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

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

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

Greg C wrote:
> This feature examines  the addresses that aliases and mailboxes deliver
> to and will mark them as "undeliverable" if they are sent to
> destinations not on your postfix server (ie, not found in the
> database).  In the case where MOST of the aliases ans mailboxes should
> be delivered locally, it can help you find errors such as typos or an
> alias that delivers to a deleted account.

at the same time it'd be much easier if i can add alias from a pull down
menu or a list to the aliases when i edit alias. imho it'd be good
feature in stead of the current text field.

>     - what is the show_custom_count?
>     - what is show_custom_domains?
>     thanks.
> 
> 
> show_custom_count is the size of the show_custom_domains array. 
> show_custom_domains contains domain names like the
> exchange.ourdomain.com <http://exchange.ourdomain.com> example above. 
> The result is that I can easily identify exchange accounts when browsing
> through mailboxes.

so show_custom_domains is a subset of show_undeliverable_exceptions?

> The undeliverable, POP/IMAP, and custom statuses can be individually
> enabled/disabled.  Maybe only one or two of them make sense for your
> situation and the others can be set to "NO"

this makes things clear (and would be useful to document somewhere:-)

ps. some of our users keep locally his mails but at the same time they
also deliver to some external mail address. so set alias_control to yes.
in this case i edit the mailbox's alias and also add the external
address(es). the above color code get a little bit confusing in this
case. since normal mailbox pop3/imap has a gray box, external address
(eg from show_custom_domains) has lightblue box. but in this case imho
both lightblue _and_ gray box should have to be there, but only
lightblue is present.

-- 
  Levente                               "Si vis pacem para bellum!"

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

[Greg C <ag...@gm...>]

On 10/12/07, Farkas Levente <lf...@bp...> wrote:
>
> hi,
> i already ask it on the forum but didn't get any answer:-(
> what is this show_status and how does it works? there is a short
> description in the conf file, but it's not enough for me:-( so how does
> this things supposed to work?


This feature examines  the addresses that aliases and mailboxes deliver to
and will mark them as "undeliverable" if they are sent to destinations not
on your postfix server (ie, not found in the database).  In the case where
MOST of the aliases ans mailboxes should be delivered locally, it can help
you find errors such as typos or an alias that delivers to a deleted
account.

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.

- what is show_undeliverable_exceptions?


There may be some delivery destinations that  do not appear in your
database, but are valid destinations for your situation.  The code will only
look for the domains specified in show_undeliverable_exceptions, as it
cannot verify the username at that domain.  For example, our postfix server
delivers many mailboxes to a MS exchange server.   The exchange server is
called exchange.ourdomain.com and we deliver mailboxes to
us...@ex....  I added exchange.ourdomain.com to the
exceptions list so those accounts aren't flagged as undeliverable.


- what is the show_custom_count?
> - what is show_custom_domains?
> thanks.


show_custom_count is the size of the show_custom_domains array.
show_custom_domains contains domain names like the
exchange.ourdomain.comexample above.  The result is that I can easily
identify exchange accounts
when browsing through mailboxes.


The undeliverable, POP/IMAP, and custom statuses can be individually
enabled/disabled.  Maybe only one or two of them make sense for your
situation and the others can be set to "NO"


> --
>   Levente                               "Si vis pacem para bellum!"
>
> -------------------------------------------------------------------------
> 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-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>

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

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

hi,
i already ask it on the forum but didn't get any answer:-(
what is this show_status and how does it works? there is a short
description in the conf file, but it's not enough for me:-( so how does
this things supposed to work?
- what is show_undeliverable_exceptions?
- what is the show_custom_count?
- what is show_custom_domains?
thanks.

-- 
  Levente                               "Si vis pacem para bellum!"

Re: [Postfixadmin-devel] database setup

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

David Goodwin wrote:
> Farkas Levente wrote :
>> hi,
>> i wouldn't like to go into the detailed discussion of database. just a
>> few of my thoughts:
>> - i would like to keep all of my database utf-8. otherwise always
>> happened something wrong.
>> - i don't like innodb since it creates a never ending growing files.
> 
> Can you provide more details on this - I've used innodb at work, and
> never had a problem with it - it certainly hasn't used up all available
> disk space!
> 
> Innodb is far better than MyISAM for a number of reasons - e.g.
> transactions, acid compliance, foreign key support etc.
> The _only_ reason you'd ever want to use MyISAM is for quick selects, or
> if you want full text indexing (afaik). We don't need either, so it's
> not a problem.
> 
> Innodb also doesn't do table level locking, which is probably a good
> thing as the vacation tables are the only ones which are likely to
> experience a lot of read/write traffic - all other tables are
> effectively 'read-only' for the vast majority of the time.
> 
> (I hope that makes sense... I'm just pointing out that I think innodb is
> a good choice for the vacation tables).

i know all the above except the file in /var/lib/mysql which holds the
database never get shorter. even if you delete all the tables. that's
way most people not like it. of course if the whole history (from the
creation and all changes) of the database is not too long than you not
recognize it.

>> - i like to use mysql.
>> probably the best choice would be falcon, but the it'll be released only
>> next year. so i don't know the solution but something better then the
>> current.
> 
> We wouldn't be able to support falcon for some time - as Christian says
> - partly because it'll take ~ 6 months for Linux distributions to catch
>   up and ship with it, and partly because there will be a number of
>   people not using the latest version of MySQL, who won't want to
>   upgrade.
> 
> I thought Falcon is mostly a replacement for Innodb, to remove any 
> dependence on Oracle - in our situation, would it bring any new
> functionality above innodb?

i hope it won't an all the time increasing file.

-- 
  Levente                               "Si vis pacem para bellum!"

Re: [Postfixadmin-devel] database setup

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

Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 11. Oktober 2007 schrieb Farkas Levente:
>> i wouldn't like to go into the detailed discussion of database. just
>> a few of my thoughts:
>> - i would like to keep all of my database utf-8. otherwise always
>> happened something wrong.
> 
> Can you define "something wrong happened", please?
> I agree we need to use utf8 on fields like "description" which can 
> contain text in any language.
> 
> However, fields like "domain" and "email" should be latin1 to avoid the 
> utf8 overhead. Or do you really use utf8 in domain names and mail 
> adresses? (I even doubt it is allowed.)

i agree with that IF the database is utf-8 and those char field which
are not needed to be utf-8 are latin1, but i prefer this way and not the
opposite when the database it latin1 and some field are utf-8!

>> - i don't like innodb since it creates a never ending growing files.
> 
> I never tested innodb in detail, but if this really happens, I would 
> consider it worth a bugreport against MySQL (unless it is expected 
> behaviour or a known bug ;-)

it's well know imho you can find it after some google:-(

> BTW: The reason why InnoDB is used is the foreign key with automatic 
> cleanup (DELETE CASCADE). Maybe we could do it manually instead.

i understand the reasons i just tell my preferences.

>> probably the best choice would be falcon, but the it'll be released
>> only next year. 
> 
> That's too late - and we want to have the least-possible requirements.
> (In other words: we'll wait a year or two after release until we use 
> falcon.)

or we can define an alternative/testing database setup for falcon.

-- 
  Levente                               "Si vis pacem para bellum!"

Re: [Postfixadmin-devel] database setup

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

Farkas Levente wrote :
> hi,
> i wouldn't like to go into the detailed discussion of database. just a
> few of my thoughts:
> - i would like to keep all of my database utf-8. otherwise always
> happened something wrong.
> - i don't like innodb since it creates a never ending growing files.

Can you provide more details on this - I've used innodb at work, and
never had a problem with it - it certainly hasn't used up all available
disk space!

Innodb is far better than MyISAM for a number of reasons - e.g.
transactions, acid compliance, foreign key support etc.
The _only_ reason you'd ever want to use MyISAM is for quick selects, or
if you want full text indexing (afaik). We don't need either, so it's
not a problem.

Innodb also doesn't do table level locking, which is probably a good
thing as the vacation tables are the only ones which are likely to
experience a lot of read/write traffic - all other tables are
effectively 'read-only' for the vast majority of the time.

(I hope that makes sense... I'm just pointing out that I think innodb is
a good choice for the vacation tables).

> - i like to use mysql.
> probably the best choice would be falcon, but the it'll be released only
> next year. so i don't know the solution but something better then the
> current.

We wouldn't be able to support falcon for some time - as Christian says
- partly because it'll take ~ 6 months for Linux distributions to catch
  up and ship with it, and partly because there will be a number of
  people not using the latest version of MySQL, who won't want to
  upgrade.

I thought Falcon is mostly a replacement for Innodb, to remove any=20
dependence on Oracle - in our situation, would it bring any new
functionality above innodb?

thanks,

David.
--=20
David Goodwin=20

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

[Postfixadmin-devel] Easier translation

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

Hello,

@Francois: If you haven't started the french translation yet, please use=20
the attached file as base. It will save you some time because it=20
already contains the english strings.

@all
=46YI: I have written a script to make translations easier.
Basically, it checks a language file for missing texts and pastes the=20
english texts (with a comment added) into the language file.

Well, that's the theory. Practise is a bit more difficult and resulted=20
in an quite interesting bash script ;-)

This method has some advantages:
=2D translators don't need to check against en.lang, they just have to=20
  check for the "# XXX" comments
=2D we don't need to include en.lang by default (as fallback) because each=
=20
  language file contains all texts (some in english though)

I'll attach fr.lang as an example. Please check if this file is OK
(it should only have lines added, when compared with the SVN version).

If nobody complains, I'll update all language files and commit them to=20
SVN. I'll also add my script to SVN.


Regards,

Christian Boltz
=2D-=20
> Ich komme ja nicht aus dem Norden, aber gilt da nicht dieser Spruch:
> "Hamburg ist das Tor zur Welt, aber Bremen hat den Schl=FCssel dazu."
Stimmt. Aber damit k=F6nnen die nichts anfangen, weil Hamburg weltoffen
ist :-)         [> Martin R=F6hricht und Thorsten K=F6rner in suse-linux]

Re: [Postfixadmin-devel] database setup

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

Hello,

Am Donnerstag, 11. Oktober 2007 schrieb Farkas Levente:
> i wouldn't like to go into the detailed discussion of database. just
> a few of my thoughts:
> - i would like to keep all of my database utf-8. otherwise always
> happened something wrong.

Can you define "something wrong happened", please?
I agree we need to use utf8 on fields like "description" which can 
contain text in any language.

However, fields like "domain" and "email" should be latin1 to avoid the 
utf8 overhead. Or do you really use utf8 in domain names and mail 
adresses? (I even doubt it is allowed.)

> - i don't like innodb since it creates a never ending growing files.

I never tested innodb in detail, but if this really happens, I would 
consider it worth a bugreport against MySQL (unless it is expected 
behaviour or a known bug ;-)

BTW: The reason why InnoDB is used is the foreign key with automatic 
cleanup (DELETE CASCADE). Maybe we could do it manually instead.

> - i like to use mysql.

I also ;-)

> probably the best choice would be falcon, but the it'll be released
> only next year. 

That's too late - and we want to have the least-possible requirements.
(In other words: we'll wait a year or two after release until we use 
falcon.)

> so i don't know the solution but something better then the current.

:-(


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] database setup

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

hi,
i wouldn't like to go into the detailed discussion of database. just a
few of my thoughts:
- i would like to keep all of my database utf-8. otherwise always
happened something wrong.
- i don't like innodb since it creates a never ending growing files.
- i like to use mysql.
probably the best choice would be falcon, but the it'll be released only
next year. so i don't know the solution but something better then the
current.

-- 
  Levente                               "Si vis pacem para bellum!"

Re: [Postfixadmin-devel] Database scheme and upgrade

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

Hello,

Am Donnerstag, 11. Oktober 2007 schrieb Christian Boltz:
> Using InnoDB seems to cause some technical problems [...]

There's also another issue: DELETE CASCADE requires that both tables -=20
vacation and vacation_notification are in InnoDB format.
If the vacation table is still a MyISAM table, the CREATE TABLE=20
vacation_notification will fail with error #1005/errno 150.

We also have to ensure that the corresponding columns in both tables=20
have the same type, length, charset etc. (Using an ID column would make=20
this a bit easier.)

Note to myself:=20
    ALTER TABLE vacation ENGINE =3D InnoDB;
should work.


Regards,

Christian Boltz
=2D-=20
> [KDE-Update] Also meine Uhr sieht exakt so aus wie vorher
> (ohne da=DF ich an den Einstellungen was gemacht h=E4tte)
Meine Uhr sieht st=E4ndig anders aus. Dauernd andere Zahlen.
[> Christoph Maurer und Bernd Brodesser in suse-linux]

Re: [Postfixadmin-devel] Fwd: Re: Fwd: postfixadmin with latest PGSQL (8.2.4)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


>> a) a unique idenfier is added to the mail body, and users can either
>> click on a link or forward the mail to spam@domain to train
>> spamassassin as appropriate.
> 
> Beware that doing this training (especially if people don't really know 
> what they are doing) can make spam detection worse - at least some 
> people on the german postfixbuch-users list reported this.
> 

Yes.. the awkwardness would come in that the identifier would need to be
removed from emails going out of the organisation....

>> or
>>
>> b) List all recent emails (e.g. the last 7 days worth) allowing users
>> to say "Yes- that, that that and that were spam".
> 
> Sounds like Maya Mailguard. I don't really want to re-invent this 
> wheel - if you need this feature, you should use Maya.

Ah. I'll have a look at that. I've not head of it.
( http://www.maiamailguard.com )

> Yes. However, I'd vote to add (<ul>- and CSS-based) dropdown menus with 
> the "add ...." link.
>

Fine by me

David.

- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHDeHo/ISo3RF5V6YRAhFeAKC2u8SSAKmQvMix0m3LzzSNd93HCwCgluDU
E8j54RgCGBjIUzCFbbTSxsE=
=0+Ax
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Fwd: Re: Fwd: postfixadmin with latest PGSQL (8.2.4)

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

Hello,

Am Freitag, 5. Oktober 2007 schrieb David Goodwin:
> Sounds very interesting; I've been meaning to add some sort of
> spamassassin integration where either :
>
> a) a unique idenfier is added to the mail body, and users can either
> click on a link or forward the mail to spam@domain to train
> spamassassin as appropriate.

Beware that doing this training (especially if people don't really know 
what they are doing) can make spam detection worse - at least some 
people on the german postfixbuch-users list reported this.

> or
>
> b) List all recent emails (e.g. the last 7 days worth) allowing users
> to say "Yes- that, that that and that were spam".

Sounds like Maya Mailguard. I don't really want to re-invent this 
wheel - if you need this feature, you should use Maya.

> > > >>> and more handy admin_menu.tpl.
>
> I think the menu could change to something like :
>
> 'List Virtual'
> 'List Domains'
> 'List Admins'
> 'List Vacations' (?)
>
> and have the related add/edit/remove links in the list-XXX.php
> page.

Yes. However, I'd vote to add (<ul>- and CSS-based) dropdown menus with 
the "add ...." link.


Regards,

Christian Boltz
-- 
> Can I get some more info from the machine? 'dmesg', 'cat
> /proc/bus/input/devices', etc ...
Sorry, there's no command calles "etc" on my machine... ;-)
[Rasmus Plewe on https://bugzilla.novell.com/show_bug.cgi?id=176022]

[Postfixadmin-devel] Database scheme and upgrade

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

Hello,

short summary: The database scheme has some flaws currently.=20
Besides that, we need a method to do upgrades from 2.1 to SVN. See also
https://sourceforge.net/forum/forum.php?thread_id=3D1838084&forum_id=3D6760=
76


Long version:

Note that I'll mostly cover MySQL in this mail, because I don't know=20
much about PostgreSQL.

a) database scheme
~~~~~~~~~~~~~~~~~~

The vacation and vacation_notification tables have all fields set to=20
utf8 by default. This causes problems with index length etc. (one utf8=20
character needs 3 bytes!)
We should only make fields utf8 that may contain non-ascii data.
Especially "email" and "domain" should NOT be utf8.

OTOH, the other tables do not have any utf8 field. At least the=20
description field should be utf8.

=46or anyone not knowing the disadvantages of using utf8 unconditionally=20
(and everybody who wants to learn more on charset handling in MySQL in=20
general), here's an interesting article:
http://mysqldump.azundris.com/archives/60-Handling-character-sets.html=20


The "default '0000-00-00 00:00:00'" on datetime fields seems to cause=20
problems with MySQL strict mode. See this tracker entry:
https://sourceforge.net/tracker/index.php?func=3Ddetail&aid=3D1699218&group=
_id=3D191583&atid=3D937964

AFAIK it's possible to default to "now()" (needs testing on MySQL 4.x),=20
but we can also use real NULLs.


Using InnoDB seems to cause some technical problems, according to the=20
forum post:=20
https://sourceforge.net/forum/forum.php?thread_id=3D1838084&forum_id=3D6760=
76

The reasons why InnoDB is used in the vacation table currently are
=2D too long primary key (see utf8 issues above)
=2D DELETE CASCADE - could be replaced with an explicit DELETE command for=
=20
  vacation_notification


Another issue is that all tables have the mail address as primary key.=20
This is a) not recommended (I don't remember the details, sorry) and b)=20
makes it difficult to secure Postfixadmin because parameter checking is=20
difficult.

The better solution would be to add an "ID" column as auto_increment and=20
make the mail address an UNIQUE index.


b) database upgrade
~~~~~~~~~~~~~~~~~~~

In general: We should offer a way to upgrade a 2.1 database to SVN=20
version and any future release. Yes, this means not only 2.1 -> 2.2=20
updates, but each small change in SVN.

Possible method:
=2D revert all changes in DATABASE_MYSQL.TXT since 2.1 release
=2D instead, create ALTER TABLE statements for each change
=2D these ALTER TABLE statements should be executed by setup.php
  (it could also create the initial database, but that's another story)
=2D create an additional table that keeps the "database version" so that=20
  we always know which ALTER TABLE statements have to be executed.
=2D check the database version in login.php and print a warning if it's=20
  outdated

S9Y uses a similar method, and I never had problems with database=20
upgrades. See these files:
http://svn.berlios.de/wsvn/serendipity/trunk/include/admin/upgrader.inc.php=
?op=3Dfile&rev=3D0&sc=3D0
http://svn.berlios.de/wsvn/serendipity/trunk/include/functions_upgrader.inc=
=2Ephp?op=3Dfile&rev=3D0&sc=3D0


The Typo3 method would also be nice, but I'm afraid the initial=20
implementation needs too much work (we probably can't just use some=20
functions from the Typo3 framework, would be too easy ;-)

=46or those who don't know Typo3, I'll describe the used method:
=2D Typo3 ships with the latest sqldump
=2D the code compares the current database ("SHOW CREATE TABLE") with the=20
  sqldump and creates ALTER TABLE statements to update the database

If someone knows a good standalone tool (PHP or perl) that does this,=20
please point it out NOW.


c) general issues
~~~~~~~~~~~~~~~~~

The SQL dump should NOT
=2D GRANT anything (maybe the user uses another username etc) - it's easy=20
  to setup a new user with phpMyAdmin if someone is not familar with the=20
  mysql command line
=2D contain "USE postfix" - the database name can differ as well. Just=20
  remove this line and let the user specify the database name at the=20
  mysql commandline.
=2D contain any "DROP TABLE IF EXISTS" statements
=2D Even hardcoded table names might be a problem - at least we allow to=20
  change them in $CONF. However, I don't consider this one a real=20
  problem.


Regards,

Christian Boltz
=2D-=20
Tut mir leid. Tu hast dich daf=FCr entschieden,  Computer zu benutzen. Aus
irgendeinem Grunde glaubst du,  das sei risikofrei.  Ich versichere dir,
da=DF es das nicht ist. Computer sind b=F6se, rostige, alte Kettens=E4gen, =
die
grundlos anspringen.   [Ratti in suse-linux]

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

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

> - 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/
=20
I don't think much of the one above; although it's minimal, it doesn't allo=
w=20
for prepared statements. Do you use S9Y?


David.
--=20
David Goodwin=20

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

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

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

> > > Would be an idea. However, we'll need a way to handle existing
> > > unencrypted passwords.
> >
> > That could be done through some  sort of generic 'upgrade' script -
> > which it appears we'll need....
>=20
> Let's declare this problem minor when compared with database updates in=
=20
> general ;-)

Indeed, and that specific problem is a non-issue now anyway.

> > > > My grievance with this is that when ever an admin is edited, I
> > > > think your previous patch, implied that a users password had to
> > > > be changed/set. Which is horrible.
> > >
> > > No, the password does not need to be touched. See my change in
> > > r123:
> >
> > OK.
>=20
> Will you commit this or shall I do it?

I've made the change in my checked out copy, but need to test it (I
didn't get a chance last night). So, if you beat me to it, so be it.

> >
> > Well, we could always bundle mdb2 / pear db with postfixadmin - this
> > would remove any requirement for admins to set it up etc.
>=20
> I'd like to split this to two questions:
> a) do we want to use a database abstraction layer?
> b) which one
>=20
> a) Well, if there's a good and lightweight one available...
>=20
> 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?)
>=20
> So for me the question is if we need a full-featured abstraction layer=20
> or only some simple functions that generate the query.
>=20
> If the abstraction layer adds some hundred kB to the tarball, then we=20
> need really good arguments for it IMHO ;-)
=20
I'm not particuarly bothered by the 'size of the tarball' issue.
Hundreds of kb are pretty in significant.

My requirements are :

1) Support for prepared statements
2) Support for a url-like database connection

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

> b) Good question...
>=20
> 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?

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

Not used adodb.

> - 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/

I'll try and take a look later; my web browser seems to be acting up at
the moment for some unknown reason :-/

David.
--=20
David Goodwin=20

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

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

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

Hello,

Am Sonntag, 7. Oktober 2007 schrieb David Goodwin:
> > > As these are the passwords for the admin user, how about we
> > > change is so admin passwords are _always_ encrypted with
> > > something decent? As admin passwords aren't used for mailboxes,
> > > it wouldn't have any impact outside of postfixadmin.
> >
> > Would be an idea. However, we'll need a way to handle existing
> > unencrypted passwords.
>
> That could be done through some  sort of generic 'upgrade' script -
> which it appears we'll need....

Let's declare this problem minor when compared with database updates in 
general ;-)

> > > My grievance with this is that when ever an admin is edited, I
> > > think your previous patch, implied that a users password had to
> > > be changed/set. Which is horrible.
> >
> > No, the password does not need to be touched. See my change in
> > r123:
>
> OK.

Will you commit this or shall I do it?

> > > If we're thinking of older ones, then we'd have to use
> > > something like PEAR::DB or PEAR::MDB2 - which emulate
> > > prepared-statement-ness.
> >
> > Ah, the old question of using an abstraction layer. I'm still not
> > sure if we really need it - but having some helper functions (for
> > example insert("table", array ("field1" => "value1", "field2" =>
> > "value2") that create database statements might be a good idea.
>
> 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 ;-)

b) Good question...

Candidates are: (feel free to add missing ones)
- mdb2 (requires PEAR, together 420k as .tar.gz)
- 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)
- 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/


Regards,

Christian Boltz
-- 
Fsck, I'm remembering back to the pre-archived-by-Google era of Usenet;
some local newbie was asking how to compile RM COBOL programs in the
Unix environment, and my anti-COBOL bias might have shown through as I
explained that the RM COBOL compiler on Unix was named "rm".     [AdB]

[Postfixadmin-devel] fetchmail support

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

Hello,

Viktor Gotwig (info AT symateam.de) has sent me a patch to add fetchmail=20
support to Postfixadmin. I just commited the major parts of it. The=20
only thing I left out is the menu entry (templates/menu.tpl)
   <li><a target=3D"_top" href=3D"fetchmail.php">
      <?php print $PALANG['pMenu_fetchmail']; ?></a></li>
which should be wrapped by a nice "if ($CONF[fetchmail_whatever'])".

=46or now, you have to type fetchmail.php in your browser to use the=20
script.

The original patch (against 2.1) is attached to this mail; I had to do=20
some minor changes to make it work with the SVN version.

This is the original mail Viktor sent me:
(some additional comments are listed below)

=2D---------  Weitergeleitete Nachricht  ----------

Betreff: postfixadmin 2.1.0
Datum: Montag, 24. September 2007
Von: Viktor Gotwig
An: Christian Boltz

Hello mister Boltz,

I have taken some improvements on postfixadmin-2.1.0 to add an fetchmail
interface. May be, you can also reuse it.

Many small/middle companies have only an dynamical IP connection to the
internet (DSL etc.) and are not able directly receive their emails from
outside with postfix. Fetchmail is very handly, but does not have some
possibility for an sql configuration.

My approach was to run an cronjob "job.pl" (each 5 minutes), that create
an .fetchmailrc configuration on the fly for each account, runs
"fetchmail" with that and saves returned text protocol message from
fetchmail back into the table.

Security things:
1) the file .fetchmailrc does not contains passwords or another sensible
data from different users at a time,
2) it will be deleted at the end of cron job,
3) the passwords are stored base64-encoded to protect against accident
read/remember by administrators working on the DB. Is of course not
secure, helps against accidents only.

ToDo for me: the fetchmail option "MDA" is not tested yet. We plan to
write some custom email filter scripts, it may be conveniently to use
that option here.

Thanks a lot for the program, it is really very useful. Sorry for
perhaps to quick and dirty code, I have had very little time for that.
And polite request to you: Please find some time to check/protect the
code against sql injections, there are really a lot of places in code
where injections are possible.

I will be like to hear something from you :)


Good luck,

Viktor.

P.S. For the info: I have already send this patch to mister Peters
(because their email address was first that I found on some source
files), but he answered not to work on this project any more.
=2D------------------------------------------------------

Additions from some later mails (in german, therefore not quoted here):

"legal"
=2D he has allowed to publish his code/patch under GPL
=2D we are allowed to do any change we find useful
=2D he would be happy if we list his name somewhere[tm]

technical:
=2D the "Extra options" and "MDA" can be dangerous (example MDA=20
  "rm -rf /") - so these fields should be locked unless a special
  $CONF setting is enabled.
  Another option would be to offer some options in a dropdown list,
  populated by a config.inc.php setting.
=2D the user interface differs from the current Postfixadmin style (try=20
  yourself ;-)  (yes, we should change it to follow the current=20
  Postfixadmin style)
=2D fetchmail.tpl uses an interesting method to call helper functions,
  judge yourself (I'll add my opition later)
=2D known bug: several "undefined offset" and "undefined index" notices
=2D the database definition for fetchmail currently resides in a comment
  in fetchmail.php
=2D lots of strings are not translatable yet


Regards,

Christian Boltz
=2D-=20
> > Ich habe auf diese Soap Opera hier eigentlich keine Lust...
> Dann mach Deinen Rechner aus, das Fenster auf und bef=F6rdere diesen
> aus dem selbigen.
wieso Fenster auf?
[>> su...@ni..., > Michael Raab und Michael Schulz in suse-linux]

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

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

> > As these are the passwords for the admin user, how about we change is
> > so admin passwords are _always_ encrypted with something decent? As
> > admin passwords aren't used for mailboxes, it wouldn't have any
> > impact outside of postfixadmin.
>=20
> Would be an idea. However, we'll need a way to handle existing=20
> unencrypted passwords.
>=20

That could be done through some  sort of generic 'upgrade' script -
which it appears we'll need....

> > My grievance with this is that when ever an admin is edited, I think
> > your previous patch, implied that a users password had to be
> > changed/set. Which is horrible.
>=20
> No, the password does not need to be touched. See my change in r123:
>=20

OK.

> > If we're thinking of older ones, then we'd have to use=20
> > something like PEAR::DB or PEAR::MDB2 - which emulate
> > prepared-statement-ness.
>=20
> Ah, the old question of using an abstraction layer. I'm still not sure=20
> if we really need it - but having some helper functions (for example
>     insert("table", array ("field1" =3D> "value1", "field2" =3D> "value2")
> that create database statements might be a good idea.
>=20

Well, we could always bundle mdb2 / pear db with postfixadmin - this
would remove any requirement for admins to set it up etc.

> > I added a min_password_length config setting in.... which should help
> > too ($CONF['min_password_length'])
>=20
> Yes, I already hit this in the test installation on my laptop ;-) (which=
=20
> doesn't need strong passwords - it's not connected to Postfix at all).

Note minor change to config.inc.php[.sample]

David.
--=20
David Goodwin=20

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

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

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

Hello,

Am Freitag, 5. Oktober 2007 schrieb David Goodwin:
> > > > I consider it security-critical to include the password in the
> > > > HTML code (browser cache etc.). Luckily, this code seems to be
> > > > buggy - at least, it never included the password for me.
> > >
> > > Ah, it should say $tPassword. I'd never intentionally display the
> > > unencrypted password in the form.
> >
> > This isn't really better - if someone uses unencrypted passwords,
> > there will be a cleartext password again.
>
> Ah, bugg-rit. I'd forgotten about that 'feature'
>
> As these are the passwords for the admin user, how about we change is
> so admin passwords are _always_ encrypted with something decent? As
> admin passwords aren't used for mailboxes, it wouldn't have any
> impact outside of postfixadmin.

Would be an idea. However, we'll need a way to handle existing=20
unencrypted passwords.

> > The correct and secure solution is not to insert the password at
> > all.
>
> My grievance with this is that when ever an admin is edited, I think
> your previous patch, implied that a users password had to be
> changed/set. Which is horrible.

No, the password does not need to be touched. See my change in r123:

=2D-- admin/edit-admin.php        (Revision 107)
+++ admin/edit-admin.php        (Revision 123)
@@ -89,2 +89,5 @@
=2D      $result =3D db_query ("UPDATE $table_admin SET=20
modified=3DNOW(),active=3D'$sqlActive', password=3D'$fPassword' WHERE=20
username=3D'$username'");
=2D
+      $password_query =3D '';
+      if ($fPassword !=3D '') { # do not change password to empty one
+         $password_query =3D ", password=3D'$fPassword'";
+      }
+      $result =3D db_query ("UPDATE $table_admin SET=20
modified=3DNOW(),active=3D'$sqlActive' $password_query WHERE=20
username=3D'$username'");


In short: If no password was entered, do not touch it in the UPDATE=20
query (the $password_query part is empty in this case).

> > > <Smarty + Prepared statements would make me very happy />
> >
> > I don't know Smarty good enough to add a statement, but I'm afraid
> > it would add some overhead. There are other ways to make the
> > templates easier...
>
> To which I'd say :
>
> 1) Postfixadmin isn't going to be in a high demand, zillions of users
> style situation, so performance doesn't matter (that much!)

;-)

> 2) Using Smarty would stop the automatic spread of variables from the
> controller to the view - which would make it far more obvious what is
> given to the view layer, and what isn't.

Hmm, there are other ways to reach this goal. I don't say that Smarty is=20
bad, but you can reach _this_ goal by putting the templates into=20
functions or classes.

Anyway: The templates need a big cleanup first. Maybe I can even make a=20
nice render_table() function for all the list-* pages...

> 3) We can tell Smarty to sanitise all data it displays by default,
> rather than us having to run htmlentities everywhere, so we can stop
> XSS/HTML injection like problems very easily.

I'd say this is also solvable with functions or classes - you can=20
sanitize all parameters when calling the function ;-)

> > Prepared statements would be a good idea - we would get rid of SQL
> > injections easily.
>
> Indeed. Question is, what version(s) of PHP/MySQL to we need to
> support.=20

I checked php.net about this. If I didn't miss something, PHP does not=20
provide a prepare / execute for MySQL. We would have to use the MySQL=20
PREPARE and EXECUTE statements as query manually.

=46or pgsql prepared statement support was added in PHP 5.1.

> If we're thinking of older ones, then we'd have to use=20
> something like PEAR::DB or PEAR::MDB2 - which emulate
> prepared-statement-ness.

Ah, the old question of using an abstraction layer. I'm still not sure=20
if we really need it - but having some helper functions (for example
    insert("table", array ("field1" =3D> "value1", "field2" =3D> "value2")
that create database statements might be a good idea.

> I added a min_password_length config setting in.... which should help
> too ($CONF['min_password_length'])

Yes, I already hit this in the test installation on my laptop ;-) (which=20
doesn't need strong passwords - it's not connected to Postfix at all).


BTW: You are signing your mails with the 0x908C915875DBE8EF key, but=20
this key is not available at the keyservers. Is this intentional or did=20
you just forget to upload it?


Regards,

Christian Boltz
=2D-=20
[PDF] Fipptehler korrigiert -- wie konnten wir das bisher uebersehen ;)
=2D <xsl:if test=3D"position()=3D1">Sch=FCsselworte: </xsl:if>
+ <xsl:if test=3D"position()=3D1">Schl=FCsselworte: </xsl:if>
[David Haller in suse-linux-faq]

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

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

Hello,

Am Freitag, 5. Oktober 2007 schrieb David Goodwin:
> > > > I consider it security-critical to include the password in the
> > > > HTML code (browser cache etc.). Luckily, this code seems to be
> > > > buggy - at least, it never included the password for me.
> > >
> > > Ah, it should say $tPassword. I'd never intentionally display the
> > > unencrypted password in the form.
> >
> > This isn't really better - if someone uses unencrypted passwords,
> > there will be a cleartext password again.
>
> Ah, bugg-rit. I'd forgotten about that 'feature'
>
> As these are the passwords for the admin user, how about we change is
> so admin passwords are _always_ encrypted with something decent? As
> admin passwords aren't used for mailboxes, it wouldn't have any
> impact outside of postfixadmin.

Would be an idea. However, we'll need a way to handle existing=20
unencrypted passwords.

> > The correct and secure solution is not to insert the password at
> > all.
>
> My grievance with this is that when ever an admin is edited, I think
> your previous patch, implied that a users password had to be
> changed/set. Which is horrible.

No, the password does not need to be touched. See my change in r123:

=2D-- admin/edit-admin.php        (Revision 107)
+++ admin/edit-admin.php        (Revision 123)
@@ -89,2 +89,5 @@
=2D      $result =3D db_query ("UPDATE $table_admin SET=20
modified=3DNOW(),active=3D'$sqlActive', password=3D'$fPassword' WHERE=20
username=3D'$username'");
=2D
+      $password_query =3D '';
+      if ($fPassword !=3D '') { # do not change password to empty one
+         $password_query =3D ", password=3D'$fPassword'";
+      }
+      $result =3D db_query ("UPDATE $table_admin SET=20
modified=3DNOW(),active=3D'$sqlActive' $password_query WHERE=20
username=3D'$username'");


In short: If no password was entered, do not touch it in the UPDATE=20
query (the $password_query part is empty in this case).

> > > <Smarty + Prepared statements would make me very happy />
> >
> > I don't know Smarty good enough to add a statement, but I'm afraid
> > it would add some overhead. There are other ways to make the
> > templates easier...
>
> To which I'd say :
>
> 1) Postfixadmin isn't going to be in a high demand, zillions of users
> style situation, so performance doesn't matter (that much!)

;-)

> 2) Using Smarty would stop the automatic spread of variables from the
> controller to the view - which would make it far more obvious what is
> given to the view layer, and what isn't.

Hmm, there are other ways to reach this goal. I don't say that Smarty is=20
bad, but you can reach _this_ goal by putting the templates into=20
functions or classes.

Anyway: The templates need a big cleanup first. Maybe I can even make a=20
nice render_table() function for all the list-* pages...

> 3) We can tell Smarty to sanitise all data it displays by default,
> rather than us having to run htmlentities everywhere, so we can stop
> XSS/HTML injection like problems very easily.

I'd say this is also solvable with functions or classes - you can=20
sanitize all parameters when calling the function ;-)

> > Prepared statements would be a good idea - we would get rid of SQL
> > injections easily.
>
> Indeed. Question is, what version(s) of PHP/MySQL to we need to
> support.=20

I checked php.net about this. If I didn't miss something, PHP does not=20
provide a prepare / execute for MySQL. We would have to use the MySQL=20
PREPARE and EXECUTE statements as query manually.

=46or pgsql prepared statement support was added in PHP 5.1.

> If we're thinking of older ones, then we'd have to use=20
> something like PEAR::DB or PEAR::MDB2 - which emulate
> prepared-statement-ness.

Ah, the old question of using an abstraction layer. I'm still not sure=20
if we really need it - but having some helper functions (for example
    insert("table", array ("field1" =3D> "value1", "field2" =3D> "value2")
that create database statements might be a good idea.

> I added a min_password_length config setting in.... which should help
> too ($CONF['min_password_length'])

Yes, I already hit this in the test installation on my laptop ;-) (which=20
doesn't need strong passwords - it's not connected to Postfix at all).


Regards,

Christian Boltz
=2D-=20
[PDF] Fipptehler korrigiert -- wie konnten wir das bisher uebersehen ;)
=2D <xsl:if test=3D"position()=3D1">Sch=FCsselworte: </xsl:if>
+ <xsl:if test=3D"position()=3D1">Schl=FCsselworte: </xsl:if>
[David Haller in suse-linux-faq]

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

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

>=20
> > > I consider it security-critical to include the password in the HTML
> > > code (browser cache etc.). Luckily, this code seems to be buggy -
> > > at least, it never included the password for me.
> >
> > Ah, it should say $tPassword. I'd never intentionally display the
> > unencrypted password in the form.
>=20
> This isn't really better - if someone uses unencrypted passwords, there=
=20
> will be a cleartext password again.

Ah, bugg-rit. I'd forgotten about that 'feature'

As these are the passwords for the admin user, how about we change is so
admin passwords are _always_ encrypted with something decent?=20
As admin passwords aren't used for mailboxes, it wouldn't have any
impact outside of postfixadmin.

>=20
> The correct and secure solution is not to insert the password at all.
>=20

My grievance with this is that when ever an admin is edited, I think
your previous patch, implied that a users password had to be
changed/set. Which is horrible.

> > <Smarty + Prepared statements would make me very happy />
>=20
> I don't know Smarty good enough to add a statement, but I'm afraid it=20
> would add some overhead. There are other ways to make the templates=20
> easier...
=20
To which I'd say :

1) Postfixadmin isn't going to be in a high demand, zillions of users
style situation, so performance doesn't matter (that much!)
2) Using Smarty would stop the automatic spread of variables from the=20
controller to the view - which would make it far more obvious what is
given to the view layer, and what isn't.
3) We can tell Smarty to sanitise all data it displays by default,
rather than us having to run htmlentities everywhere, so we can stop
XSS/HTML injection like problems very easily.

> Prepared statements would be a good idea - we would get rid of SQL=20
> injections easily.

Indeed. Question is, what version(s) of PHP/MySQL to we need to support.
If we're thinking of older ones, then we'd have to use something like
PEAR::DB or PEAR::MDB2 - which emulate prepared-statement-ness.


I added a min_password_length config setting in.... which should help
too ($CONF['min_password_length'])

David.
--=20
David Goodwin=20

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

Re: [Postfixadmin-devel] Fwd: Re: Fwd: postfixadmin with latest PGSQL (8.2.4)

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

> > > I've tried to search email of GingerDog and didn't found it :(
> > >
> > > Sorry, I'm not familiar with Sourceforge community, and the
> > > unability to
> > > contact active developers of the Postfixadmin frustrates me.
>=20


Drat! That dual identify of David Goodwin and GingerDog! Who is that
masked villian?  :)

(Googling for GingerDog and Postfixadmin works quite well)

>=20
> However I know that the Sourceforge interface can be confusing=20
> sometimes ;-)
>=20

Definately :(

> > > I'm also currently developing add-ons for PostfixAdmin such as use
> > > of restriction classes of the Postfix, status monitoring, maillog
> > > checks, antispam features involvement and so on... I think, all
> > > these would be of certain interest for others.
>=20

Sounds very interesting; I've been meaning to add some sort of
spamassassin integration where either :

a) a unique idenfier is added to the mail body, and users can either click=
=20
on a link or forward the mail to spam@domain to train spamassassin as
appropriate.

or

b) List all recent emails (e.g. the last 7 days worth) allowing users to
say "Yes- that, that that and that were spam".

Where I have Postfixadmin deployed we have the problem that a lot of the
mail from the postfixadmin box is picked up through catch-all addresses
and collected via pop3 by other servers, which themselves talk to
client(s). Getting mail in the right format for spam training is
therefore non-trivial.


> > >>>
> > >>> however, I need to make some minor adjustments in several scripts
> > >>> to make it working with the latest PostgreSQL.
>=20
> Which version do you use? 2.1 or the latest SVN version?
>=20
> (Unfortunately I'm using MySQL here, but there's someone on the=20
> mailinglist who can help with pgsql.)
>=20

I use PostgreSQL - curently 8.1 (i think) (whatever comes with Ubuntu
Edgy).=20

> > >>> also, I have a more adequate translation file for russian
> > >>> language,=20


Excellent

> > >>> and more handy admin_menu.tpl.=20
>=20

I think the menu could change to something like :

'List Virtual'
'List Domains'
'List Admins'
'List Vacations' (?)

and have the related add/edit/remove links in the list-XXX.php
page.

> I'm looking forward for your contributions to Postfixadmin :-)

Ditto

David.

--=20
David Goodwin=20

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

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

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

Hello,

Am Donnerstag, 4. Oktober 2007 schrieb David Goodwin:
> Christian Boltz wrote :
> > just going through the svn commits...
>
> I'm glad someone else looks at them :)

;-)

> > I consider it security-critical to include the password in the HTML
> > code (browser cache etc.). Luckily, this code seems to be buggy -
> > at least, it never included the password for me.
>
> Ah, it should say $tPassword. I'd never intentionally display the
> unencrypted password in the form.

This isn't really better - if someone uses unencrypted passwords, there=20
will be a cleartext password again.

The correct and secure solution is not to insert the password at all.

> <insert comment about postfix admin's horrible templating and
> sanitisation structure />

<insert comment about duplicated code />

;-)

> <Smarty + Prepared statements would make me very happy />

I don't know Smarty good enough to add a statement, but I'm afraid it=20
would add some overhead. There are other ways to make the templates=20
easier...

Prepared statements would be a good idea - we would get rid of SQL=20
injections easily.

> > Argh, it seems admin/edit-admin.php needs some fixes...
> >
> > I just fixed some password-related bugs in edit-admin.php:
> > - When entering a password in the first field and leaving the
> > second one empty, the password was changed anyways.
>
> Er.. I thought my logic was something along the lines of :
>
> 1) Get password from template - if it matches the encrypted password
> belonging to that admin assume it's not changed and do nothing.
>
> 2) If it doesn't match the encrypted password, see if password2 is
> available, and if they match, update the user's password to the new
> value (after pacrypt'ing it).

See above.

> > - It was also changed to an empty password if you left both fields
> >   empty. This is a bad idea because you often modify some admin
> > settings without even knowing his password.
>
> There would normally have been the 1st password field with a value
> within it, so this shouldn't happen (unless someone wants it to have
> an empty password)

Again: see above ;-)

> I guess my web browser was a little too eager in caching/filling
> password boxes in for me.

Another reason to leave them empty by default ;-)

> > One bug is remaining in admin/edit-admin.php:
> > When editing an admin, it does not take the "active" status from
> > the database. This means editing an admin always disables it
> > (unless you correct the checkbox yourself).
> > Can you please fix this?
>
> Hmm.. I think this is a pgsql vs mysql-ism - in that it works for
> PgSQL. I'll try and review the code again today.

After your change, it works :-)


Regards,

Christian Boltz
=2D-=20
> |``All mail clients suck.  This one just sucks less.'' -me, circa 1995
> Diese Aussage ist heute gueltiger denn je! ("me" ist Michael Elkins!).
Pah.  Mutt kann ja nichtmal die einfachsten Scriptw=FCrmer interpretieren.
Geh mir da wech mit.       [> David Haller und Ratti in fontlinge-devel]

Re: [Postfixadmin-devel] Fwd: postfixadmin with latest PGSQL (8.2.4)

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

Guten Abend!

(I'm a bit surprised - do you speak german?)

Am Freitag, 5. Oktober 2007 schrieb Sergey Litvinenko:
> Guten Abend, Christian!!
>
> > First question: Sergey, is it OK for you if I forward your mail
> > (and future mails) to the postfixadmin-devel mailinglist?
> > (I'll wait for your OK before doing it)
>
> yes, it's OK :)
> I've sent subscribe request.

Don't forget to answer the confirmation mail ;-)

> > Yes, sounds interesting. You can submit patches in the tracker
> > (also on http://sourceforge.net/projects/postfixadmin) or send them
> > to the postfixadmin-devel mailinglist.
>
> how to make patches?
> I can point the place in the code where and what I've changed and for
> what reason, but I don't know how to make it as a patch.
>
> Diff original and modified versions??

Yes, diff (with -u option) is the correct tool.

If you changed a single file:
    diff -u file.orig file > file.patch

If you changed multiple files and have copied the directory before
    diff -Nur postfixadmin.orig/ postfixadmin > postfixadmin.patch

If you use the SVN version and change it, it's even easier:
    svn diff > postfixadmin.patch

> okay, I'll prepare these diffs and will send to postfixadmin-devel
> list soon.

:-)

> > Which version do you use? 2.1 or the latest SVN version?
>
> the version from the latest FreeBSD ports
> I see it as "Postfix Admin 2.1.0."

That's pretty old. Please update to the current SVN version before 
creating patches - we have done lots of changes and also lots of fixes.

SVN checkout (should be one line):
    svn co https://postfixadmin.svn.sourceforge.net/svnroot/postfixadmin 
    postfixadmin/trunk

Then run "svn update" regularly to have the latest version.

If you have problems or questions while porting your changes to the 
latest version, just ask on postfixadmin-devel or on #postfixadmin on 
irc.freenode.org

> > (Unfortunately I'm using MySQL here, but there's someone on the
> > mailinglist who can help with pgsql.)
>
> I have long experience with Postgres, and with PHP/PGSQL programming.
> I just want some things with pgsql-related code to be hair-brushed,
> as I want to use the Postfixadmin with PGSQL with more installations.

AFAIK some people use the SVN version with pgsql, so it must have 
improved ;-)

> > As Mischa already said: Database backup, currently only for MySQL.
>
> I'd like to develop backup code for Postgres :)

:-)


Regards,

Christian Boltz
-- 
[SuSE vs. SUSE] As a friend of mine elsewhere remarked, the picky
spelling capitalization scheme reinforces the idea that Linux is
case-sensitive, so these are "sensitive" issues and certainly worth
discussing (for us, at least)! :)   [Shriramana Sharma in opensuse]

[Postfixadmin-devel] Fwd: Re: Fwd: postfixadmin with latest PGSQL (8.2.4)

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

Hello,

FYI: This is the reply to a mail Mischa forwarded to me. 
Sergey permitted to send it to the mailinglist and will also subscribe 
here.

Maybe we should have some type of meta-documentation ("how to contact 
us" etc.) - see below

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

Subject: Re: Fwd: postfixadmin with latest PGSQL (8.2.4)
Date: Donnerstag, 4. Oktober 2007
From: Christian Boltz <pos...@cb...>
To: Mischa Peters <mi...@hi...>, se...@rs...

Hello,

Am Donnerstag, 4. Oktober 2007 schrieb Mischa Peters:
> Would you be so kind to help this guy out. ;)

Of course ;-)

First question: Sergey, is it OK for you if I forward your mail (and 
future mails) to the postfixadmin-devel mailinglist?
(I'll wait for your OK before doing it)

> Begin forwarded message:
> > From: Sergey Litvinenko <se...@rs...>
> > Date: October 03, 2007 22:42:07GMT+02:00
> > To: Mischa Peters <mi...@hi...>
> > Subject: Re: postfixadmin with latest PGSQL (8.2.4)

> > I've tried to search email of GingerDog and didn't found it :(
> >
> > Sorry, I'm not familiar with Sourceforge community, and the
> > unability to
> > contact active developers of the Postfixadmin frustrates me.

Two hints about contacting people on Sourceforge:
Go to http://sourceforge.net/projects/postfixadmin and
- click the name of any project admin or developer. A mail address is 
  offered - its always   <username>@users.sourceforge.net
- if you click the mail address, there's also a contact form

However I know that the Sourceforge interface can be confusing 
sometimes ;-)

> > I'm also currently developing add-ons for PostfixAdmin such as use
> > of restriction classes of the Postfix, status monitoring, maillog
> > checks, antispam features involvement and so on... I think, all
> > these would be of certain interest for others.

Yes, sounds interesting. You can submit patches in the tracker (also on 
http://sourceforge.net/projects/postfixadmin) or send them to the 
postfixadmin-devel mailinglist.

If you provide enough good patches, we can also add you as developer 
with direct SVN access.

> >>> I've ran a couple of installations of postfixadmin and find it
> >>> very useful, thank you!
> >>>
> >>> however, I need to make some minor adjustments in several scripts
> >>> to make it working with the latest PostgreSQL.

Which version do you use? 2.1 or the latest SVN version?

(Unfortunately I'm using MySQL here, but there's someone on the 
mailinglist who can help with pgsql.)

> >>> also, I have a more adequate translation file for russian
> >>> language, 

I don't understand russian, but you can still send it ;-)
(patch against SVN version preferred)

> >>> and more handy admin_menu.tpl. 

Again: Patches welcome ;-)

> >>> I would like to share this with developers of the Postfixadmin,
> >>> whom to contact?

The best way is to subscribe to postfixadmin-devel. You can do this on
http://lists.sourceforge.net/mailman/listinfo/postfixadmin-devel

As an alternative, you can also post to the forum on 
http://sourceforge.net/projects/postfixadmin or enter bugs and patches 
in the tracker there.

> >>> Also, script http://domain.tld/postfixadmin/admin/backup.php
> >>> sends
> >>> DEBUG INFORMATION:
> >>> Invalid query: ERROR: syntax error at or near "CREATE" LINE 1:
> >>> SHOW CREATE
> >>> TABLE admin ^
> >>>
> >>> what for this script is intended?? i've found nothing about it on
> >>> FAQ :(

As Mischa already said: Database backup, currently only for MySQL.


I'm looking forward for your contributions to Postfixadmin :-)


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]