#90 CLI for Postfixadmin


Today i've spend a lot of time to make a simple CLI widget for Postfixadmin. So you can add a tons of mailboxes or aliases at once by one script execution.

The requirements are:


Simply put the scripts folder in your main root of postfixadmin or somewhere else. You can add path to postfixadmin by -webroot /path/to/pfadmin

At the moment only user view and user password works
Version 0.2 comes tomorrow. eventually.

//btw: popen with dovecotpw doesn't work on cli. Need bugfix here. <------ IMPORTANT (functions.inc.php - function pacrypt(..) )
Every time I got 'Enter new password:' on STDOUT from dovecotpw

Copyright to many tons of code goes to CakePHP great work.
CakePHP's dispatcher with own Shell.

Report Bugs in this ticket please.


  • Valkum

    V0.1b - PostfixAdmin-CLI -> changed some text added copyright

  • Valkum

    Moved to v0.1b:
    *Added some Copyright text
    *Added postfixadmin-cli (bashscript)
    *Changed text in console help function

    Bugs fixed:
    *Got "Class 'Info' not found when calling postfixadmin-cli without args - fixed

  • GingerDog

    cool; i'll try and merge this son; nice idea.

  • Valkum

    Sry yesterday i've forgot to put in my actual user model.
    Now i start to implement the rest of user methods. Then i upload my model.

  • Valkum

    v0.2 - Postfixadmin-CLI -> User Shell completed. See Comment

  • Valkum

    So Version 0.2 is up.

    'user add' added.
    'user delete' added.

    changed way of output.
    model uses vars $return and $errormsg as transport.
    return 0 or 1.

    Some things in functions.inc.php are very sad for CLI.

    In line 1348 i changed $_SERVER["SERVER_NAME"]; to php_uname("n");
    because this works and i think that it is silly to run pfa twice from the same server.

    In line 1742 i changed $REMOTE_ADDR = $_SERVER['REMOTE_ADDR'];
    $REMOTE_ADDR = 'localhost';
    if (isset($_SERVER['REMOTE_ADDR']))
    Because $_SERVER is not available in CLI.

    Please find a fix for the dovecotpw problem. See Details above.

  • Valkum

    Hope for Fully OOP Recoded Version of PFA in Version 3.0

  • Thanks for your scripts. The commandline client is an often requested feature ;-)
    I also like the model/ files - OOP (and IMHO more important: one central place for the code, instead of 3 slightly different versions) is always a good thing[tm]. Now we "only" have to change the current code to actually use this classes...

    Some small notes:

    > Some things in functions.inc.php are very sad for CLI.
    > In line 1742 i changed $REMOTE_ADDR = $_SERVER['REMOTE_ADDR'];
    > to:
    > $REMOTE_ADDR = 'localhost'; [...]

    That's the db_log() function, aka logging.
    Maybe something like 'CLI' would be a better choice so that it's clear it was a commandline action.
    An even better idea would be to include the username of the user currently logged in. For shell users, this means something like:

    $processUser = posix_getpwuid(posix_getuid());
    $REMOTE_ADDR = $processUser['name'] . ' @ CLI';

    The posix functions are not available on windows, and maybe not even on all linux installations (hint: php packages that are split by module) -> The posix_* calls need to be wrapped with function_exists().

    BTW: On which version/svn revision of postfixadmin are your changes based? I'm asking to avoid merge conflicts.
    For me it looks like you used the 2.3 release as base since the model/AliasHandler.php and model/VacationHandler.php are exactly the same.
    SVN trunk has some changes in VacationHandler.php (added support for vacation start and end dates) - therefore you should use this version if you have to change anything in it ;-) AliasHandler.php also has some changes (mostly whitespace) in SVN trunk.

    Regarding your comments on the global vars for table names: yes, they are ugly. The long-term solution (at least from my point of view) is to use the db_insert, db_update, db_delete functions (see functions.inc.php) instead of writing the INSERT, UPDATE and DELETE statements "by hand". Some new queries already use these functions, however several "old" ones need to be migrated.

    Yes, we'll also need a similar function for SELECT. This might be harder than the above ones because some SELECT queries postfixadmin uses are quite complex. We'll have the choice between nearly no abstraction and a non-understandable db_select function ;-) - I hope there can be something between those extremes.

    And a final question: What about joining the postfixadmin-devel mailinglist? Communicating using a textarea that displays max. 5 lines (= this ticket ;-) isn't the best option IMHO. But it's your decision of course since you provide(d) the code ;-)

  • Sebastian

    Hi guys,

    actually, I hadn't any time to develop further, but I can see light on the other end of the tunnel... ;)

    I started looking at PHPDoctrine as OOP-model. PHPDoctrine evolved very good over the last few months. I think I'll start an approach to convert things towards PHPDoctrine.

    Are there any other good solutions out there that would be worth looking at?

  • Valkum

    I think to write own OOP DB Models is much better than use somethin based on third party.
    The only reason to use cakePHP CLi was the nice getParams and dispatcher function. :)
    But when we use such a big project like PHPDoctrine we have to use alway te up to date version of this. So we have more work if something changes in PHPDoctrine.

    So i Think so:

    *Use of db_update etc.
    (pgsql things have to handled in this functions to)

    *Port this functions to OOP.

    If anyone have more time then me, he can Write the alias shell based on my user shell and create-alias.php, edit-alias.php and delete-alias.php
    But then directly with db_delete, db_insert etc.

    About db_select. I thing we have to watch over drupals db function.
    There you can transfer params so that you can build complex queries.

    btw: what the spoken language in pfa-devel maillist ?

  • Valkum

    Oh one thing i have forgotten.
    The language phrases, should not include html tags or something similar.

    • status: open --> closed-fixed
    • Group: --> SVN (please specify revision!)
  • Current SVN trunk contains a fully working postfixadmin-cli (with lots of changes and improvements over what the files in this ticket contains).

    Therefore I'd say we can happily close this as fixed :-)