Re: [Postfixadmin-devel] Strategy for vacation script and vacation tables

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

Hello,

Am Mittwoch, 27. Dezember 2017 schrieb Christoph Lechleitner:

> Problem 1: Sender.pm almost unusable in Debian stretch:
> 
> Unfortunately, as I just commented in
>   https://sourceforge.net/p/postfixadmin/patches/136/#e917
> the Sender.pm coming with Debian stretch can not be satisfied by
> adding to the first line of vacation.pl -X any more.
> 
> I kind-of worked around that commenting out some lines in Sender.pm,
> which is less than ideal ;-)

Indeed ;-)

> I might be able to patch out the Sender.pm dependency, but it seems
> that has already happend (on the trunk at least) and might be in vain
> for other reasons, too.

Yes, this was already changed in git.

> Problem 2: vacation.pl confusion around $interval resp. interval_time:
> 
> Interval variant 1, legacy:
> 
> In the configuration part, $interval is supposed to set the vacation
> message interval for all vacations.
> 
> This is overruled though, by
>   $interval = get_interval($to);
> 
> Interval variant 2:
> 
> The patch dated 2012-04-19 is (in the old version, not in the trunk
> version) described to introduce a policy where interval (or
> interval_time?) means
>   0 = one reply, 1 = autoreply, > 1 = Delay reply

Yes, that's the expected behaviour:
0 = reply exactly once for the whole vacation period
1 = reply to every mail
2 = reply if the last reply was sent more than $seconds ago

The examples in config.inc.php will tell you the same ;-)

> Interval variant 3:
> 
> The actual interval used is detected through get_interval() only,
> which queries interval_time from vacation.
> 
> Interval future?
> 
> Can someone clarify the current idea around interval / interval_time?
> 
> I guess it's that 0/1/>1 strategy?

Right, see above.

> Problem 3, only somehow related:
> 
> The recent upgrade from Debian jessie to stretch, i.e. postfixadmin
> 2.3.7 to 3.0.2, seems to have set vacation.activefrom and
> vacation.activeuntil to 2000-01-01 00:00:00.
> 
> Could that be?
> 
> Are activefrom, activeuntil supposed to be used?
> 
> (I hate databases' date types ..., we usually use unixtime seconds or
> milliseconds as integers)

Oops, interesting bug.

We use the 2000-01-01 as default date mostly because you can't use 
CURRENT_TIMESTAMP on more than one field in MySQL. This usually isn't a 
problem because it's "old enough" - but for the vacation end date, we 
should default to a date in the (far) future when adding the 
"activeuntil" field during the upgrade.

This is one of the few cases where I'll modify an existing upgrade 
function in upgrade.php - doing this change later means to get a wrong 
value when adding the column. (Nevertheless, I'll add a new function to 
keep the scheme in sync for those who already have the activeuntil 
column.)

I just pushed a fixed upgrade.php to fix this, but there's a fine print:
- As I just found out, sqlite doesn't support to change the field 
  default later, so people with existing sqlite databases will have to 
  live with the wrong default.
- Also, the new default only applies when adding the column, so if you 
  already have the activeuntil column, the 2000-01-01 values will 
  survive. In theory the new default also applies when doing an INSERT
  without specifying activeuntil, but this won't happen with 
  PostfixAdmin ;-)

> Intermediate question:
> 
> Are there plans to remove support for MySQL/MariaDB from postfixadmin,
> making it PostgreSQL-only?

No worries, I use PostfixAdmin with MariaDB myself ;-)

> Conclusion rg. vacation:
> 
> If I understand it correctly there are currently 4 vacation scripts
> around:
> 
> 1. Old vacation.pl with several issues (Sender.pm, interval), but
> MySQL support.
> 
> 2. Newer vacation.pl in svn

SVN won't see any updates anymore, so please ignore it and use github.
(Just wondering - should I do a final commit that deletes everything and 
only puts a README with a pointer to github there?)

> Concluding from the intermediate name vacation-pgsql.pl it seems it is
> or was PostgreSQL only?

Yes. Years ago, we had separate vacation scripts for MySQL and 
PostgreSQL. Needless to say that that was a maintenance pain, so we 
decided to merge everything into one script. A "real" merge is difficult 
with two completely different scripts, so the PostgreSQL script "won" 
and got some additions to handle MySQL specific cases.

> The current version,
> https://github.com/postfixadmin/postfixadmin/blob/master/VIRTUAL_VACAT
> ION/vacation.pl does contain some MySQL code, but is that up-to-date?

I'm using it (the version from PostfixAdmin 3.0.2) with MySQL on several 
servers, so I'm quite sure it works ;-)

> 3. A PHP script, currently PostgreSQL only (other limits, too):
> https://sourceforge.net/p/postfixadmin/patches/9/
> 
> 4. A python script, currently PostgreSQL only (other limits, too):
> https://sourceforge.net/p/postfixadmin/patches/10/

These are user contributions, but since they are incomplete, it's 
unlikely that we pick them up. They can't completely replace the current 
perl script because of their limitations and I'm not going to maintain 
multiple vacation scripts.

Actually it might be a good idea to finally close these tickets as 
rejected - having them hang around isn't useful for anybody.

Personally I prefer python over perl, so if someone sends us a 
vacation.py that implements all features of vacation.pl, I'll consider 
it as a replacement ;-)  (and make vacation.pl a wrapper to avoid that 
everybody needs to change master.cf ;-)

> What are the plans for vacation script's future?
> The newer vacation.pl from the git trunk?

Yes.

> Vacation strategies:
> 
> What does anybody propose for the immediate situation of us (and
> propably other Debian stretch setups)?
> 
> Should we switch to the new vacation.pl?
> Does that have any open issues we should know about?
> (I am willing to help with those if there are any)

Just check the open bugs (which are still spread across Sourceforge and 
github) - but in general, we fix bugs and (hopefully) don't introduce 
new ones ;-)

> Should we rather add MySQL support to on of the 3rd party vacation
> scripts in PHP resp. Python?

As I wrote above - personally I'm a python fan because it forces you to 
write clean code, but I'm not sure if rewriting vacation.pl "just to 
make it python" is worth the effort.

> Should we switch to postfixadmin 3.1 completely?

Using the latest version is always a good idea ;-)

> We might be able to provide a repository for Debian (and Devuan,
> Ubuntu, ...) within our OpenSource platform, Clazzes.org (resp. the
> http://deb.clazzes.org repository collection)

:-)

The openSUSE build service might be another option. I'm already building 
the RPM package there, and if someone gets me started with building DEBs 
there, we'd have everything at one place, which would make the release 
work easier.


Regards,

Christian Boltz
-- 
> es ist doch ausgesprochen ruhig hier und das nach dem Release einer
> neuen openSUSE Version. Sollte es etwa keine Probleme geben?
Vermutlich sind alle damit beschaeftigt, kmail2 ans Laufen zu bekommen.
Dann gibt es auch wieder Mails :-)
[> Marco Röben und Thomas Moritz in opensuse-de]