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

[Christoph L. <chr...@it...>]

Hello everybody!

We are using postfixadmin for over 4 years now, first in Debian wheezy,
then Debian jessie, now Debian stretch.

We are using MySQL and the old "stable" vacation.pl.

We appreciate the project, obviously, and early on I even submitted a
patch for vacation.pl that got accepted:
https://sourceforge.net/p/postfixadmin/patches/117/

Unfortunately, after our upgrade to Debian stretch the vacation script
situation has became more than difficult, and I'd like to find a way out
of that SNAFU.

I'm willing to work on more patches and the like, but not without
discussing the strategy first, so here come our current problems and
some thoughts ...


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 ;-)

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.


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
which seems to match the broken
  <select class="flat" name="fInterval_Time">
    <option value="0" selected="selected"></option>
  </select>
created by vacation.php (3.0.2, Debian stretch).
I have not investigated the trunk version of vacation.php yet, sorry.

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?


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)


Intermediate question:

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

Changing our 2 installations of postfixadmin & postfix & dovecot &
apache authentication (for CalDAV) from MySQL/MariaDB to PostgreSQL
would be a LOT OF HARD WORK (and I don't like Debian's approach to
PostgreSQL upgrades), but we might be able to manage it.


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

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

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

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/

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


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)

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

Should we switch to postfixadmin 3.1 completely?
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)


Regards,

Christoph


-- 

Christoph Lechleitner

------------------------------------------------------------------------
ITEG IT-Engineers GmbH | Conradstr. 5, A-6020 Innsbruck, Austria
Mail: chr...@it... | Web: http://www.iteg.at/
------------------------------------------------------------------------