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

Re: [Postfixadmin-devel] vacation and spam

[tonio <to...@st...>]

David Goodwin a écrit :
> Martin Ambroz wrote :
>   
>> Pardon, fix ;-) Try this:
>>     
>
>   
>> --- vacation.pl	2007-11-08 17:52:32.000000000 +0100
>> +++ vacation.pl	2007-11-08 17:58:19.000000000 +0100
>> @@ -325,6 +325,7 @@
>>     elsif (/^cc:\s+(.*)\n$/i) { $cc = $1; $lastheader = \$cc; }  
>>     elsif (/^subject:\s+(.*)\n$/i) { $subject = $1; $lastheader = \$subject; }  
>>     elsif (/^message-id:\s+(.*)\n$/i) { $messageid = $1; $lastheader = \$messageid; }  
>> +   elsif (/^x-spam-flag:\s+yes/i) { exit (0); } 
>>     elsif (/^precedence:\s+(bulk|list|junk)/i) { exit (0); }  
>>     elsif (/^x-loop:\s+postfix\ admin\ virtual\ vacation/i) { exit (0); }  
>>     else {$lastheader = "" ; }
>>     
>
>
> Is there any difference between x-spam-flag and x-spam-status?
>
>
> X-Spam-Flag: YES                                                                                                                                            
> X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on $(hostname)
> X-Spam-Level: *****                                                                                                                                         
> X-Spam-Status: Yes, score=5.9 required=5
>
> David.
>
>   
 From SA Wiki:

--
SpamAssassin <http://wiki.apache.org/spamassassin/SpamAssassin> adds the 
headers *X-Spam-Status*, X-Spam-Level, X-Spam-Checker-Version and 
(conditionally) *X-Spam-Flag*;
--




*
***

Re: [Postfixadmin-devel] vacation and spam

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

Martin Ambroz wrote :
> Pardon, fix ;-) Try this:

> --- vacation.pl	2007-11-08 17:52:32.000000000 +0100
> +++ vacation.pl	2007-11-08 17:58:19.000000000 +0100
> @@ -325,6 +325,7 @@
>     elsif (/^cc:\s+(.*)\n$/i) { $cc =3D $1; $lastheader =3D \$cc; } =20
>     elsif (/^subject:\s+(.*)\n$/i) { $subject =3D $1; $lastheader =3D \$s=
ubject; } =20
>     elsif (/^message-id:\s+(.*)\n$/i) { $messageid =3D $1; $lastheader =
=3D \$messageid; } =20
> +   elsif (/^x-spam-flag:\s+yes/i) { exit (0); }=20
>     elsif (/^precedence:\s+(bulk|list|junk)/i) { exit (0); } =20
>     elsif (/^x-loop:\s+postfix\ admin\ virtual\ vacation/i) { exit (0); }=
 =20
>     else {$lastheader =3D "" ; }


Is there any difference between x-spam-flag and x-spam-status?


X-Spam-Flag: YES                                                           =
                                                                           =
     =20
X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on $(hostname)
X-Spam-Level: *****                                                        =
                                                                           =
     =20
X-Spam-Status: Yes, score=3D5.9 required=3D5

David.

--=20
David Goodwin=20

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

Re: [Postfixadmin-devel] vacation and spam

[tonio <to...@st...>]

Martin Ambroz a écrit :
> Pardon, fix ;-) Try this:
>   


Thx a lot ! Works exactly like i wanted.
I think this check is a must have to avoid backscatter mails from 
vacation service.

Thx again for your help

Tonio

Re: [Postfixadmin-devel] vacation and spam

[Martin A. <li...@am...>]

Pardon, fix ;-) Try this:

Re: [Postfixadmin-devel] vacation and spam

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

to...@st... wrote :
> hello,
> i'm wondering if there is a way to add in vacation.pl, a check to =20
> Spamassassin header flag in order to avoid autoreply with spam messages.
>=20


Yes that should be quite easy to do.

I'm tempted to add it into the file, as a quick check - but wonder
whether it would be best if there was some sort of user defined list -
either in a database, or the vacation.pl file itself?

thanks,
David.

--=20
David Goodwin=20

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

[Postfixadmin-devel] vacation and spam

[<to...@st...>]

hello,
i'm wondering if there is a way to add in vacation.pl, a check to  
Spamassassin header flag in order to avoid autoreply with spam messages.

thx for your answers

Tonio

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [188] trunk

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

Christian Boltz wrote :
> Hello,
>=20
> Am Sonntag, 4. November 2007 schrieb Gin...@us...:
> > Revision: 188
>=20
> > debian: adding - initial support for creating .debs; run
> > dpkg-buildpakcage -rfakeroot within the trunk dir
>=20
> So we'll get a debian package. Nice :-)
=20
cd trunk
dpkg-buildpackage -rfakeroot

When ever you want to create a new release, edit debian/changelog

> I'll create RPM files when 2.2 is ready.
=20
Feel free to add the .spec file (that's what rpm uses, right?) to svn.

> I have to admit not to know much about the debian/* files, but I wonder=
=20
> if "docs" and "rules" really need to be executable.

Probably not.

David

--=20
David Goodwin=20

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [188] trunk

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

Hello,

Am Sonntag, 4. November 2007 schrieb Gin...@us...:
> Revision: 188

> debian: adding - initial support for creating .debs; run
> dpkg-buildpakcage -rfakeroot within the trunk dir

So we'll get a debian package. Nice :-)

I'll create RPM files when 2.2 is ready.

> Property changes on: trunk/debian/docs
> ___________________________________________________________________
> Name: svn:executable
>    + *

> Property changes on: trunk/debian/rules
> ___________________________________________________________________
> Name: svn:executable
>    + *

I have to admit not to know much about the debian/* files, but I wonder=20
if "docs" and "rules" really need to be executable.


Regards,

Christian Boltz
=2D-=20
Das terrorsicherste Verkehrsmittel ist ganz klar das Automobil. Einzeln
verpackte Verkehrsteilnehmer in Stahlh=FClle mit gro=DFen Abst=E4nden. :)
[Kristian K=F6hntopp auf
http://blog.koehntopp.de/archives/1376-Mach-mir-den-Rail-Marshall.html]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [178] trunk/DOCUMENTS/SUPERADMIN.TXT

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

> MySQL doesn't have this foreign key, and I don't think it is really=20
> useful.
>=20
> OTOH, Postfix sees the domain "ALL" and will (theoretically) accept=20
> mails on it...
>=20
> I vote for dropping the foreign key in PostgreSQL and then deleting=20
> the "ALL" domain from the database. Both should be done in upgrade.php.

So, presumably a different way is needed to mark an admin as a
global-admin? Do we need a new field in the user table?

I presumed Postfix would never see the field, as it's set to inactive
(in the domain table) - isn't it?

thanks
David.

--=20
David Goodwin=20

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [178] trunk/DOCUMENTS/SUPERADMIN.TXT

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

Hello,

Am Samstag, 3. November 2007 schrieb David Goodwin:
> Christian Boltz wrote :
> > Am Samstag, 3. November 2007 schrieb 
Gin...@us...:
> > > SUPERADMIN.TXT: updating docs
> > >
> > > +(The domain 'ALL' should already exist in the domain table; if
> > > not you'll need to recreate it)
> >
> > Huh? I don't have 'ALL' in my domain table don't see problems.
> > Why do you think it should be added?
>
> Certainly with PostgreSQL, there's a foreign key between
> domain_admins.domain and domain.domain - hence domain.domain = 'ALL'
> needs to exist first.
>
> Perhaps MySQL either doesn't check the fkey, or doesn't have the fkey
> there?

MySQL doesn't have this foreign key, and I don't think it is really 
useful.

OTOH, Postfix sees the domain "ALL" and will (theoretically) accept 
mails on it...

I vote for dropping the foreign key in PostgreSQL and then deleting 
the "ALL" domain from the database. Both should be done in upgrade.php.


Regards,

Christian Boltz
-- 
Linux - Life is too short for reboots

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [178] trunk/DOCUMENTS/SUPERADMIN.TXT

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

Christian Boltz wrote :
> Hello,
> 
> Am Samstag, 3. November 2007 schrieb Gin...@us...:
> > Revision: 178
> > Author:   GingerDog
> 
> > SUPERADMIN.TXT: updating docs
> 
> > +(The domain 'ALL' should already exist in the domain table; if not
> > you'll need to recreate it)
> 
> Huh? I don't have 'ALL' in my domain table don't see problems.
> Why do you think it should be added?
> 

Certainly with PostgreSQL, there's a foreign key between
domain_admins.domain and domain.domain - hence domain.domain = 'ALL'
needs to exist first.

Perhaps MySQL either doesn't check the fkey, or doesn't have the fkey
there?

thanks
David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [178] trunk/DOCUMENTS/SUPERADMIN.TXT

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

Hello,

Am Samstag, 3. November 2007 schrieb Gin...@us...:
> Revision: 178
> Author:   GingerDog

> SUPERADMIN.TXT: updating docs

> +(The domain 'ALL' should already exist in the domain table; if not
> you'll need to recreate it)

Huh? I don't have 'ALL' in my domain table don't see problems.
Why do you think it should be added?


Regards,

Christian Boltz
-- 
Why do you focus so much on _new_ technology? -- New is better. Is
nothink old that is better than new. -- Yes there is. -- Da? Namink
one then. -- The Original Pentium versus counting on your fingers.
-- Da. Da. "Don't divide. Intel inside"  [Sid & Pitr in userfriendly]

Re: [Postfixadmin-devel] Database upgrade (was: (fwd) SF.net SVN: postfixadmin: [170] trunk/upgrade.php)

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

Hello,

Am Freitag, 2. November 2007 schrieb David Goodwin:
> > Simply use CREATE TABLE IF NOT EXISTS ;-)  (given PgSQL supports
> > it).
>
>  Yes, that was my problem - I don't think PostgreSQL does.

:-(

> > I don't know if PgSQL supports the SHOW TABLES command or if we
> > have to read from information schema
> > http://www.postgresql.org/docs/8.2/interactive/infoschema-tables.ht
> >ml
>
> Probably.

You'll need to search for the details - I don't know much about PgSQL 
and had to do lots of searches in the PgSQL documemtation to make the 
SQL commands in upgrade.php as compatible as possibe.

> > Another option is to simply ignore the error ;-)
>
> I couldn't - as db_query was calling 'die()' when it failed.

Seems you used an old revision ;-)))

> > The basic idea is good.
> >
> > However, I change the do_upgrade function to use a classical
> >     for ($i = 1; $i <= 10; $i++)
> > loop and function_exists(). This awoids the need to sort the
> > upgrade functions (which will break when we have >99 functions) ;-)
> > Note that you may not use leading zeros!
>
> Can they not be ordered lexiographically (spelling?) which would fix
> that issue; or alterantively, the script 'casts' the number into
> something with enough leading zeros as required using printf?

Maybe we talk at cross purposes - there is no need to use leading zeros.
This avoids all problems with fixed length. Given we would use fixed 
length: what if we exceed the number the length allows? (Short answer: 
rename _all_ upgrade_* functions.)
Without leading zeroes, it's very easy - there is no limit that we could 
exceed.

The "sorting" of the functions is simply done when editing upgrade.php - 
and if someone adds upgrade_42 between upgrade_2 and upgrade_3, I 
promise to learn how to use the svn revert command ;-))

Running all functions in the correct order is also no problem. If you 
have doubts, try
    for ($i = 1, $i <= 100; $i++) { echo "$i\n"; }

> > I also added the option to create upgrade_<number>_mysql and
> > upgrade_<number>_pgsql functions for database-specific changes.
>
> I thought of that - but decided to not bother splitting it into two
> seperate bits - thinking that if all of a change was in one statement
> it would make it easier to follow. Of course, I could be mistaken
> about this.

This was also my first thought, but then I noticed that
- some changes only affect a specific database type (for example MySQL 
  engine and charset changes)
- some changes need a very different syntax, and it's not always 
  possible to merge into a single query

Therefore I added the _option_ to have database specific functions.
You can (and usually should) use upgrade_<number> for changes that 
affect all database types. 

The _mysql and _pgsql functions are just to avoid the need for checking 
the database type in each function. In this case, I recommend to add a 
comment "# MySQL only" or "# PgSQL only" at the "function ...()" line 
to make it more visible that the function only runs on one database.

[...]
> > There are still several TODO notes in upgrade.php, especially
> > related to PgSQL.
>
> I'll try and resolve these soon.

Have fun - writing the ALTER statements can sometimes be very 
interesting...

> > While talking about database upgrade:
> > I propose we should
> > - create the tables within upgrade.php (maybe we should rename it
> >   ;-) - do all future database changes as ALTER statements within
> >   upgrade.php - the function numbers should always be the SVN
> >   revision numbers of the change
> > - drop DATABASE_*.TXT
> > - remaining question: where do we put the GRANT statements etc.?
> >   Or can we assume that people who run a mailserver know how to
> >   grant database permissions?
> > - drop DOCUMENTS/TABLE_BACKUP_MX.TXT and
> >   DOCUMENTS/TABLE_CHANGES.TXT and remove the references to these
> >   files in DOCUMENTS/UPGRADE.TXT
>
> All good ideas to me. If it's easy enough to write, it does make more
> sense to create the initial database structure from 'upgrade.php' 

We will have to make the database dumps database independent (with 
{whatever} placeholders if needed), but this shouldn't be too hard.

This is the "hardest" part - actually creating the tables simply means 
adding another upgrade_* function. (Having a table_exists() function 
would be nice, but ignoring errors also works.)

While talking about ignoring errors: Maybe we could even check for 
the "usual" error messages and display everything else.

The list of error messages to ignore isn't too long. For MySQL, in RegEx 
format:

   Invalid query: Can't DROP .*; check that column/key exists
     -> Index already dropped

   Invalid query: Duplicate column name .*
     -> column already added

   Invalid query: Unknown column 'change_date' in .*
   Invalid query: Unknown column 'create_date' in .*
     -> renamed columns, listed with name because this shouldn't happen 
        too often

You'll have to find out the PgSQL error messages ;-)

> as well as handling anything else.

Tip: The developer doing a database change can simply paste his ALTER 
TABLE statement (he needs it anyway to change his local database)
to upgrade.php, which is even easier than hand-editing the DATABASE_* 
files.


Regards,

Christian Boltz
-- 
And as Novell has shown with the packager: it's never too late for 
a beta, to add new features ;-)     [Marcel Hilzinger in opensuse]

Re: [Postfixadmin-devel] Database upgrade (was: (fwd) SF.net SVN: postfixadmin: [170] trunk/upgrade.php)

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

> We can use the SVN revision as version to make the update bulletproof 
> (it's too easy to forget to change a $database_level variable ;-)
> 
> Sidenote: I just learned that svn does keyword substitution only if you 
> tell it to do so. A good SVN documentation is on 
> http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html
 
 Yes, that's an excellent manual ! 

> 
> You already know that I like the S9Y database code. I have taken an idea 
> from there: Placeholders like {AUTOINCREMENT}.
 
 Will look later

> 
> Simply use CREATE TABLE IF NOT EXISTS ;-)  (given PgSQL supports it).
 
 Yes, that was my problem - I don't think PostgreSQL does.

> I don't know if PgSQL supports the SHOW TABLES command or if we have to 
> read from information schema 
> http://www.postgresql.org/docs/8.2/interactive/infoschema-tables.html
 

Probably.

> Another option is to simply ignore the error ;-)

I couldn't - as db_query was calling 'die()' when it failed.

> The basic idea is good.
> 
> However, I change the do_upgrade function to use a classical
>     for ($i = 1; $i <= 10; $i++)
> loop and function_exists(). This awoids the need to sort the upgrade 
> functions (which will break when we have >99 functions) ;-)
> Note that you may not use leading zeros!

Can they not be ordered lexiographically (spelling?) which would fix
that issue; or alterantively, the script 'casts' the number into
something with enough leading zeros as required using printf?

> 
> I also added the option to create upgrade_<number>_mysql and 
> upgrade_<number>_pgsql functions for database-specific changes.
 
I thought of that - but decided to not bother splitting it into two
seperate bits - thinking that if all of a change was in one statement it
would make it easier to follow. Of course, I could be mistaken about
this.

> > The only problems with the below is that it can't run on it's own
> > without the table already existing - I can't seem to use
> > db_query($sql) if the table doesn't exist and catch the error. Does
> > this imply db_query($sql) needs updating to return some sort of error
> > code or call trigger_error() instead?
> 
> I have added an optional $ignore_error parameter to db_query ;-)

Cool, thanks.

> I also dived into DOCUMENTATION/* and the SVN log and added all needed 
> update commands to upgrade.php.
 
Excellent.

> There are still several TODO notes in upgrade.php, especially related to 
> PgSQL.
 
I'll try and resolve these soon.

> While talking about database upgrade:
> I propose we should
> - create the tables within upgrade.php (maybe we should rename it ;-)
> - do all future database changes as ALTER statements within upgrade.php
> - the function numbers should always be the SVN revision numbers of the 
>   change
> - drop DATABASE_*.TXT
> - remaining question: where do we put the GRANT statements etc.?
>   Or can we assume that people who run a mailserver know how to grant
>   database permissions?
> - drop DOCUMENTS/TABLE_BACKUP_MX.TXT and DOCUMENTS/TABLE_CHANGES.TXT and
>   remove the references to these files in DOCUMENTS/UPGRADE.TXT
> 


All good ideas to me. If it's easy enough to write, it does make more
sense to create the initial database structure from 'upgrade.php' as
well as handling anything else.

You've been busy!


thanks
David.
-- 
David Goodwin 

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

[Postfixadmin-devel] Database upgrade (was: (fwd) SF.net SVN: postfixadmin: [170] trunk/upgrade.php)

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

Hello,

Am Mittwoch, 31. Oktober 2007 schrieb David Goodwin:
> Below is a quick stab at something that could do the upgrade
> procedure for us.
>
> Namely, every time in the future there is an update to do to the db,
> it goes as a new function in upgrade.php
>
> So... if in 'version' 56 I decide to remove a column, I would do
> something like :

We can use the SVN revision as version to make the update bulletproof 
(it's too easy to forget to change a $database_level variable ;-)

Sidenote: I just learned that svn does keyword substitution only if you 
tell it to do so. A good SVN documentation is on 
http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html

In short:
    svn propset svn:keywords "Revision" upgrade.php

I have done this and hope my next commit will insert the revision 
number.

> function upgrade_56() {
> 	// probably need to switch between database types.

You already know that I like the S9Y database code. I have taken an idea 
from there: Placeholders like {AUTOINCREMENT}.

I added the function db_query_parsed to upgrade.php and inserted the 
placeholders S9Y uses. Please check if the PgSQL strings are valid, and 
correct them if they are not.

> 	// see below.
> 	db_query('alter table add column bar woof foo');
> }
>
> I've missed out the logic to update the config table after an
> upgrade, 

Simply use CREATE TABLE IF NOT EXISTS ;-)  (given PgSQL supports it).

Otherwise, we'll have to check if the table exists.

MySQL:   SHOW TABLES LIKE 'config'

I don't know if PgSQL supports the SHOW TABLES command or if we have to 
read from information schema 
http://www.postgresql.org/docs/8.2/interactive/infoschema-tables.html

Another option is to simply ignore the error ;-)

> but have included the logic not to include the same update 
> twice.
>
> Any comments/observations?

The basic idea is good.

However, I change the do_upgrade function to use a classical
    for ($i = 1; $i <= 10; $i++)
loop and function_exists(). This awoids the need to sort the upgrade 
functions (which will break when we have >99 functions) ;-)
Note that you may not use leading zeros!

I also added the option to create upgrade_<number>_mysql and 
upgrade_<number>_pgsql functions for database-specific changes.

> The only problems with the below is that it can't run on it's own
> without the table already existing - I can't seem to use
> db_query($sql) if the table doesn't exist and catch the error. Does
> this imply db_query($sql) needs updating to return some sort of error
> code or call trigger_error() instead?

I have added an optional $ignore_error parameter to db_query ;-)

I also dived into DOCUMENTATION/* and the SVN log and added all needed 
update commands to upgrade.php.

There are still several TODO notes in upgrade.php, especially related to 
PgSQL.

While talking about database upgrade:
I propose we should
- create the tables within upgrade.php (maybe we should rename it ;-)
- do all future database changes as ALTER statements within upgrade.php
- the function numbers should always be the SVN revision numbers of the 
  change
- drop DATABASE_*.TXT
- remaining question: where do we put the GRANT statements etc.?
  Or can we assume that people who run a mailserver know how to grant
  database permissions?
- drop DOCUMENTS/TABLE_BACKUP_MX.TXT and DOCUMENTS/TABLE_CHANGES.TXT and
  remove the references to these files in DOCUMENTS/UPGRADE.TXT


Regards,

Christian Boltz
-- 
Now I hope the best for my seven 1.44MB disks, oh yes, very old ...
and I feel about 8 years younger by copying files to disks.
[Thomas Porschberg in opensuse]

[Postfixadmin-devel] http://www200.pair.com/mecham/spam/virtual.html

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

Hello Gary,

on http://www200.pair.com/mecham/spam/virtual.html you recommend to use 
revision 1 of postfixadmin and then apply some patches.

I had a quick look at these patches. For me, it looks like some of them 
are already in the current SVN version, but some are not.

If you have patches against current SVN, I'd like to include them. This 
would make it easier for you (you don't need to maintain patches) and 
also for everybody using your howto because updating postfixadmin is 
quite difficult when you have heavily patched it.

Also note that the .htaccess in admin/ is no longer needed because we 
have merged everything into the / directory.

I'm looking forward for your reply.


Regards,

Christian Boltz
Postfixadmin developer
-- 
BUGS
       It is not yet possible to change operating system by writing
       to /proc/sys/kernel/ostype.       -- Linux sysctl(2) manpage

[Postfixadmin-devel] (fwd) SF.net SVN: postfixadmin: [170] trunk/upgrade.php

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

Hi,

Below is a quick stab at something that could do the upgrade procedure
for us.

Namely, every time in the future there is an update to do to the db, it
goes as a new function in upgrade.php

So... if in 'version' 56 I decide to remove a column, I would do
something like :

function upgrade_56() {
	// probably need to switch between database types.
	// see below.
	db_query('alter table add column bar woof foo');
}

I've missed out the logic to update the config table after an upgrade,
but have included the logic not to include the same update twice.

Any comments/observations?

The only problems with the below is that it can't run on it's own
without the table already existing - I can't seem to use db_query($sql)
if the table doesn't exist and catch the error. Does this imply
db_query($sql) needs updating to return some sort of error code or call
trigger_error() instead?

(I've forwarded the svn ci message, so you can see the code as
necessary)


thanks
David
----- Forwarded message from Gin...@us... -----

Added: trunk/upgrade.php
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- trunk/upgrade.php	                        (rev 0)
+++ trunk/upgrade.php	2007-10-31 20:18:53 UTC (rev 170)
@@ -0,0 +1,68 @@
+<?php
+require_once('common.php');
+$sql =3D "SELECT * FROM config WHERE name =3D 'version'";
+
+// create table config (name varchar(20), value varchar(20));
+// insert into config('version', '01');
+// Should really query the db to see if the 'config' table exists first!
+
+$r =3D db_query($sql);
+
+if($r['rows'] =3D=3D 1) {
+    $rs =3D $r['result'];
+    $row =3D db_array($rs);
+    $version =3D $row['value'];
+    _do_upgrade($version);
+}
+
+
+function _do_upgrade($current_version) {
+    $all_functions =3D get_defined_functions();
+    $upgrade_functions =3D array();
+    foreach($all_functions['user'] as $function_name) {
+        if(preg_match('!upgrade_(\d+)!', $function_name, $matches)) {
+            $version =3D $matches[1];
+            if($version <=3D $current_version) {
+                continue;
+            }
+            $upgrade_functions[$matches[1]] =3D $function_name;
+        }
+    }
+
+    ksort($upgrade_functions);
+    foreach($upgrade_functions as $version =3D> $function) {
+        $function();
+    }
+}
+
+function upgrade_00() {
+    global $CONF;
+    if($CONF['database_type'] =3D=3D 'mysql') {
+        echo 'mysql 00';
+    }
+    if($CONF['database_type'] =3D=3D 'pgsql') {
+        echo 'pgsql 00';
+    }
+}
+
+function upgrade_01() {
+    global $CONF;
+    if($CONF['database_type'] =3D=3D 'mysql') {
+        echo 'mysql 01';
+    }
+    if($CONF['database_type'] =3D=3D 'pgsql') {
+        echo 'pgsql 01';
+    }
+}
+function upgrade_02() {
+    global $CONF;
+    if($CONF['database_type'] =3D=3D 'mysql') {
+        echo 'mysql 02';
+    }
+    if($CONF['database_type'] =3D=3D 'pgsql') {
+        echo 'pgsql 02';
+    }
+}
+function upgrade_03() {
+    echo 'woof 03';
+}


This was sent by the SourceForge.net collaborative development platform, th=
e world's largest Open Source development site.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Postfixadmin-svn mailing list
Pos...@li...
https://lists.sourceforge.net/lists/listinfo/postfixadmin-svn

----- End forwarded message -----

--=20
David Goodwin=20

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

Re: [Postfixadmin-devel] confirm 87f3f82968f6c61dcc1f89c540e23dfaa9fa6c7b

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

Hallo Leute,

Am Donnerstag, 1. Januar 1970 schrieb=20
pos...@li...:
> If you reply to this message, keeping the Subject: header intact,
> Mailman will discard the held message.  Do this if the message is
> spam.  If you reply to this message and include an Approved: header
> with the list password in it, the message will be approved for
> posting to the list.  The Approved: header can also appear in the
> first line of the body of the reply.


Regards,

Christian Boltz
=2D-=20
>> die Novell-Webseiten wissen noch gar nichts von SuSE 10
> Irgendwie m=FCssen die geschlafen haben ;-)
Oder wir haben es nur noch nicht gefunden ;-)
[>>Thomas Hertweck, >Christian Boltz u. S=F6ren Wengerowsky in suse-linux]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [167] trunk

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

[forwarded to postfixadmin-devel - postfixadmin-svn is reserved for 
commit messages, -devel is for discussions ;-) ]

----------  Forwarded message  ----------

Subject: Re: SF.net SVN: postfixadmin: [167] trunk
Date: Mittwoch, 31. Oktober 2007
From: David Goodwin <da...@co...>
To: pos...@li...

chr...@us... wrote :
> Revision: 167
>           
http://postfixadmin.svn.sourceforge.net/postfixadmin/?rev=167&view=rev
> Author:   christian_boltz
> Date:     2007-10-30 18:31:37 -0700 (Tue, 30 Oct 2007)
> 
> Log Message:
> -----------
> stylesheet.css
> - added styles for CSS-based dropdown menu, based on "Son of 
Suckerfish"
>   http://www.htmldog.com/articles/suckerfish/dropdowns/
 

Cool :-)
Guess I should take a look later today.

Have you started to do anything wrt database upgrade script(s)?
If not, I might pull my finger out and try writing something.


thanks
David.
-- 
David Goodwin 

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

-------------------------------------------------------

Re: [Postfixadmin-devel] safeget etc

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

Hello,

Am Dienstag, 23. Oktober 2007 schrieb David Goodwin:
> > Note 1:
> > Feel free to use the safeget/safepost/safeserver functions at other
> > places too ;-)
[...]
> It's name (safeget) implies (to me) that it will return something
> safe.... and probably doesn't need to have escape_string applied on
> it. I know this isn't the case.

Hmm, I'm using this function names in some other projects and homepages=20
I'm involved in, and you are the first one who complains about the=20
name ;-)

"safeget" because you won't get any "undefined index" warnings and you=20
have a sane dafault as fallback. (We could also think about including=20
stripslashes if magic_quotes are on.)

Anyhow: If you know better names for these functions, just tell me ;-)

> Would it be more useful to do something like Zend_Filter - namely
> ensuring that a field matches a given type as well.
>
> function safeget($name, $type, $default =3D null)
> or something; so you could ensure you had e.g. an int back?

I usually do this using
    $var =3D (int) safeget('var');

Doing it inside safeget would make things more difficult - it would need=20
some if or case switching. And you never know which types you need and=20
will have to add another type every now and then. (I'm not even talking=20
about values that must validate against a regex etc.)

> > Note 2:
> > $fm_struct in fetchmail.php is a really useful array once you
> > understand how to use it. We should consider to use similar arrays
> > for the other tables (something for after the 2.2 release).
>
> Guess I'll have to read the code sometime then :)

Yes ;-)
Hint: read the comments around the array definition, and then read the=20
template file. Or simply play a bit with the values and reload the=20
fetchmail page in your browser...

> (Sorry I've not done much lately, I'll pull my finger out one day
> soon)

No problem. As long as nobody pays you, nobody can/will force you to do=20
lots of work ;-)


Regards,

Christian Boltz
=2D-=20
> > Wow consensus in less than 24 hours....imagine if it always
> > worked that way....:-)
> Something smells fishy here ;-)
Do you have the solution(tm) for the "Kanzlerfrage"? :)
[>> Peter Flodin, > Andreas J=E4ger und Christoph Thiel in opensuse]

Re: [Postfixadmin-devel] safeget etc

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

<snip>
> Note 1:
> Feel free to use the safeget/safepost/safeserver functions at other=20
> places too ;-)
>=20
>     $var =3D safeget('var');
> is easier to use than
>     $var =3D "";
>     if (isset($_GET['var'])) $var =3D $_GET['var'];
>=20
> Optionally you can specify a default value which will be returned if the=
=20
> $_GET variable is not set:
>     $var =3D safeget('var', 'default');

It's name (safeget) implies (to me) that it will return something
safe.... and probably doesn't need to have escape_string applied on it.
I know this isn't the case.

Would it be more useful to do something like Zend_Filter - namely
ensuring that a field matches a given type as well.

function safeget($name, $type, $default =3D null)
or something; so you could ensure you had e.g. an int back?

>=20
> Note 2:
> $fm_struct in fetchmail.php is a really useful array once you understand=
=20
> how to use it. We should consider to use similar arrays for the other=20
> tables (something for after the 2.2 release).

Guess I'll have to read the code sometime then :)

(Sorry I've not done much lately, I'll pull my finger out one day soon)

Thanks
David.
--=20
David Goodwin=20

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

Re: [Postfixadmin-devel] fetchmail support

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

Hello,

as you might have seen, I have done some changes on fetchmail.php and=20
fetchmail.tpl tonight.

Status:
=2D all SQL queries use escape_string
=2D the layout now looks more postfixadmin-like :-)  (separate editing=20
  page instead of "embedding" it in the list view)
=2D no more "undefined index" warnings (see below)
=2D known bug: adding a new entry is totally broken right now :-(  -=20
  probably I applied too much quoting to the SQL query...
=2D ToDo: insert a domain dropdown to only display fetchmail setup of a=20
  specific domain
=2D ToDo: fetchmail.php and fetchmail.tpl contain lots of tabs which need=20
  to be converted to spaces. I'll do a separate commit just for these=20
  whitespace changes.

Note 1:
=46eel free to use the safeget/safepost/safeserver functions at other=20
places too ;-)

    $var =3D safeget('var');
is easier to use than
    $var =3D "";
    if (isset($_GET['var'])) $var =3D $_GET['var'];

Optionally you can specify a default value which will be returned if the=20
$_GET variable is not set:
    $var =3D safeget('var', 'default');


Note 2:
$fm_struct in fetchmail.php is a really useful array once you understand=20
how to use it. We should consider to use similar arrays for the other=20
tables (something for after the 2.2 release).


Regards,

Christian Boltz
=2D-=20
PS: Achja, Du schuldest mir eine neue Tischplatte... Warum mu=DFte ich=20
heute morgen nur den SuSE-Ordner =F6ffnen? [Helga Fischer in suse-linux]

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin: [106] trunk/templates/admin_edit-admin.tpl

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

Hello,

Am Dienstag, 9. Oktober 2007 schrieb David Goodwin:
> > > Well, we could always bundle mdb2 / pear db with postfixadmin -
> > > this would remove any requirement for admins to set it up etc.
> >
> > I'd like to split this to two questions:
> > a) do we want to use a database abstraction layer?
> > b) which one
> >
> > a) Well, if there's a good and lightweight one available...
> >
> > Let's sum up our database usage:
> > - INSERT and UPDATE queries
> > - DELETE queries
> > - SELECT queries with WHERE and LIMIT
> > - begin/end transaction
> > (did I miss something?)
> >
> > So for me the question is if we need a full-featured abstraction
> > layer or only some simple functions that generate the query.
> >
> > If the abstraction layer adds some hundred kB to the tarball, then
> > we need really good arguments for it IMHO ;-)
>
> I'm not particuarly bothered by the 'size of the tarball' issue.
> Hundreds of kb are pretty in significant.

It's not about filesize, but about complexity. I'd like to understand 
the code I'm using ;-)

> My requirements are :
>
> 1) Support for prepared statements

Basically yes, but it depends on the amount of code we need.
If we need some hundred kB just to be able to replace (pseudocode)
    "... WHERE field='" . db_escape($value) . "'"
with
    "... WHERE field=?"
    execute ($query, $value)
then I would call it too much overhead ;-)

> 2) Support for a url-like database connection

Why/where do you see an anvantage in this point?

> (postfixadmin doesn't (yet) use sequences, so I think these are a non
> issue - but normally something an abstraction layer handles)

What do you mean with "sequences"?

> > b) Good question...
> >
> > Candidates are: (feel free to add missing ones)
> > - mdb2 (requires PEAR, together 420k as .tar.gz)
>
> Most people will already have PEAR.
> Did you include a specific driver in this figure?

No, I just checked the download size of PEAR + mdb2.

> > - pear db (http://pear.php.net/package/DB says it is obsolete and
> > mdb2 should be used)
> > - adodb (470 kB .tar.gz) (proposed by Viktor Gotwig)
> > - adodb lite (370 kB .tar.gz)
>
> Not used adodb.

Search for adodb vs. pear db/mdb2 comparisons, and you'll find several 
people saying adodb and adodb lite are better ;-)

> > - the S9Y (www.s9y.org) database routines, which are simple
> >   (only 8 kB .tar.gz) but effective.
> >   If you want to have a look at it:
> >  
> > http://php-blog.cvs.sourceforge.net/php-blog/serendipity/include/db/

[from the second mail]
> I don't think much of the one above; although it's minimal, it doesn't 
> allow for prepared statements. Do you use S9Y?

Yes, I use S9Y for my blog (http://blog.cboltz.de).

S9Y supports INSERT and UPDATE with field=>value arrays, which is very 
useful.
You are right that it doesn't allow prepared statements (however it 
contains a function to quote a string correctly, and includes a 
function for SELCT ... LIMIT), but OTOH it doesn't add much overhead.

Needless to say that that this is something for post-2.2 ;-)


Regards,

Christian Boltz
-- 
>>Habt Ihr noch alle Tassen im Schrank ?
>Die Referenztassen?
Nun, das Emacs - Referenzfass war jedenfalls nicht gemeint ...
[Christoph Moench-Tegeder und Hans Bonfigt in doc]

Re: [Postfixadmin-devel] Show analyze alias gotos and display?

[Farkas L. <lf...@bp...>]

Christian Boltz wrote:
> Hello,
> 
> Am Freitag, 12. Oktober 2007 schrieb Greg C:
> [...]
>> It is designed to help mail admins to easily see the status of
>> accounts while browsing through multiple pages of aliases and
>> mailboxes, but it will only be helpful where 99% of mail is delivered
>> to local postfix accounts and a handful of other destinations.  If a
>> high percentage of mail is delivered to places like yahoo.com,
>> hotmail.com, gmail.com, or other mail systems, all those domains will
>> be marked as undeliverable or they  have to be added to the
>> exceptions list so they are not flagged.
> 
> Which leads to a feature request from me: can we have another option to 
> only flag aliases that point to non-existing _local_ mailboxes?
> 
>> - what is the show_custom_count?
>>
>>> - what is show_custom_domains?
>>> thanks.
>> show_custom_count is the size of the show_custom_domains array.
> 
> Why don't you simply use   count($show_custom_domains)   ? ;-)
> One error-prone config option less.
> 
> 
> Another note: This should be documented somewhere in SVN. Maybe the best 
> place is directly in config.inc.php ;-)

agree all of the above:-)

-- 
  Levente                               "Si vis pacem para bellum!"

Re: [Postfixadmin-devel] Show analyze alias gotos and display?

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

Hello,

Am Freitag, 12. Oktober 2007 schrieb Greg C:
[...]
> It is designed to help mail admins to easily see the status of
> accounts while browsing through multiple pages of aliases and
> mailboxes, but it will only be helpful where 99% of mail is delivered
> to local postfix accounts and a handful of other destinations.  If a
> high percentage of mail is delivered to places like yahoo.com,
> hotmail.com, gmail.com, or other mail systems, all those domains will
> be marked as undeliverable or they  have to be added to the
> exceptions list so they are not flagged.

Which leads to a feature request from me: can we have another option to 
only flag aliases that point to non-existing _local_ mailboxes?

> - what is the show_custom_count?
>
> > - what is show_custom_domains?
> > thanks.
>
> show_custom_count is the size of the show_custom_domains array.

Why don't you simply use   count($show_custom_domains)   ? ;-)
One error-prone config option less.


Another note: This should be documented somewhere in SVN. Maybe the best 
place is directly in config.inc.php ;-)


Regards,

Christian Boltz
-- 
* Linux Viruscan.....
  Windows 95 found.  Remove it? (y/n)