postfixadmin-devel — Postfix Admin development talk - users are also welcome

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[457] trunk/VIRTUAL_VACATION/vacation.pl

[Christian B. <pos...@cb...>]

Hello,

Am Mittwoch, 3. September 2008 schrieb Gin...@us...:
> +    # the regexp used here could probably be improved somewhat, for
> now hope that people won't use # as a valid mailbox character.
> +    my $tmp = $smtp_recipient;
> +    $tmp =~ s/\@$vacation_domain//;

What about matching against the end-of-string to make the regex 
failsafe?

    $tmp =~ s/\@$vacation_domain$//;

Untested (and therefore not commited) - please give it a try and commit 
it to SVN if it works ;-)


Regards,

Christian Boltz
-- 
Chance is irrelevant.  We will succeed.            -- Seven of Nine

Re: [Postfixadmin-devel] About forwarding

[David G. <da...@co...>]

Ismail OZATAY wrote :
> Hello all,
> 
> I have a problem. If i want to forward someone's mailbox to other one, i 
> have to delete mailbox and while creating it can be a forward box. Why i 
> must delete the mailbox ? Is there a way to fix this problem?
> 

Yes, login as the user and you can edit forwarding etc

David.
-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

[Postfixadmin-devel] About forwarding

[Ismail O. <is...@is...>]

Hello all,

I have a problem. If i want to forward someone's mailbox to other one, i 
have to delete mailbox and while creating it can be a forward box. Why i 
must delete the mailbox ? Is there a way to fix this problem?

Thanks

ismail 

Re: [Postfixadmin-devel] refactoring

[Christian B. <pos...@cb...>]

Hello,

just to keep you up to date:

I have updated the baseclass and filled it with some code (by splitting 
fetchmail.php). I also created a class for fetchmail as a first 
example.

The two files are attached. Be warned that the code is completely 
untested and still is not as abstract as it should be at many places. 
However, you should get the point.

Comments and patches welcome ;-)


Regards,

Christian Boltz
-- 
> > My calendar shows May 12th to be a Friday, not a Thursday?
> I meant 11th ;-(.
With all the delays, perhaps mentioning the year would also be
a good idea. ;-)     [> Andreas Jaeger and houghi in opensuse]

Re: [Postfixadmin-devel] refactoring [ZF stuff]

[Christian B. <pos...@cb...>]

Hello,

Am Dienstag, 29. Juli 2008 schrieb David Goodwin:
> 21:36 < lenix> ok, i've made a first step and managed to dump the
> model of my current db-structure into some PHP/ZendFramework code
> 21:36 < lenix> see http://lenix.de/pfaModel.phps and
> http://lenix.de/pfaModel.sql

Looks good, but I'm still not sure if we
a) need a class for each table
b) need a "big" abstraction layer for doing some SELECT, INSERT, UPDATE 
   and DELETE operations

The other option would be a small database class with a syntax like

$db->begin # begin transaction - or simply ignore call if not supported
$db->insert($table, $values_array)
$db->update($table, $primarykey_field, $primarykey_value, $values_array)
$array = $db->select($table, $cond, $limit, $orderby)

and some helper functions like
$db->cond($field, $operation, $value)
    # example: $db->cond("domain", "=", "example.com")
$db->and($cond1, $cond2, $cond3, ...) # used to build WHERE clauses
    # example: $db->and($db->cond(...), $db->cond(...) )
$db->or($cond1, ...) # same with OR

The helper functions might look superfluous, but they make the 
statements independent from the SQL language.

The advantage I see with this solution: It would be really lightweight 
and only contain what we really need.

When thinking further: what would be easier for someone who wants to add 
LDAP support? (I'm not a LDAP user/admin/fan, but it looks like some 
people would like to use it. So we should at least try to make it easy 
for them.)

> 21:38 < lenix> $_columns is for reference-purposes only, i don't know
> whether such a variable does exist in ZF

OK, this would have been my first complaint otherwise. We (will) have 
the table structure in $struct already, duplicating it in the database 
class is pointless.

We have the database structure in upgrade.php also, but I'm afraid we 
won't be able to avoid this - unless someone extracts the database 
scheme comparison from Typo3 ;-)

> 21:41 < lenix> GingerDog: i intended to add some validation-routines
> and an usage-example first..

I'll have validation code in my module class already, not sure if you 
need additional validation in the database class.

Having some usage examples (for insert, update, delete and select) would 
be nice.


Regards,

Christian Boltz
-- 
"Guten Tag, ich möchte gerne einen Tisch reservieren."
"Gerne, auf welchen Namen denn?"
"31337 /-/ /\ X0R!"
[Jens Benecke in suse-linux zum Thema Realnames]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[428] trunk/VIRTUAL_VACATION/vacation.pl

[David G. <da...@co...>]

Christian Boltz wrote :
> Hello,
> 
> Am Dienstag, 29. Juli 2008 schrieb Gin...@us...:
> > Revision: 428
> 
> > vacation.pl: add patch from Luxten - enable re-notification after
> > definable timeout
> 
> > +# notification interval, in seconds
> > +# set to 0 to notify only once
> > +my $interval = 60*60*24;
> 
> This means the default interval is 1 day - IMHO too often, this will 
> become annoying. I'd prefer a week or, even better, only once as a sane 
> default. 
> 
> Any objections against changing the default (back) to "only once"?
> 
> 

None!

-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[428] trunk/VIRTUAL_VACATION/vacation.pl

[Christian B. <pos...@cb...>]

Hello,

Am Dienstag, 29. Juli 2008 schrieb Gin...@us...:
> Revision: 428

> vacation.pl: add patch from Luxten - enable re-notification after
> definable timeout

> +# notification interval, in seconds
> +# set to 0 to notify only once
> +my $interval = 60*60*24;

This means the default interval is 1 day - IMHO too often, this will 
become annoying. I'd prefer a week or, even better, only once as a sane 
default. 

Any objections against changing the default (back) to "only once"?


Regards,

Christian Boltz
-- 
Aus technischen Grunden befindet sich die Signatur
auf der Rückseite dieser Mail.

Re: [Postfixadmin-devel] refactoring [ZF stuff]

[David G. <da...@co...>]

21:36 < lenix> ok, i've made a first step and managed to dump the model 
of my current db-structure into some PHP/ZendFramework code
21:36 < lenix> see http://lenix.de/pfaModel.phps and 
http://lenix.de/pfaModel.sql
21:37 < lenix> see 
http://framework.zend.com/manual/en/zend.db.table.relationships.html#zend.db.table.relationships.cascading 
for
                onDelete/onUpdate
21:38 < GingerDog> looks good
21:38 < GingerDog> i'm not sure i like the pfa prefix though
21:38 < lenix> $_columns is for reference-purposes only, i don't know 
whether such a variable does exist in ZF
21:39 < lenix> i would use some kind of prefix, i don't care which one
21:39 < GingerDog> Most importantly, do not declare cascading operations 
both in the RDBMS and in your Zend_Db_Table class.
21:39 < lenix> but it proves to be good pratice if you want to include 
the code of/in some other software
21:39 < lenix> GingerDog: exactly
21:40 < lenix> i've got cascading-stuff inside my innodb already, that's 
why i commented it out
21:40 < GingerDog> can you mail the code, or a url of it, to the -devel 
mailing list
21:41 < lenix> GingerDog: i intended to add some validation-routines and 
an usage-example first..
21:41 < lenix> but if you think publishing it in such an early state of 
course i can
21:42 < lenix> .. an early state make sense, of course ..
21:43 < lenix> anyway, i will call it a day now and go play some foosball :)
21:43 < lenix> ttyl
21:43 < GingerDog> k
21:44 < GingerDog> if you're going to imrpove on it then keep at it
21:44 < GingerDog> but it needs "publishing" sooner rather than later
21:50 < lenix> if you think it is enough for a first step already feel 
free to copy/paste our conversation to the list



-- 
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] about error

[Christian B. <pos...@cb...>]

Hello,

Am Dienstag, 29. Juli 2008 schrieb Ismail OZATAY:
> why i can not add with the same name mailuser ? I mean i have 2
> domains xxx.com and yyy.com. i add al...@xx... then i can not add
> al...@yy....  it says "The EMAIL is not valid!" . how can i fix this
> problem ? could you help me ?

I'm quite sure the failing domain (yy.com) is not resolvable in your 
nameserver. Please create an DNS entry for it (you'll need it anyway if 
you want to receive mails on it) or set 
$CONF['emailcheck_resolve_domain']='NO'


Note to myself and GingerDog (whoever is faster):
This starts to become a FAQ - we should really display a separate error 
message on DNS failures.


Regards,

Christian Boltz
-- 
> got a patch?
-ENOTMYJOB
[> Markus Rueckert and Bernhard Walle in opensuse-packaging]

[Postfixadmin-devel] about error

[Ismail O. <is...@is...>]

Hi all ;

why i can not add with the same name mailuser ? I mean i have 2 domains 
xxx.com and yyy.com. i add al...@xx... then i can not add al...@yy....  it 
says "The EMAIL is not valid!" . how can i fix this problem ? could you help 
me ?

thanks 

Re: [Postfixadmin-devel] refactoring

[Christian B. <pos...@cb...>]

Hello,

this mail has two parts:

a) summing up the IRC session (copy and paste from the IRC log)

b) things we didn't talk about in IRC

Gingerdog, you might want to skip to b) ;-)


a)

Am Montag, 28. Juli 2008 schrieb David Goodwin:
> Christian Boltz wrote :
> > Am Mittwoch, 23. Juli 2008 schrieb Christian Boltz:
> > > My idea in short:
> > > - create a basic class with the required functions/methods.
> >
> > I have written a proof-of-concept class postfixadminBaseclass as
> > described in my proposal. It is attached to this mail.

> Right, I'll include the code inline, as I'm lazy (and using mutt,
> while my office computer is dead thanks to the thunder+lightening)

> class postfixadminBaseclass {
...
>     # name, also used for generating links
>     public function name($listmode=0) {
>         # usually:
>         return "baseclass";
...
>     }
>
> ^^ What's name() trying to do?

The intention was to use it as basename for generating links (to 
the "add new", "edit" and "list" pages). However, I'm not sure if this 
should be really inside the class, since it has to do with HTML 
rendering.

-> removal candidate, I'll comment it out in my draft (and already have 
an idea how to replace it ;-)

...
>     # handles add and edit calls internally
>     protected function addOrEdit($primarykey, Array $newvalues,
> $mode) { # mode: 0 = edit, 1 = new
>
>         #    calls: [TODO]
>         #    - [non-public] function validate_by_type() (simple check
> against #      field type given in table structure)
>
> ^^ I think this is unnecessary; database introspection might be a
> better bet.

[GingerDog] i think type checks etc would be better handled by asking 
            the model class to validate() itself

we can do most checks this way (nearly automatically - in the central 
class). And it even has the advantage that we can define our own types 
if needed - like "mail address"

...
>     # TODO
>     #  * [non-public] check_domain_permission() (check if the admin
> has #    permissions for this domain)
>     #  * [non-public] check_other_permission() (check other
> permissions, for #    example if editing mailbox aliases is allowed)
...
> It would be nice for the permission definitions to be done in one
> place, where ever that may be.
>
> Could permissions be listed a bit like :
>
> e.g.
>
> /**
>  * decorator for permission enforcement
>  */
> class PermissionProxy {
...

I'm not planning to implement a login($user, $pass) inside the class. 
But I'm thinking about a check "has permissions for this domain?" or "is 
superadmin?" which is basically what we have in each script right now.
The base class would handle this without modification in each module 
And the "special permission checks" I mentioned are things like checking 
$CONF['fetchmail'] ;-)

[GingerDog] Permissions checks (or at least enforcements) shouldn't 
            really be in the individual controller(s)  
            if they are moved to the model classes then they take effect 
            for any user, regardless of whether they're coming through  
            the web interface, xmlrpc or whatever 
            and there may be less repetition 

The checks would be in the base class - no need to redefine them each 
time. Just using the functions from the parent class doesn't look bad 
for me ;-)


Part b)

> So, exposed via xmlrpc etc...
>
> /**
>  * phpdoc needs adding IRL
>  * clients (whether 'local' or via xmlrpc/soap etc) connect to this.
>  */
> class AliasServer {
...
>         public function addAlias($p, $p, $p) {
>                 return $this->backend->addAlias($u, $p);
>         }

If possible, we should have common names ("add", "edit") instead of 
type-specific ones. If you simply add a $type-Parameter, you don't even 
need to implement a xmlrpc connector class for each type ;-)
(the data arguments can/should be passed as array to be flexible)

>         public function getAliasList($domain, $offset, $limit) {
>                 return $this->backend->getAliasList($domain, $offset,
> $limit); }

Ah, you just found two missing parameters in my items() function: 
$offset and $limit. I now have:
public function items 
    ($domain="", $admin="", $search="", $offset = -1, $limit = -1)

Looks like I should switch to a named parameter array instead of lots of 
optional parameters...

    # $filter can contain several parameters to filter the list.
    # All parameters in $filter are optional.
    # $filter = array(
    #   'domain' -> "",
    #   'admin'  -> "",
    #   'search  -> "",
    #   'offset' -> 0,
    #   'limit'  -> -1, # unlimited
    # )
    public function items (array $filter) {

Looks better ;-)

>         public function search($domain, $string) {
>                 // whatever
>         }

Already included in items(), see above ;-)

> /* The above isn't quite right yet, as $username/$password need
>  * passing in to each method call... as xmlrpc isn't very stateful
> ... * perhaps my decorator idea can't/won't work
>  */

This makes another two parameters to the generic xmlrpc calls: username 
and password. (I'll forget about this for now - first I need a working 
baseclass and then I'll think about xmlrpc again ;-)

> Then for the actual Model object (e.g. Alias) :
...
> class Alias extends Zend_Db_Abstract {
>         protected $_name = 'alias';
>         protected $_primary = 'id'; // whatever the pkey field is
>         protected $_sequence = false; // force use of pkey field
> value in insert . public function __construct() {
>                 $db = Zend_Db::factory('....whatever...'); //?
>                 parent::__construct($db);
>         }
...

Or just use our db_insert (and db_update, db_delete etc.) function we 
already have. I'll probably do this when filling the baseclass with 
code.

And again: Do _not_ make such things specific to a table or module 
unless really needed ;-)

> > Comments welcome: (ditto)
> > - do you think this could become the basis of all postfixadmin
> > pages?
>
> I'm keen to separate a page from the underlying logic used for it.

/me too ;-)

> We should provide e.g. xmlrpc or soap integration, and decouple the
> business logic from the controller scripts that generate html pages.

ACK - even if my main target is to make maintenance and writing new 
modules easier. Adding xmlrpc or soap integration doesn't conflict with 
this target.

> Having some sort of base controller and/or model class will be a good
> thing.

Yes. I'm sure we don't even foresee how many good things we will get by 
having a class-based implementation :-)

Last IRC quote for this mail:
If my class works as I expect, most modules will contain of "overwrite 
table name, overwrite database scheme/field list, overwrite default 
values" - and nothing else :-)

> > - what should I/we do better? (We have 35 °C outside, so I'm sure
> > the baseclass isn't perfect ;-)
>
> Heh; it was warm here, but also humid (as is nearly always the case
> in the UK); thankfully we've just had a few thunderstorms and things
> seem better. The dog wasn't happy though.

;-)

> I think a good start is perhaps to list all classes, and the
> functions they need :

Yes - and we should also keep in mind how to map them on the standard 
method names in my baseclass.

> Vacation:
>   - isEnabled($email);

items() with a search parameter (empty result = no vacation)

The easier way would be an itemExists() function, however I'm not sure 
if we need this.

>   - create($email, $subject, $body, $whatever);
>   - delete($email, $subject, $body, $whatever);
>   - retrieve($email);
>
> Domain:
>   - list($offset, $limit = 20)
>   - retrieve($name);
>   - create($name, $backup_mx, etc);
>   - delete($name);
>
> Mailbox:
>   - list($offset, $limit = 20);
>   - retrieve($name);
>   - create($name, $fullname, $password, ... etc)
>   - delete($name);

All those will work with the functions I already have
[retrieve -> item(), create -> add()].

> There would need to be some sort of shared 'authentication'/'user'
> data/object so we can enforce permission checks (e.g that a user can
> only delete their own mailbox, and not someone elses; but a global
> admin can delete any... etc)

Yes - as written above, the login details could just be additional 
parameters.

The username has to be passed to the baseclass somehow (parameter to 
each function or as a global variable - what's better?)

The password check should be done outside because it differs on the 
implementation (HTML output has a session, xmlrpc might need to pass it 
each time).


My personal summary of the mail is that my baseclass isn't that bad.
If nobody objects, I'll create a classes/ directory in SVN and check it 
in in the next days ;-)


Regards,

Christian Boltz
-- 
Und dann war da noch der junge Mann, der unbedingt Schriftsteller 
werden wollte. Er wollte Emotionen wecken und die Leute zum Weinen
bringen. Sein Traum wurde wahr, er verfaßt heute die Fehlermeldungen
bei Microsoft.

Re: [Postfixadmin-devel] refactoring

[David G. <da...@co...>]

Christian Boltz wrote :
> Hello,
> 
> Am Mittwoch, 23. Juli 2008 schrieb Christian Boltz:
> > My idea in short:
> > - create a basic class with the required functions/methods.
> 
> I have written a proof-of-concept class postfixadminBaseclass as 
> described in my proposal. It is attached to this mail.
> 
> Please note that the class does not contain real code yet, only the 
> structure and sometimes some dummy code. It also still misses some 
> (internal) functions like permission check.
> 
> Functions and variable definitions are currently sorted by action - this 
> needs to be changed to "variables first", but the current sorting is 
> easier for the initial development.
> 
> I did some small changes compared to the proposal in my mail - see the 
> comments inside the file for details.

Right, I'll include the code inline, as I'm lazy (and using mutt,
while my office computer is dead thanks to the thunder+lightening)

<?php

# template for all postfixadmin classes (admins, domains, mailboxes etc.)
#
# What it DOES:
# * handling of listing (database -> array)
# * handling of editing/adding items (database -> variables for item-to-edit and variables -> database)
# * input validation for editing/adding items
# * permission checks
# * accepts / returns data as variables/arrays
#
# What it DOES NOT:
# * rendering of lists -> table_class
# * rendering of edit forms -> form_class
# * output HTML etc.

class postfixadminBaseclass {

    protected function __construct() {
        $this->initStruct;
        $this->initDefaults;
    }

    # name, also used for generating links
    public function name($listmode=0) {
        # usually:
        return "baseclass";

        # for "virtual" list vs. "mailbox" editing
        # if ($listmode == 0) {
        #     return "mailbox";
        # } else {
        #     return "virtual";
        # }
    }

^^ What's name() trying to do?


    #  * [read-only] table structure as array (like $fm_struct in
    #    fetchmail.php)

^^ You love fetchmail.php don't you ? :)



    #  * function get_list() (for list view)
    #  * function get_list_for_domain() (for list view)
    #    - both get_list* should have an optional $search parameter
    #  -> I decided to merge this to one function
    #  -> "list" is a reserved word, switched to "items"
    public function items ($domain="", $admin="", $search="") {
        # get list from database
        # return array (array(key -> value), array(key -> value), ...)
    }

^^ OK, this makes sense.

    #  * function get_item() (current values, for edit form)
    public function item ($primarykey) {
        # get item from database
        # return array (key -> value)
    }

^^ Ditto; seems fine.


    # handles add and edit calls internally
    protected function addOrEdit($primarykey, Array $newvalues, $mode) {
        # mode: 0 = edit, 1 = new

        #    calls: [TODO]
        #    - [non-public] function validate_by_type() (simple check against
        #      field type given in table structure)

^^ I think this is unnecessary; database introspection might be a
better bet.

        #      -> see fetchmail.php _inp_*()
        #      -> also check that only allowed fields are set
        #    - [non-public] function validate_special() (other checks that are
        #      not covered by type check)

^^ OK; good plan.

    }


    # TODO
    #  * [non-public] check_domain_permission() (check if the admin has
    #    permissions for this domain)
    #  * [non-public] check_other_permission() (check other permissions, for
    #    example if editing mailbox aliases is allowed)
    #  * other non-public functions as needed - target should be to have most
    #    code in the common class and as least as possible in the
    #    mailbox/alias/whatever class.
    #    -> this also means that functions should be split into subparts where needed

It would be nice for the permission definitions to be done in one
place, where ever that may be.

Could permissions be listed a bit like :

e.g. 

/**
 * decorator for permission enforcement
 */
class PermissionProxy {
        public function __construct($real) {
                $this->real = $real;
        }
        $perms = array ( 'object.functionName' => array('role','role','role'),
                         'otherobject.somethingElse' => array('role', 'role'), // etc
                        )

        function __call($name, $values) {
                // see if $name is in permissions array, and role(s)
                // match.
                $key = get_class($this->real) . '.' $name;
                $permission = array_key_exists($key, $perms)) && ..  etc ..
                if($permission) {
                        return call_user_func_array(array($whatever,$name), $values);
                }
                else { 
                        throw new PermissionException("Access denied"); 
                }
        }

}

So, exposed via xmlrpc etc...

/**
 * phpdoc needs adding IRL 
 * clients (whether 'local' or via xmlrpc/soap etc) connect to this.
 */
class AliasServer {
        protected $backend = null;
        public function __construct() {
                $this->backend = new PermissionProxy(new Alias());
        }

        public function addAlias($p, $p, $p) {
                return $this->backend->addAlias($u, $p);
        }

        public function deleteAlias($u, $p) {
                return $this->backend->deleteAlias($admin);
        }
        public function getAliasList($domain, $offset, $limit) {
                return $this->backend->getAliasList($domain, $offset, $limit);
        }

        public function search($domain, $string) {
                // whatever
        }
}
/* The above isn't quite right yet, as $username/$password need
 * passing in to each method call... as xmlrpc isn't very stateful ...
 * perhaps my decorator idea can't/won't work
 */


Then for the actual Model object (e.g. Alias) :


/*
 * see http://framework.zend.com/manual/en/zend.db.table.html 
 * perhaps have a PostfixAdminAbstract class with additional
 * functionality over Zend_Db_Abstract in it for Alias to inherit from?
 */
class Alias extends Zend_Db_Abstract {
        protected $_name = 'alias';
        protected $_primary = 'id'; // whatever the pkey field is
        protected $_sequence = false; // force use of pkey field value in insert .
        public function __construct() {
                $db = Zend_Db::factory('....whatever...'); //?
                parent::__construct($db); 
        }

        // Zend_Db_Abstract provides:
        // insert(array(key=>value, key=>value ... ));
        // update($data, $where);
        // delete($where);
        // find($pkey);
        // fetchall($select_query);

        // perhaps we'd want to wrap e.g. update in a call like ...
        public function edit($pkey, $data) {
                // perform validation check(s); throw some sort of
                // exception if they fail.
                return $this->update($data, $this->getAdapter()->quoteInto('pkey = ?', $pkey));
        }
}

> Comments welcome: (ditto)
> - do you think this could become the basis of all postfixadmin pages?

I'm keen to separate a page from the underlying logic used for it. We
should provide e.g. xmlrpc or soap integration, and decouple the
business logic from the controller scripts that generate html pages. 
Having some sort of base controller and/or model class will be a good
thing.

> - what should I/we do better? (We have 35 °C outside, so I'm sure the 
>   baseclass isn't perfect ;-)

Heh; it was warm here, but also humid (as is nearly always the case in
the UK); thankfully we've just had a few thunderstorms and things seem
better. The dog wasn't happy though.

I think a good start is perhaps to list all classes, and the functions
they need :

e.g.

Vacation:
  - isEnabled($email);
  - create($email, $subject, $body, $whatever);
  - delete($email, $subject, $body, $whatever);
  - retrieve($email);

Domain:
  - list($offset, $limit = 20)
  - retrieve($name);
  - create($name, $backup_mx, etc);
  - delete($name);

Mailbox:
  - list($offset, $limit = 20);
  - retrieve($name);
  - create($name, $fullname, $password, ... etc)
  - delete($name);

etc

There would need to be some sort of shared 'authentication'/'user'
data/object so we can enforce permission checks (e.g that a user can only
delete their own mailbox, and not someone elses; but a global admin
can delete any... etc)

</ramble>

And so on,

David.
-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] refactoring

[Christian B. <pos...@cb...>]

Hello,

Am Mittwoch, 23. Juli 2008 schrieb Christian Boltz:
> My idea in short:
> - create a basic class with the required functions/methods.

I have written a proof-of-concept class postfixadminBaseclass as 
described in my proposal. It is attached to this mail.

Please note that the class does not contain real code yet, only the 
structure and sometimes some dummy code. It also still misses some 
(internal) functions like permission check.

Functions and variable definitions are currently sorted by action - this 
needs to be changed to "variables first", but the current sorting is 
easier for the initial development.

I did some small changes compared to the proposal in my mail - see the 
comments inside the file for details.


Comments welcome:
- do you think this could become the basis of all postfixadmin pages?
- what should I/we do better? (We have 35 °C outside, so I'm sure the 
  baseclass isn't perfect ;-)


Regards,

Christian Boltz
-- 
> welche log willst sehen ???
Das ist die Postfixbuch-Users Liste, vielleicht das Log von,
hmmm, Postfix? Nur so ne Idee.
[> R. Wilhelm und Ralf Hildebrandt in postfixbuch-users]

Re: [Postfixadmin-devel] refactoring

[Christian B. <pos...@cb...>]

Hello,

Am Montag, 28. Juli 2008 schrieb Guido 'lenix' Böhm:
> i just subscribed to the list. I've seen the recent
> "Refactoring" thread in the archives and would like to
> participate if anybody is interested.

Yes, of course ;-)

> What would you guys think about using ZendFramework [1]
> for the ORM [2] and validation part at least? 

Good question - I don't know it, so I can't really answer.
After having a quick look at the documentation, it looks like it has 
lots of things we'll never need and might therefore cause some 
overhead. (I can't judge if it is worth it ;-)

> [...] It could probably ease the hassle with PG-
> vs. MySQL since it comes with a pretty much complete
> database abstraction layer.

Well, in postfixadmin the things we need is mostly SELECT / INSERT / 
UPDATE / DELETE. We already have some abstraction functions for those 
queries which work well IMHO and are easy to use. I consider the 
various checks for pgsql in the code mostly historical issues - usually 
they can be replaced with db_boolean() calls or alike.

The ALTER TABLE for database upgrades are always special (_very_ special 
if foreign keys come into play ;-) and I'm quite sure that most 
abstraction layers won't be very useful for those things.

> Of course this would be PHP5 only, but i don't think this 
> is really an issue since PHP4 isn't officially supported

ACK

> anymore anyway and should be outdated soon. Moving to
> PHP5 would allow for various other improvements like
> and exception-based error-handling throughout the source.

Yes, why not...

> Maybe it would be a good idea to consider an MVCed [3]
> rework of the interface, too, 

My proposal goes in this direction, even if I didn't have MVC in mind 
when writing it ;-)

> and think up a way how to 
> integrate some kind of module-/plugin-system for
> additional functions which extend the core-functionality

Yes, good idea. And not really difficult to implement.

> I was thinking about adding a searchable maillog for
> Domain-Admins for example, which would include rejects/
> bounces/... from /var/log/maillog for the domains in
> question, something i would consider a typical plugin
> use-case. Vacation, Fetchmail and broadcast-msgs would
> imho make good candidates for being "outsourced" as
> plugins as well.

We could call _everything_ a module or plugin.

> On an unrelated note, can someone provide me with an
> (maildir-) archive of postfixadmin-devel? It seems like
> sourceforge itself doesn't provide any downloads and i
> like to have archives searchable in my mailclient..

I'll send you a mailbox off-list. Converting to maildir shouldn't be too 
hard ;-)


Regards,

Christian Boltz
-- 
Und der erste, der mich darauf hinweist, ich könne das ja selbst
umkonfigurieren, ich müsse nur die 200KB-Doku lesen, den besuche
ich zu Hause und *singe*(!) ihm den Sourcecode vor,  und DAS ist
WIRKLICH eine STRAFE. [Ratti in suse-linux]

Re: [Postfixadmin-devel] refactoring

[David G. <da...@co...>]

> i just subscribed to the list. I've seen the recent
> "Refactoring" thread in the archives and would like to
> participate if anybody is interested.
 
Anyone's welcome; but your more welcome if you contribute code :)

> What would you guys think about using ZendFramework [1]
> for the ORM [2] and validation part at least? I've done
> various small to midsize projects with ZF recently and
> had a pretty positive impression about the documentation
> (good examples, ..) and the structure and robustness of
> the code. It could probably ease the hassle with PG-
> vs. MySQL since it comes with a pretty much complete
> database abstraction layer.
 
ZF sounds fine; I was reading the docs for Zend_Db_Table 
the other day. My only issue is that I'd like to aim for a
xmlrpc/soap interface, which means you can't have objects as
return types or parameters to methods.

My dummy code for what I wanted to achieve already uses PDO.

I think xmlrpc/soap would be very useful for people wanting to
integrate postfixadmin with e.g. squirrelmail /
insert-other-email-client-here. At the moment they have to duplicate
code which isn't very good.

Presumably xmlrpc/soap will allow others to integrate postfixadmin in
ways I've not yet considered.

> Of course this would be PHP5 only, but i don't think this
> is really an issue since PHP4 isn't officially supported
> anymore anyway and should be outdated soon. Moving to
> PHP5 would allow for various other improvements like
> and exception-based error-handling throughout the source.
 
Yes, I have no problem with dropping PHP4 compatibility.

> Maybe it would be a good idea to consider an MVCed [3]
> rework of the interface, too, and think up a way how to
> integrate some kind of module-/plugin-system for
> additional functions which extend the core-functionality
> (managing a set of domains/aliases/mailboxes inside an
> sql-database).
 
We're working towards an MVC approach. The views are already seperate,
so it's just a case of fixing the controller/model section.

Some sort of plugin architecture sounds like a good idea.

> On an unrelated note, can someone provide me with an
> (maildir-) archive of postfixadmin-devel? It seems like
> sourceforge itself doesn't provide any downloads and i
> like to have archives searchable in my mailclient..
 
I can't sorry. I delete most email on this account once it is older
than a few weeks.

David.


-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] refactoring

[Guido 'l. B. <g....@le...>]

Hi everyone,

i just subscribed to the list. I've seen the recent
"Refactoring" thread in the archives and would like to
participate if anybody is interested.

What would you guys think about using ZendFramework [1]
for the ORM [2] and validation part at least? I've done
various small to midsize projects with ZF recently and
had a pretty positive impression about the documentation
(good examples, ..) and the structure and robustness of
the code. It could probably ease the hassle with PG-
vs. MySQL since it comes with a pretty much complete
database abstraction layer.

Of course this would be PHP5 only, but i don't think this
is really an issue since PHP4 isn't officially supported
anymore anyway and should be outdated soon. Moving to
PHP5 would allow for various other improvements like
and exception-based error-handling throughout the source.

Maybe it would be a good idea to consider an MVCed [3]
rework of the interface, too, and think up a way how to
integrate some kind of module-/plugin-system for
additional functions which extend the core-functionality
(managing a set of domains/aliases/mailboxes inside an
sql-database).

I was thinking about adding a searchable maillog for
Domain-Admins for example, which would include rejects/
bounces/... from /var/log/maillog for the domains in
question, something i would consider a typical plugin
use-case. Vacation, Fetchmail and broadcast-msgs would
imho make good candidates for being "outsourced" as
plugins as well.

On an unrelated note, can someone provide me with an
(maildir-) archive of postfixadmin-devel? It seems like
sourceforge itself doesn't provide any downloads and i
like to have archives searchable in my mailclient..

[1] http://framework.zend.com/
[2] http://en.wikipedia.org/wiki/Object-relational_mapping
[3] http://en.wikipedia.org/wiki/Model-view-controller

// lenix
-- 
Guido Boehm |    _/  | website: http://lenix.de/
Voigtstr. 8 |   _/   | contact: http://lenix.de/contact/
20257 DE/HH |  _/    | my card: http://lenix.de/contact/vcard.vcf
01738099196 | _/_/_/ | sweet<3: http://xichen.de/ :]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[414] branches

[David G. <da...@co...>]

Christian Boltz wrote :
> Hello,
> 
> Am Mittwoch, 23. Juli 2008 schrieb Gin...@us...:
> > Revision: 414
> 
> > yeah, clearly I should have created the branch before merging stuff
> > into 2.2.1...
> >
> > Added Paths:
> > -----------
> >     branches/postfixadmin-2.2.1.1/
> 
> What about using another scheme for branch names and version tagging?
> 
> Proposal:
>     branches/postfixadmin-2.2 (a branch for all 2.2.* code)
> and
>     tags/postfixadmin-2.2.1.1 (a tag for each release, code in read-only 
>     mode - no commits in tags/*)
> 
> This avoids the need to rename the branch after every minor release.
> It would also bring some benefit for our users - we could just tell them 
> to use branches/postfixadmin-2.2 and run svn up from time to time 
> without the risk to break something.
> 
> 

sounds good to me.

David


-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[414] branches

[Christian B. <pos...@cb...>]

Hello,

Am Mittwoch, 23. Juli 2008 schrieb Gin...@us...:
> Revision: 414

> yeah, clearly I should have created the branch before merging stuff
> into 2.2.1...
>
> Added Paths:
> -----------
>     branches/postfixadmin-2.2.1.1/

What about using another scheme for branch names and version tagging?

Proposal:
    branches/postfixadmin-2.2 (a branch for all 2.2.* code)
and
    tags/postfixadmin-2.2.1.1 (a tag for each release, code in read-only 
    mode - no commits in tags/*)

This avoids the need to rename the branch after every minor release.
It would also bring some benefit for our users - we could just tell them 
to use branches/postfixadmin-2.2 and run svn up from time to time 
without the risk to break something.


Regards,

Christian Boltz
-- 
Error: File not found -- search behind couch? (Y/N)

Re: [Postfixadmin-devel] refactoring

[Christian B. <pos...@cb...>]

Hello,

Am Dienstag, 22. Juli 2008 schrieb David Goodwin:
> I'm wondering if we should refactor the codebase into having a
> distinct object layer which :
>
> a) Could be exposed via xmlrpc or soap (useful for 3rd party
> integration)
>
> b) Could be more easily tested (unit tests etc)
>
> c) Will move some logic from the controllers into a model layer.

Just a short note: I'm also thinking about refactoring since some time. 
My focus was more on making programming and changes easier, but having 
an automated interface would be a nice side effect.

My idea in short:

- create a basic class with the required functions/methods. Most 
  important items: (intentionally skipping the parameter lists)
  * [non-public] table structure as array (like $fm_struct in 
    fetchmail.php)
  * function get_list() (for list view)
  * function get_list_for_domain() (for list view)
    - both get_list* should have an optional $search parameter
  * function get_item() (current values, for edit form)
  * function edit() (called when submitting the edit form)
    parameters given as array with named keys
    edit() calls:
    - [non-public] function validate_by_type() (simple check against 
      field type given in table structure)
    - [non-public] function validate_special() (other checks that are 
      not covered by type check)
  * function add() (basically like edit())
  * function delete()
  * [non-public] check_domain_permission() (check if the admin has 
    permissions for this domain)
  * [non-public] check_other_permission() (check other permissions, for 
    example if editing mailbox aliases is allowed)
  * other non-public functions as needed - target should be to have most 
    code in the common class and as least as possible in the 
    mailbox/alias/whatever class.

- make each object type (admin, domain, mailbox, alias) a PHP class 
  based on the basic class described above

- create/use a class for rendering lists
  Maybe we can use the Table class from http://exorsus.net/software/, 
  example on http://exorsus.net/software/table_class/test_complete.php
  (I'm using this class at other places already)

- create a class for rendering edit forms (see fetchmail.php for ideas)
  or use the one from http://exorsus.net/software

- create a small class rendering the domain dropdown we have at nearly 
  every list page

> Pseudo example:
>
> Mailbox object:
>   -> login($u, $p);
>   -> addMailbox($name, $domain)
>   -> deleteMailbox($name, [$domain]);
>   -> updateMailbox($assoc_array_of_params);

Since you already propose separate objects for mailbox, domain etc, 
I'd prefer to have common names like "add", "edit", "delete".

> Vacation object:
>   -> setAway($msg, $mailbox);
>   -> setReturned($mailbox);
>
> Domain object:
>   -> addNewDomain($name, $other, $parameters);
>   -> listDomains();
>   -> addMailbox($name);
>
> Alias object:
>   -> addNewAlias($source, $dest);
>   -> listAliasesForDomain($domain_name, $paging, $parameters);
>   -> removeAlias($source, $dest);

Admin object:
   -> list admins
   -> list domains for admin
   -> create admin
   -> add domain to admin

> So these objects would encapsulate all the required SQL logic, and
> should also have authentication checks (as appropriate). They could
> then be exposed via e.g. xmlrpc or soap - however this might require
> all methods having an additional two parameters (username, password)
> etc, or writing a simple proxy object.

A central proxy object is probably easier to maintain... (as always: if 
you can do it at a central place, don't spread the same code across 10 
files ;-)

The basic permission checks (is access to this domain allowed) could be 
handled in the basic class. If more details have to be checked, each 
class can do it additionally.

> I've made a vaguely related blog post -
> http://codepoets.co.uk/using-soap-and-xmlrpc-php5-newbies-findings

Just had a quick look at it - sounds interesting, but I'll need some 
more time to read it. Right now, I like this the best:
    SOAP is really now just called "SOAP", I think they've dropped 
    the "Simple..." bit from the name as it can be anything but simple.
;-)

> I've also released postfixadmin 2.2.1.

Good to hear.

As always ;-) I found some small problems.

You have missed some small fixes, see the attached patch.

In case you wonder: I generated this patch with (the following 3 lines 
should be entered as a single one):
svn diff 
https://postfixadmin.svn.sourceforge.net/svnroot/postfixadmin/branches/postfixadmin-2.2.1 
https://postfixadmin.svn.sourceforge.net/svnroot/postfixadmin/trunk 
and then removed everything related to alias domains.

Please read the patch and don't blindly apply it to the 2.2(.2) branch - 
at some places I have replaced big changes by short comments 
(upgrade.php, language files)

As a side effect of not including alias domains, you have caused a small 
problem with database upgrade - upgrade.php is currently at Revison 392 
(in trunk) and 397 (in 2.2.1 branch).
This means the functions to create the alias_domain table won't run when 
merged back in because it has a lower number (upgrade_300 and 
upgrade_362 - I just wonder why we have it twice...)
The problem isn't really big - we have to rename the functions to a 
higher number - and we need IF NOT EXISTS in the CREATE TABLE statement 
for those using the svn version ;-)

Oh, and IMHO we should include all database changes from trunk in future 
releases even if it produces unused tables. Causes less trouble ;-)


On the positive side, I have updated the RPM packages and also uploaded 
an openSUSE RPM to SF. I also updated the changelog and updated 
debian/changes in trunk.


Regards,

Christian Boltz
-- 
Meine Katze hat zu der Maus auch gesagt: "Kannst ganz beruhigt sein,
ich tu Dir nichts!" Und vom Fressen hat die Katze kein Ton gesagt.
[Rolf-Hubert Pobloth in suse-linux]

[Postfixadmin-devel] refactoring

[David G. <da...@co...>]

Hi,

I'm wondering if we should refactor the codebase into having a
distinct object layer which :

a) Could be exposed via xmlrpc or soap (useful for 3rd party
integration)

b) Could be more easily tested (unit tests etc)

c) Will move some logic from the controllers into a model layer.


Pseudo example:

Mailbox object:
  -> login($u, $p);
  -> addMailbox($name, $domain) 
  -> deleteMailbox($name, [$domain]);
  -> updateMailbox($assoc_array_of_params);

Vacation object:
  -> setAway($msg, $mailbox);
  -> setReturned($mailbox);

Domain object:
  -> addNewDomain($name, $other, $parameters);
  -> listDomains();
  -> addMailbox($name);

Alias object:
  -> addNewAlias($source, $dest);
  -> listAliasesForDomain($domain_name, $paging, $parameters);
  -> removeAlias($source, $dest);


So these objects would encapsulate all the required SQL logic, and
should also have authentication checks (as appropriate). They could
then be exposed via e.g. xmlrpc or soap - however this might require
all methods having an additional two parameters (username, password)
etc, or writing a simple proxy object.

I've made a vaguely related blog post - 
http://codepoets.co.uk/using-soap-and-xmlrpc-php5-newbies-findings

Feedback welcome :)


I've also released postfixadmin 2.2.1.

David.
-- 
David Goodwin 

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]

Re: [Postfixadmin-devel] postfixadmin-devel@lists.sourceforge.net

[Christian B. <pos...@cb...>]

Hello,

Am Sonntag, 20. Juli 2008 schrieb MailingLists:
> Christian Boltz wrote:
...
> > I'm not sure if this is really the cause of the problem. Anyway,
> > you can try    SELECT domain, 1 as id FROM domain WHERE ...

> Well I tried that syntax and I still get the errors :-[

Then the error is probably somewhere else.

> I have ran a grep "id" mail.log for the full errors with debuy log
> level turned on in amavis, you may see this log here:

Seems you misunderstood me - grep in your _amavis config_, not the mail 
log, please ;-)  While you are on it, you can also include all 
SQL-related statements.

Something like   grep -ri "id\|sql" /etc/amavis*   should do this.


Regards,

Christian Boltz
-- 
"Error Message: Your Password Must Be at Least 18770 Characters and
 Cannot Repeat Any of Your Previous 30689 Passwords (Q276304)"
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q276304

Re: [Postfixadmin-devel] postfixadmin-devel@lists.sourceforge.net

[MailingLists <mai...@st...>]

Benny Pedersen wrote:
> On Sun, July 20, 2008 18:44, MailingLists wrote:
>
>   
>> @lookup_sql_dsn = (
>>     ['DBI:mysql:database=postfixadmin;host=127.0.0.1;port=3306',
>>      'postfixadm',
>>      'aaaaaaaa']);
>>
>> $sql_select_policy = 'SELECT domain FROM domain WHERE CONCAT("@",domain)
>> IN (%k)';
>>     
>
> this is not currently supported :(
>
> http://www.ijs.si/software/amavisd/README.sql-mysql.txt
>
> thats the sql setup for amavisd, and we both need it :-)
>
>   
>> Example data follows:
>>     
>
> i had something in my mind with this olso so users can select from presets
> like this in postfixadmin, and domain owner can add new presets if one
> like it, olso maybe if domain owner permit it make it possible for user to
> custom policy it in amavisd
>
> if i was better php coder this was done now :/
>
> but dont add amavisd tables to postfix admin, it will fail in the long run
>
> make a postfix admin sql cluase that uses amavisd sql data and modify it
>
> then its portable code and can be used longer then my life
>
> just my 2 cent, eh @ :-)
>
>   
Hey,

Thank you for the swift informative reply! :)

Can you explain a little more as I don't code and am not very good with
SQL ?

Thanks again.


Dusty.

Re: [Postfixadmin-devel] postfixadmin-devel@lists.sourceforge.net

[MailingLists <mai...@st...>]

Christian Boltz wrote:
> Hello,
>
> Am Sonntag, 20. Juli 2008 schrieb MailingLists:
>   
>> I sometimes get errors in my mail.log as follows:
>>
>> Jul 20 16:36:12 stoned-hacker amavis[14077]: (14077-07)
>> lookup_sql_field(id) (WARN: no such field in the SQL table),
>> "mai...@st..." result=undef
>>     
>
>   
>> root@stoned-hacker:/var/log# cat /etc/amavis/conf.d/50-user
>>     
> ...
>   
>> $sql_select_policy = 'SELECT domain FROM domain WHERE
>> CONCAT("@",domain) IN (%k)';
>>     
>
> I'm not sure if this is really the cause of the problem. Anyway, you can 
> try    SELECT domain, 1 as id FROM domain WHERE ...
>
> If this doesn't help, grep your whole amavis config for "id".
>
>
> Regards,
>
> Christian Boltz
>   
Well I tried that syntax and I still get the errors :-[

I have ran a grep "id" mail.log for the full errors with debuy log level
turned on in amavis, you may see this log here:

http://stoned-hacker.co.uk/log.txt

Any ideas ?

Thanks for the prompt reply.


Dusty.

Re: [Postfixadmin-devel] postfixadmin-devel@lists.sourceforge.net

[Benny P. <me...@ju...>]

On Sun, July 20, 2008 18:44, MailingLists wrote:

> @lookup_sql_dsn = (
>     ['DBI:mysql:database=postfixadmin;host=127.0.0.1;port=3306',
>      'postfixadm',
>      'aaaaaaaa']);
>
> $sql_select_policy = 'SELECT domain FROM domain WHERE CONCAT("@",domain)
> IN (%k)';

this is not currently supported :(

http://www.ijs.si/software/amavisd/README.sql-mysql.txt

thats the sql setup for amavisd, and we both need it :-)

> Example data follows:

i had something in my mind with this olso so users can select from presets
like this in postfixadmin, and domain owner can add new presets if one
like it, olso maybe if domain owner permit it make it possible for user to
custom policy it in amavisd

if i was better php coder this was done now :/

but dont add amavisd tables to postfix admin, it will fail in the long run

make a postfix admin sql cluase that uses amavisd sql data and modify it

then its portable code and can be used longer then my life

just my 2 cent, eh @ :-)

-- 
Benny Pedersen
Need more webspace ? http://www.servage.net/?coupon=cust37098

Re: [Postfixadmin-devel] postfixadmin-devel@lists.sourceforge.net

[Christian B. <pos...@cb...>]

Hello,

Am Sonntag, 20. Juli 2008 schrieb MailingLists:
> I sometimes get errors in my mail.log as follows:
>
> Jul 20 16:36:12 stoned-hacker amavis[14077]: (14077-07)
> lookup_sql_field(id) (WARN: no such field in the SQL table),
> "mai...@st..." result=undef

> root@stoned-hacker:/var/log# cat /etc/amavis/conf.d/50-user
...
> $sql_select_policy = 'SELECT domain FROM domain WHERE
> CONCAT("@",domain) IN (%k)';

I'm not sure if this is really the cause of the problem. Anyway, you can 
try    SELECT domain, 1 as id FROM domain WHERE ...

If this doesn't help, grep your whole amavis config for "id".


Regards,

Christian Boltz
-- 
[Msg-ID-Fix]   Wenn mich Evolution mehr als ein Furz einer Kuh auf einer
Wiese am anderen Ende von Deutschland interessieren wuerde, dann koennte
ich das sicher locker hinbekommen, die Variable so auszuwerten. ICH WILL
ABER NICHT VERDAMMT NOCH MAL!!!             [David Haller in suse-linux]