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

Re: [Postfixadmin-devel] postfixadmin 3.1 - sqlite Connect: given database path does not exist, is not writable, or $CONF['database_name'] is empty.

[Sophie L. <so...@kl...>]

Issue was permissions 555 / root:root on directory. Changed and works :)


Problem solved via the irc.


> On 27 Nov 2017, at 20:40, Sophie Loewenthal <so...@kl...> wrote:
> 
> Hi guys,
> 
> Apologies for quick set up question! 
> 
> In postfixadmin 3.1 I have this config for sqlite in config.local.php:
> 
> $CONF['database_type'] = 'sqlite';
> $CONF['database_host'] = 'localhost';
> $CONF['database_user'] = 'postfix';
> $CONF['database_password'] = 'password';
> $CONF['database_name'] = '/var/sqlite/postfixadmin.db';
> $CONF['database_prefix'] = '';
> 
> -rwxr-xr-x 1 www-data mail 0 Nov 27 19:28 /var/sqlite/postfixadmin.db
> 
> This was created with the command # sqlite3 /var/sqlite/postfixadmin.db
> 
> 
> When I call setup.php this message is returned: 
> 
> • Depends on: SQLite - OK
> • Error: Can't connect to database
> Please edit the $CONF['database_*'] parameters in config.local.php.
> DEBUG INFORMATION
> Connect: given database path does not exist, is not writable, or $CONF['database_name'] is empty.
> 
> Any idea why this is breaking?
> 
> 
> Kind regards, Sophie.
> 
> 
> 
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel

[Postfixadmin-devel] postfixadmin 3.1 - sqlite Connect: given database path does not exist, is not writable, or $CONF['database_name'] is empty.

[Sophie L. <so...@kl...>]

Hi guys,

Apologies for quick set up question! 

In postfixadmin 3.1 I have this config for sqlite in config.local.php:

$CONF['database_type'] = 'sqlite';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'postfix';
$CONF['database_password'] = 'password';
$CONF['database_name'] = '/var/sqlite/postfixadmin.db';
$CONF['database_prefix'] = '';

-rwxr-xr-x 1 www-data mail 0 Nov 27 19:28 /var/sqlite/postfixadmin.db

This was created with the command # sqlite3 /var/sqlite/postfixadmin.db


When I call setup.php this message is returned: 

• Depends on: SQLite - OK
• Error: Can't connect to database
Please edit the $CONF['database_*'] parameters in config.local.php.
DEBUG INFORMATION
Connect: given database path does not exist, is not writable, or $CONF['database_name'] is empty.

Any idea why this is breaking?


Kind regards, Sophie.

Re: [Postfixadmin-devel] Downloading the PostfixAdmin directly to the mailserver

[Johnny A. S. <jo...@so...>]

On Thursday 23. February 2017 22.47, Robert Moskowitz wrote:
> On 02/23/2017 03:28 PM, Christian Boltz wrote:
> > AFAIK Sourceforge doesn't provide direct wget'able download URLs, so
> > you'll always have to start at the web interface.

Yes, they do. All download links on SourceForge is wget-able.
I usually go to the files section of any project and download from there.

> wget https://sourceforge.net/projects/postfixadmin/files/latest/download
> 
> downloads the tarball as file 'download'
> 
> Rename it and you are on your way.

It's even easier: add the switch «--content-disposition»

$ wget --content-disposition https://sourceforge.net/projects/postfixadmin/files/latest/download
will download the latest version and save it as postfixadmin-3.0.2.tar.gz, or whatever the latest version is when downloading.

But «files/latest/download» doesn't point to the latest version, but the latest uploaded file, which usually is the latest version, but not allways.
I run a few projects on SourceForge, and also upload gpg signatures (.sig), so those who care can verify that I uploaded it. If the sig file is uploaded after the tarball, sourceForge select the the sig file as the latest version.

-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0x4F5AD64DFA687324

Re: [Postfixadmin-devel] Downloading the PostfixAdmin directly to the mailserver

[Robert M. <rg...@ht...>]

On 02/23/2017 03:28 PM, Christian Boltz wrote:
> Hello,
>
> Am Donnerstag, 16. Februar 2017, 19:58:39 CET schrieb Robert Moskowitz:
>> On a mail server with no GUI, is there a nice wget command to download
>> the .tar.gz directly to the server?
>>
>> Something like
>>
>> wget
>> https://sourceforge.net/projects/postfixadmin/<mumble-mumble>/postfixa
>> dmin-n.n.n.tar.gz
>>
>> ?
>>
>> Or does this defeat the download count feature of sourceforge?
> AFAIK Sourceforge doesn't provide direct wget'able download URLs, so
> you'll always have to start at the web interface.
>
> My usual trick is to copy the link behind "if the download doesn't start
> automatically, click here" - it points to the tarball on a mirror and
> can be used with wget.

I discovered that:

wget https://sourceforge.net/projects/postfixadmin/files/latest/download

downloads the tarball as file 'download'

Rename it and you are on your way.

I got this URL from right clicking on the download button then copying link.

>
>
> Regards,
>
> Christian Boltz

Re: [Postfixadmin-devel] Downloading the PostfixAdmin directly to the mailserver

[Aaron L. <aa...@ac...>]

On Feb 23 21:28, Christian Boltz wrote:
> Hello,
> 
> Am Donnerstag, 16. Februar 2017, 19:58:39 CET schrieb Robert Moskowitz:
> > On a mail server with no GUI, is there a nice wget command to download
> > the .tar.gz directly to the server?
> > 
> > Something like
> > 
> > wget
> > https://sourceforge.net/projects/postfixadmin/<mumble-mumble>/postfixa
> > dmin-n.n.n.tar.gz
> > 
> > ?
> > 
> > Or does this defeat the download count feature of sourceforge?
> 
> AFAIK Sourceforge doesn't provide direct wget'able download URLs, so 
> you'll always have to start at the web interface.

They're just well-hidden! Try:
	# pkgver=3.0.2
	# wget https://downloads.sourceforge.net/project/postfixadmin/postfixadmin/postfixadmin-${pkgver}/postfixadmin-${pkgver}.tar.gz

Lifted from the Arch Linux PKGBUILD:
https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/postfixadmin

-Aaron

Re: [Postfixadmin-devel] Downloading the PostfixAdmin directly to the mailserver

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

Hello,

Am Donnerstag, 16. Februar 2017, 19:58:39 CET schrieb Robert Moskowitz:
> On a mail server with no GUI, is there a nice wget command to download
> the .tar.gz directly to the server?
> 
> Something like
> 
> wget
> https://sourceforge.net/projects/postfixadmin/<mumble-mumble>/postfixa
> dmin-n.n.n.tar.gz
> 
> ?
> 
> Or does this defeat the download count feature of sourceforge?

AFAIK Sourceforge doesn't provide direct wget'able download URLs, so 
you'll always have to start at the web interface.

My usual trick is to copy the link behind "if the download doesn't start 
automatically, click here" - it points to the tarball on a mirror and 
can be used with wget.


Regards,

Christian Boltz
-- 
>>>> ??? You cannot remove the package without resolving dependencies.
>>> Of course you can >:-)
>> No, you cannot.
> --nodeps
You don't need rpm to shoot yourself in the foot.
[>(>>) Carlos E. R. and (>>)(>>) Andreas Schwab in opensuse-factory]

[Postfixadmin-devel] Downloading the PostfixAdmin directly to the mailserver

[Robert M. <rg...@ht...>]

On a mail server with no GUI, is there a nice wget command to download 
the .tar.gz directly to the server?

Something like

wget 
https://sourceforge.net/projects/postfixadmin/<mumble-mumble>/postfixadmin-n.n.n.tar.gz

?

Or does this defeat the download count feature of sourceforge?

thanks.

[Postfixadmin-devel] Security hole in AliasHandler

[Jan-Frederik R. <pos...@ri...>]

Hello,

I've just discovered a security hole in the way the AliasHandler handles
alias deletions of protected alias.

I've submitted a pull request on github.com:
https://github.com/postfixadmin/postfixadmin/pull/23

I'm writing this on this list, because it might be a big problem for
people who use postfixadmin in a bigger scale.

Greetings,

Jan-Frederik Rieckers

[Postfixadmin-devel] Can't register superadmin in setup

[<ti...@ap...>]

Haya all

I got me a copy of version 3.0, and have the setup script writing OK all the
way down. However, when trying to create a superadmin the page simply refreshes
and nothing else happens. No error is shown on the page, no superadmin is
created in the database and nothing is logged on the server.

The server is a FreeBSD 10.3 running PostgreSQL 9.3.15 and Apache 2.4.25 with
PHP 5.6.29 using mod_php as interface to Apache.

As far as I can see the database should be ready to use

padmin=# \l
                          List of databases
   Name    | Owner  | Encoding | Collate | Ctype | Access privileges 
-----------+--------+----------+---------+-------+-------------------
 padmin    | padmin | UTF8     | C       | C     | =Tc/padmin       +
           |        |          |         |       | padmin=CTc/padmin

...

And all the tables seems to be created by setup

padmin=# \d
                 List of relations
 Schema |         Name          |   Type   | Owner  
--------+-----------------------+----------+--------
 public | admin                 | table    | padmin
 public | alias                 | table    | padmin
 public | alias_domain          | table    | padmin
 public | config                | table    | padmin
 public | config_id_seq         | sequence | padmin
 public | domain                | table    | padmin
 public | domain_admins         | table    | padmin
 public | fetchmail             | table    | padmin
 public | fetchmail_id_seq      | sequence | padmin
 public | log                   | table    | padmin
 public | mailbox               | table    | padmin
 public | quota                 | table    | padmin
 public | quota2                | table    | padmin
 public | vacation              | table    | padmin
 public | vacation_notification | table    | padmin
(15 rows)

During the setup process a few messages is printed by PostgreSQL

Jan 12 21:22:01 freebsd postgres[76470]: [3-1] ERROR:  column "transport" of
relation "domain" already exists Jan 12 21:22:01 freebsd postgres[76470]: [3-2]
STATEMENT:  ALTER TABLE domain ADD COLUMN transport VARCHAR(255)
Jan 12 21:22:01 freebsd postgres[76470]: [4-1] ERROR:  column "backupmx" of
relation "domain" already exists
Jan 12 21:22:01 freebsd postgres[76470]: [4-2] STATEMENT:  ALTER TABLE domain
ADD COLUMN backupmx BOOLEAN DEFAULT false
Jan 12 21:22:04 freebsd postgres[76470]: [5-1] ERROR:  language "plpgsql"
already exists
Jan 12 21:22:04 freebsd postgres[76470]: [5-2] STATEMENT: CREATE LANGUAGE
plpgsql

Apache logs nothing besides the "200 - OK" when submitting the form and I have
"?debug=1" set in the URL. I have also tried to enable "display_errors" in
php.ini but with no luck, meaning no error is printet.

In the PostfixAdmin config I have tried to use both "system" and "md5crypt" as
$CONF['encrypt']. When not using a correctly formed e-mail address the setup
returns a error, just like the setup detects a wrong setup password and if the
two superadmin passwords don't match.

Any pointers would be a great help since I seem to be somewhat stuck.

Thanks

[Postfixadmin-devel] Final localized date patch

[Ullrich v. B. <uz...@mu...>]

I hope everbody had a nice christmas with lots of loot :)

Attached is the final fix for the localized date display. It superseedes my
last patch posted here.

Description:

The patch introduces two new functions that encapsulate the formatting of
dates. They are:

db_date_format() which returns the date format string for the
database in use and

db_date_column_query() which returns the part of an SQL query that asks for a
timestamp column.

The existing code for SQLite reused the date format for mysql, my patch fixes
this by introducing a new language specific entry $PALANG['dateformat_sqlite']
which currently has the same value as $PALANG['dateformat_mysql'].

Any other code is then rewritten to use db_date_column_query(). This
simplifies the code in several places.

As a result, dates are now always correctly localized without cluttering the
php files with database specific code. An unwanted but unavoidable side result
is that with the current PALANG contents, dates are now just dates without
hours and minutes. This is not an error but a consequence of the current
localization and easily correctable.

I have some other changes in mind but will wait for comments / patch
acceptance. Patch is attached because it's somewhat larger.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz...@mu...
Encrypted email preferred                          PGP Key-Id: 29D93B10

Re: [Postfixadmin-devel] Bug in v3.0 vacation module

[Tanstaafl <tan...@li...>]

On 12/21/2016 7:23 PM, Christian Boltz <pos...@cb...> wrote:
> a) drop the column (and hope that not too many people forgot to update
>    to the new vacation.pl)

I think spending your valuable time trying to foresee *and* resolve
other people's mistakes is a really bad way to handle things.

Just make sure the upgrade path is fully documented, and leave people
free to learn from their mistakes.

Re: [Postfixadmin-devel] Bug in v3.0 vacation module

[Ullrich v. B. <uz...@mu...>]

[Send this email to Christian not realizing that the emails from the list
don't have a Reply-To header that points to the list. I'll try to be more
careful in the future.]

Good morning!

On Thu, Dec 22, 2016 at 01:23:32AM +0100, Christian Boltz wrote:
> Which database do you use? MySQL, PostgreSQL or SQLite?
> (I'd guess PostgreSQL ;-)

I have both, a postgresql setup for production and a mysql setup for testing.
The new vacation module works with the mysql setup without problems. I haven't
changed anything in the mysql installation, so I don't know if strict mode is
enabled or not.

> I'm asking because I'm quite sure [1] your patch broke the vacation
> module for MySQL users, at least those using strict mode. The "cache"
> column is a text (not varchar) field which doesn't allow to define a
> default value, therefore we need to specify a value as long as this
> column exists.

The existing vacation module does definitely not work with postgres. With my
patch, it works with postgres and with mysql (maybe not in strict mode). So I
would say, it's at least an improvement :)

> Opinions? ;-)

If the only purpose of the column is to let people run older versions of the
vacation module, then I would definitely suggest to drop it. Keeping old cruft
like this in each version will kill you in the long run. That's my two cent.
Your opinion may of course be different. :)

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz...@mu...
Encrypted email preferred                          PGP Key-Id: 29D93B10

Re: [Postfixadmin-devel] Bug in v3.0 vacation module

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

Hello,

Am Montag, 19. Dezember 2016 schrieb Ullrich von Bassewitz:
> I wasn't able to open a ticket so here is a small diff that fixes a
> problem with the vacation module. It references a table column that
> seems to have existed in older versions, but does no longer in
> version 3. I'm using this package from the web site:
> postfixadmin-3.0.fedora.noarch.rpm

Which database do you use? MySQL, PostgreSQL or SQLite?
(I'd guess PostgreSQL ;-)


I'm asking because I'm quite sure [1] your patch broke the vacation 
module for MySQL users, at least those using strict mode. The "cache" 
column is a text (not varchar) field which doesn't allow to define a 
default value, therefore we need to specify a value as long as this 
column exists.

The "cache" field was used by old (MySQL only [2]) versions of 
vacation.pl (to store what we now have in the vacation_notification 
table), so the question is how we should continue.

The reason why I kept the column is that people out there might still 
(accidently) use an old vacation.pl together with the new PostfixAdmin. 
So the possible options are:
a) drop the column (and hope that not too many people forgot to update
   to the new vacation.pl)
b) add the column for all database types (yes, that sounds pointless,
   but would avoid differences in the database structure)
c) change VacationHandler so that it only knows and fills the cache 
   column if using a MySQL database

Opinions? ;-)


Regards,

Christian Boltz

[1] I know the code good enough to be quite sure ;-)) - but I didn't
    test it.

[2] Back then, we had a MySQL vacation.pl and a PostgreSQL vacation.pl.
    David then merged both into one, using the PostgreSQL vacation.pl as
    base. IIRC the PostgreSQL version of vacation.pl never used the 
    cache field, which explains why it doesn't exist in the PostgreSQL 
    database layout.

-- 
> IIRC gab es ÜHER mal so seltsame rechteckige Blöcke mit vielen
> einzelnen Blättern aus Zellulosefasern in denen man Rezepte nachlesen
> konnte... aber frag' mich jetzt nur nicht, wie die hießen.
Du redest doch wohl nicht von ermordeten Bäumen?
[>T. Braun und S. Posner]

Re: [Postfixadmin-devel] Problem in handling of $CONF['theme_logo']

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

Hello,

Am Dienstag, 20. Dezember 2016 schrieb Ullrich von Bassewitz:
> This is in postfixadmin version 3.0.
> 
> I didn't want to mess with internal postfixadmin directories and
> stored my custom company logo in another path: /images/mylogo.png. So
> config.inc.php contains
> 
> $CONF['theme_logo'] = '/images/mylogo.png';
> 
> This works well with the admin login page, but not with the user login
> page. The generated HTML code for the user login page contains:
> 
> <a href='main.php'><img id="login_header_logo"
> src="..//images/mylogo.png" alt="Logo" /></a>
> 
> postfixadmin prepends "../" to the configured path and makes it
> impossible to use any path that is not relative to the postfixadmin
> directory. This comes from smarty.inc.php:
> 
> if (!isset($rel_path)) $rel_path = ''; # users/* sets this to '../'
> $CONF['theme_css']  = $rel_path . htmlentities($CONF['theme_css']);
> 
> and all of the files in the "users" subdirectory, where rel_path is
> set to "../".
> 
> I didn't know how fix it without breaking something. Maybe one of the
> developers can have a look at it or at least open a ticket so it may
> get fixed somewhere along the way. Thanks!

Hmm, this is an interesting issue.

If we drop the $rel_path prefix, we'll break it for all people using an 
image relative to the PostfixAdmin directory. Since this is the default, 
this means "nearly everybody".

OTOH, I know that the current code makes it impossible to use absolute 
paths.

A way that works for both usecases isn't too easy, but it could be 
possible. I can thing of two options:
- move users/*.php to users-*.php to avoid the additional directory 
  level and the need for $relpath.
- merging the admin and user login would work, but that's a different 
  beast.

Note that both options are more a long-term fix - I'd guess some things 
will break after moving files around ;-)


For now, may I propose that you use a relative path like 
    $CONF['theme_logo'] = "myimages/mylogo.png"
and create an Alias in your apache config so that Apache maps the real 
file to that location?


Regards,

Christian Boltz
-- 
By basic sanity check I meant error/warning messages which can be
understood by mere simple human beings from planet earth
[Cristian Rodríguez in opensuse-packaging]

[Postfixadmin-devel] Improvement: Use localized dates in log view

[Ullrich v. B. <uz...@mu...>]

The following is for postfixadmin v3.0.

In the log file view, dates aren't localized. This is most visible when using
postgres because in this case, dates are converted in viewlog.php using some
US date format:

    $row['timestamp']=gmstrftime('%c %Z',$row['timestamp']);

This gives a date string like "Mon Dec 19 13:41:45 2016 GMT" as can be seen in
the screenshot from a german postfixadmin installation:

http://www.musoftware.de/Screenshot_2016-12-21_20-54-23.png

When using MySQL, the standard format returned by the database is used. It
looks like "2016-12-19 13:41:45", which is more "natural" but still not as
defined in the language files.

The following patch fixes this and makes the log view use the date formats
defined in the language files:

------------------------------------------------------------------------------
--- viewlog.php.orig    2016-12-20 22:30:33.296023861 +0100
+++ viewlog.php 2016-12-21 21:13:47.094649703 +0100
@@ -57,18 +57,21 @@
 if ($error != 1)
 {
    $table_log = table_by_key('log');
-   $query = "SELECT timestamp,username,domain,action,data FROM $table_log WHERE domain='$fDomain' ORDER BY timestamp DESC LIMIT 10";
    if (db_pgsql()) {
-      $query = "SELECT extract(epoch from timestamp) as timestamp,username,domain,action,data FROM $table_log WHERE domain='$fDomain' ORDER BY timestamp DESC LIMIT 10";
+      $dateformat = escape_string(Config::Lang('dateformat_pgsql'));
+      $query = "SELECT to_char (timestamp, '" . $dateformat  . "') as timestamp,username,domain,action,data FROM $table_log WHERE domain='$fDomain' ORDER BY timestamp DESC LIMIT 10";
+   } elseif (db_sqlite()) {
+      $dateformat = escape_string(Config::Lang('dateformat_mysql'));
+      $query = "SELECT strftime (timestamp, '" . $dateformat  . "') as timestamp,username,domain,action,data FROM $table_log WHERE domain='$fDomain' ORDER BY timestamp DESC LIMIT 10";
+   } else {
+      $dateformat = escape_string(Config::Lang('dateformat_mysql'));
+      $query = "SELECT date_format (timestamp, '" . $dateformat  . "') as timestamp,username,domain,action,data FROM $table_log WHERE domain='$fDomain' ORDER BY timestamp DESC LIMIT 10";
    }
    $result=db_query($query);
    if ($result['rows'] > 0)
    {
       while ($row = db_array ($result['result']))
       {
-         if (db_pgsql()) {
-            $row['timestamp']=gmstrftime('%c %Z',$row['timestamp']);
-         }
          $tLog[] = $row;
       }
    }
------------------------------------------------------------------------------

The code for mysql and postgresql is tested. For the sqlite version, the code
from PFAHandler.php was used. I was not able to test it, but I assume it
should be ok, provided that the code in PFAHandler.php is ok.

Please note that the existing date formats in the language files have no hours
and minutes, so after this change, dates displayed have no time attached. I
would suggest to change that. For the german language file, the current format

$PALANG['dateformat_pgsql'] = 'dd.mm.YYYY';
$PALANG['dateformat_mysql'] = '%d.%m.%Y';

can be replaced by

$PALANG['dateformat_pgsql'] = 'DD.MM.YYYY HH24:MI';
$PALANG['dateformat_mysql'] = '%d.%m.%Y %H:%i';

to add hours and minutes. Similar for the other language files.

After this change, there's one place left, where the local date format is
ignored. I will have a look at that in the next days.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz...@mu...
Encrypted email preferred                          PGP Key-Id: 29D93B10

Re: [Postfixadmin-devel] Bug in localized date display (v3.0/postgresql)

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

>
> The solution for a localizable output is to use the postgresql function
> to_char(), which expects a timestamp as first argument and an output format as
> the second. Since the second argument specifies the output format, it can be
> used by the translators to display localized dates:
>
>         if (db_pgsql()) {
>             $formatted_date = "TO_CHAR(###KEY###, '" . escape_string(Config::Lang('dateformat_pgsql')) . "')";
>
> Or, as a diff:
>
> ------------------------------------------------------------------------------
> --- PFAHandler.php.orig 2016-12-20 21:40:29.566967757 +0100
> +++ PFAHandler.php      2016-12-20 21:18:28.383772774 +0100
> @@ -565,7 +565,7 @@
>          $no  = escape_string(Config::lang('NO'));
>
>          if (db_pgsql()) {
> -            $formatted_date = "TO_DATE(text(###KEY###), '" . escape_string(Config::Lang('dateformat_pgsql')) . "')";
> +            $formatted_date = "TO_CHAR(###KEY###, '" . escape_string(Config::Lang('dateformat_pgsql')) . "')";
>              # $base64_decode = "DECODE(###KEY###, 'base64')";
>          } elseif (db_sqlite()) {
>              $formatted_date = "strftime(###KEY###, '" . escape_string(Config::Lang('dateformat_mysql')) . "')";
> -------

Thanks for this; I've applied your patch.

David.

[Postfixadmin-devel] Bug in localized date display (v3.0/postgresql)

[Ullrich v. B. <uz...@mu...>]

The following bug description is for postfixadmin v3.0 with a postgres
database. The bug is visible in the following screenshot taken from a
postfixadmin web page in german language:

http://www.musoftware.de/Screenshot_2016-12-20_22-03-31.png


Bug description:
================

The conversion from a timestamp field in the postgres database to a
displayable date is wrong. It is just coincidence that it works in the english
version. The problematic line is in model/PFAHandler.php:

if (db_pgsql()) {
    $formatted_date = "TO_DATE(text(###KEY###), '" . escape_string(Config::Lang('dateformat_pgsql')) . "')";

TO_DATE() converts a string(!) to a date. The second argument specifies how to
parse the first argument. The text() function converts a timestamp to a string
using the default date format.

So what happens here is that text() converts the timestamp field to a string,
then to_date() is used to parse this date string. While it looks as if the
second argument (taken from the language specific files) specifies the result,
it does in fact specify how to parse the output of text().

Here is an example from an actual database:

---------------------------------------------------------------------
postfix=# SELECT modified from ALIAS limit 1;
           modified
-------------------------------
 2016-12-13 15:00:40.598107+01
(1 row)
---------------------------------------------------------------------

Actually, "modified" is converted to text automagically, so using text() has
no visible effect:

---------------------------------------------------------------------
postfix=# SELECT text(modified) from ALIAS limit 1;
             text
-------------------------------
 2016-12-13 15:00:40.598107+01
(1 row)
---------------------------------------------------------------------

Using to_date(), above output is parsed and converted to a date, which in turn
is converted back to text for output:

---------------------------------------------------------------------
postfix=# SELECT to_date(text(modified), 'YYYY-MM-DD') from ALIAS limit 1;
  to_date
------------
 2016-12-13
(1 row)
---------------------------------------------------------------------

However, the string 'YYYY-MM-DD' does not specify the output, but how to parse
the input, so using 'DD.MM.YYYY' gives garbage:

---------------------------------------------------------------------
postfix=# SELECT to_date(text(modified), 'DD.MM.YYYY') from ALIAS limit 1;
  to_date
------------
 0019-06-08
(1 row)
---------------------------------------------------------------------

If you look at the code in PFAHandler.php, the second argument is passed to
the translators. This doesn't work.


Solution:
=========

The solution for a localizable output is to use the postgresql function
to_char(), which expects a timestamp as first argument and an output format as
the second. Since the second argument specifies the output format, it can be
used by the translators to display localized dates:

        if (db_pgsql()) {
            $formatted_date = "TO_CHAR(###KEY###, '" . escape_string(Config::Lang('dateformat_pgsql')) . "')";

Or, as a diff:

------------------------------------------------------------------------------
--- PFAHandler.php.orig 2016-12-20 21:40:29.566967757 +0100
+++ PFAHandler.php      2016-12-20 21:18:28.383772774 +0100
@@ -565,7 +565,7 @@
         $no  = escape_string(Config::lang('NO'));

         if (db_pgsql()) {
-            $formatted_date = "TO_DATE(text(###KEY###), '" . escape_string(Config::Lang('dateformat_pgsql')) . "')";
+            $formatted_date = "TO_CHAR(###KEY###, '" . escape_string(Config::Lang('dateformat_pgsql')) . "')";
             # $base64_decode = "DECODE(###KEY###, 'base64')";
         } elseif (db_sqlite()) {
             $formatted_date = "strftime(###KEY###, '" . escape_string(Config::Lang('dateformat_mysql')) . "')";
------------------------------------------------------------------------------

This went probably unnoticed, because the date string in the english version

$PALANG['dateformat_pgsql'] = 'YYYY-mm-dd';

causes the date text to be parsed correctly because it matches the output date
format of text().


Another problem:
================

Besides that, there's an inconsistency in the output: The mailbox list is
displayed in list-virtual.php and does NOT use the date format specified in
the language file. So the date format in the "last change" columns differs. It
is localized in the alias domains and aliases list, and fixed/not localized in
the mailbox list. In my case, I had garbage in the first two lists and a
correct (but non german) date in the last.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz...@mu...
Encrypted email preferred                          PGP Key-Id: 29D93B10

[Postfixadmin-devel] Problem in handling of $CONF['theme_logo']

[Ullrich v. B. <uz...@mu...>]

This is in postfixadmin version 3.0.

I didn't want to mess with internal postfixadmin directories and stored my
custom company logo in another path: /images/mylogo.png. So config.inc.php
contains

$CONF['theme_logo'] = '/images/mylogo.png';

This works well with the admin login page, but not with the user login page.
The generated HTML code for the user login page contains:

<a href='main.php'><img id="login_header_logo" src="..//images/mylogo.png" alt="Logo" /></a>

postfixadmin prepends "../" to the configured path and makes it impossible to
use any path that is not relative to the postfixadmin directory. This comes
from smarty.inc.php:

if (!isset($rel_path)) $rel_path = ''; # users/* sets this to '../'
$CONF['theme_css']  = $rel_path . htmlentities($CONF['theme_css']);

and all of the files in the "users" subdirectory, where rel_path is set to
"../".

I didn't know how fix it without breaking something. Maybe one of the
developers can have a look at it or at least open a ticket so it may get fixed
somewhere along the way. Thanks!

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz...@mu...
Encrypted email preferred                          PGP Key-Id: 29D93B10

Re: [Postfixadmin-devel] Bug in v3.0 vacation module

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

Hi -

Thanks - applied in changeset 1883

David.

On 19/12/2016 19:40, Ullrich von Bassewitz wrote:
>
> Good evening!
>
> I wasn't able to open a ticket so here is a small diff that fixes a problem
> with the vacation module. It references a table column that seems to have
> existed in older versions, but does no longer in version 3. I'm using this
> package from the web site: postfixadmin-3.0.fedora.noarch.rpm
>
> -------------------------------------------------------------------------------
> --- VacationHandler.orig	2016-05-22 18:17:46.000000000 +0200
> +++ VacationHandler.php	2016-12-13 15:50:18.664179212 +0100
> @@ -21,7 +21,6 @@
>              'body'          => pacol(   1,          1,      0,      'text', 'pUsersVacation_body'           , ''                                , '' ),
>              'activefrom'    => pacol(   1,          1,      1,      'text', 'pUsersVacation_activefrom'     , ''                                , '' ),
>              'activeuntil'   => pacol(   1,          1,      1,      'text', 'pUsersVacation_activeuntil'    , ''                                , '' ),
> -            'cache'         => pacol(   0,          0,      0,      'text', ''                              , ''                                , '' ), # leftover from 2.2
>              'active'        => pacol(   1,          1,      1,      'bool', 'active'                        , ''                                 , 1 ),
>              'created'       => pacol(   0,          0,      1,      'ts',   'created'                       , ''                                 ),
>              'modified'      => pacol(   0,          0,      1,      'ts',   'last_modified'                 , ''                                 ),
> @@ -180,7 +179,6 @@
>              'active' => db_get_boolean(true),
>              'activefrom' => $activeFrom,
>              'activeuntil' => $activeUntil,
> -            'cache' => '',
>          );
>
>          // is there an entry in the vacaton table for the user, or do we need to insert?
> -------------------------------------------------------------------------------
>
> I hope it is ok to post it here. If not, please let me know.
>
> There seems to be a another problem with display of date strings in a few
> places, which I will have to investigate.
>
> Regards
>
>
>         Uz
>
>

[Postfixadmin-devel] Bug in v3.0 vacation module

[Ullrich v. B. <uz...@mu...>]

Good evening!

I wasn't able to open a ticket so here is a small diff that fixes a problem
with the vacation module. It references a table column that seems to have
existed in older versions, but does no longer in version 3. I'm using this
package from the web site: postfixadmin-3.0.fedora.noarch.rpm

-------------------------------------------------------------------------------
--- VacationHandler.orig	2016-05-22 18:17:46.000000000 +0200
+++ VacationHandler.php	2016-12-13 15:50:18.664179212 +0100
@@ -21,7 +21,6 @@
             'body'          => pacol(   1,          1,      0,      'text', 'pUsersVacation_body'           , ''                                , '' ),
             'activefrom'    => pacol(   1,          1,      1,      'text', 'pUsersVacation_activefrom'     , ''                                , '' ),
             'activeuntil'   => pacol(   1,          1,      1,      'text', 'pUsersVacation_activeuntil'    , ''                                , '' ),
-            'cache'         => pacol(   0,          0,      0,      'text', ''                              , ''                                , '' ), # leftover from 2.2
             'active'        => pacol(   1,          1,      1,      'bool', 'active'                        , ''                                 , 1 ),
             'created'       => pacol(   0,          0,      1,      'ts',   'created'                       , ''                                 ),
             'modified'      => pacol(   0,          0,      1,      'ts',   'last_modified'                 , ''                                 ),
@@ -180,7 +179,6 @@
             'active' => db_get_boolean(true),
             'activefrom' => $activeFrom,
             'activeuntil' => $activeUntil,
-            'cache' => '',
         );

         // is there an entry in the vacaton table for the user, or do we need to insert?
-------------------------------------------------------------------------------

I hope it is ok to post it here. If not, please let me know.

There seems to be a another problem with display of date strings in a few
places, which I will have to investigate.

Regards


        Uz


-- 
Ullrich von Bassewitz                                  uz...@mu...
Encrypted email preferred                          PGP Key-Id: 29D93B10

Re: [Postfixadmin-devel] [PATCH] dovecot password encryption: Use old method, if detected

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

Hello,

Am Freitag, 14. Oktober 2016, 12:17:37 CEST schrieb Aaron Lindsay:
> I'm attaching a patch which should allow users to change their
> $CONF['encrypt'] setting and still allow passwords in the database
> encrypted with an older method to be used to login. Note that this is
> only for 'dovecot:' methods, and may require some manual database
> updates (i.e. if you used the 'md5crypt' method previously, you'll
> have to prefix all the existing password entries in the database with
> '{MD5-CRYPT}', since it only adds the '$1' prefix).
> 
> With those caveats out of the way, this seems to have allowed me to
> update my password configuration (making the password encryption
> stronger) without requiring all postfixadmin admins to immediately
> recreate new passwords. Please let me know if you see any issues with
> this patch - I'd love your feedback, and would like to see this
> upstream if possible.

Thanks for the patch!

It looks good, it works - and I just commited it to SVN r1875 ;-)


Regards,

Christian Boltz
-- 
Will ich mich demnaechst mal ranmachen,
allerdings momentan zuviel extrem unwichtige Sachen zu tun.
[Marcel Schmedes in suse-linux]   ^^

[Postfixadmin-devel] [PATCH] dovecot password encryption: Use old method, if detected

[Aaron L. <aa...@ac...>]

Hi,

I'm attaching a patch which should allow users to change their
$CONF['encrypt'] setting and still allow passwords in the database
encrypted with an older method to be used to login. Note that this is
only for 'dovecot:' methods, and may require some manual database
updates (i.e. if you used the 'md5crypt' method previously, you'll have
to prefix all the existing password entries in the database with
'{MD5-CRYPT}', since it only adds the '$1' prefix).

With those caveats out of the way, this seems to have allowed me to
update my password configuration (making the password encryption
stronger) without requiring all postfixadmin admins to immediately
recreate new passwords. Please let me know if you see any issues with
this patch - I'd love your feedback, and would like to see this upstream
if possible.

Thanks!

-Aaron

Re: [Postfixadmin-devel] MySQL SSL connection

[Lee C. <ja...@le...>]

On 10/02/2016 04:49 PM, Christian Boltz wrote:
> Hello,
> 
> Am Sonntag, 18. September 2016, 17:21:43 CEST schrieb Lee Clemens:
>> Is it possible to create a MySQL connection using SSL? It doesn't seem
>> the config options will be passed on to the underlying MySQL client
>> library.
> 
> No, we don't have code for that.
> 
> If you want to implement it yourself, have a look at functions.inc.php, 
> function db_connect().
> 
> I can't promise that we'll add this to the official code [1], but you'll 
> increase the chance if you send a patch ;-)
> 
> 
> Regards,
> 
> Christian Boltz
> 
> [1] I'd guess that most people connect to a MySQL server running on 
>     localhost, which makes SSL superfluous.
> 

Thank you for the reply and direction to the best function to look at.

I made some changes to use the mysqli_real_connect function, so there may be some compatibility concerns for really old version of php (<5)?

I tested it using database_ssl_ca, but ssl_set is a standard function and visibly appears to be passing in the other arguments correctly.

The database_port is also defined now, defaults to 3306, since it is an argument provided to mysqli_real_connect (was not previously configurable, iirc).

I believe the value for postgres will still be overridden in the $CONF array if:
// $CONF['database_port'] = '5432';
is uncommented in config.inc.php (further down from the new declaration I added).

The only performance impact should be seven additional keys (including the ability to specify the database_port for MySQL) in the default $CONF array and checking a single boolean per call to function db_connect.

Thanks,
Lee Clemens

* I understand it may be an uncommon requirement; I'm moving towards an 'encrypt everything' approach to security and these database connections occur over a shared network (aka 'cloud'...transiting the internet or just a service provider's internal hardware unencrypted).

Re: [Postfixadmin-devel] MySQL SSL connection

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

Hello,

Am Sonntag, 18. September 2016, 17:21:43 CEST schrieb Lee Clemens:
> Is it possible to create a MySQL connection using SSL? It doesn't seem
> the config options will be passed on to the underlying MySQL client
> library.

No, we don't have code for that.

If you want to implement it yourself, have a look at functions.inc.php, 
function db_connect().

I can't promise that we'll add this to the official code [1], but you'll 
increase the chance if you send a patch ;-)


Regards,

Christian Boltz

[1] I'd guess that most people connect to a MySQL server running on 
    localhost, which makes SSL superfluous.

-- 
Merke: die Nutzer von Facebook sind nicht "Kunden". Sie sind die Ware.
[Konni Scheller]

[Postfixadmin-devel] MySQL SSL connection

[Lee C. <ja...@le...>]

Hello,

Is it possible to create a MySQL connection using SSL? It doesn't seem the config options will be passed on to the underlying MySQL client library.

Thanks,
Lee Clemens