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

Re: [Postfixadmin-devel] config.local.php not being read.

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

Hello,

Am Montag, 13. April 2009 schrieb tan...@li...:
> Oh... wait... is this just for the admin password? Or for all email
> account passwords?

The $CONF['setup_password'] is the super-super-admin ;-) password needed 
to create new super-admins via setup.php. This is what I want to store 
in a hashed format (md5, sha1).

This change won't affect the passwords you have in your database for 
(super-)admins and mailboxes.

To make the story short: You'll (only) have to edit 
$CONF['setup_password'].


Regards,

Christian Boltz
-- 
Nicht das ich frei von Paranoia Schueben waere ;), aber wenn Dir das
passiert spiel sofort Lotto, bei dem Glueck bekommst Du bestimmt 4
Wochen den 6er mit Superzahl.   [Maik Holtkamp in suse-linux]

Re: [Postfixadmin-devel] config.local.php not being read.

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

tan...@li... wrote :
> On 4/13/2009 4:49 PM, David Goodwin wrote:
> >>> Final note: If we want to use md5 for the setup password, we should 
> >>> switch _now_ so that less users are affected.
> 
> >> I thought this would be optional... ? You're saying everyone would be
> >> FORCED to do so?
> 
> > Yes. The setup_password is a mandatory step now. Failing to do it
> > leaves a big security hole open when ever a user upgrades (especially
> > if it's automatic via e.g. apt)
> 
> Oh... wait... is this just for the admin password? Or for all email
> account passwords?

The passowrd which allows you to run the setup.php page (and create
new admin users)

David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] config.local.php not being read.

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

On 4/13/2009 4:49 PM, David Goodwin wrote:
>>> Final note: If we want to use md5 for the setup password, we should 
>>> switch _now_ so that less users are affected.

>> I thought this would be optional... ? You're saying everyone would be
>> FORCED to do so?

> Yes. The setup_password is a mandatory step now. Failing to do it
> leaves a big security hole open when ever a user upgrades (especially
> if it's automatic via e.g. apt)

Oh... wait... is this just for the admin password? Or for all email
account passwords?

Re: [Postfixadmin-devel] config.local.php not being read.

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

tan...@li... wrote :
> On 4/13/2009 3:14 PM, Christian Boltz wrote:
> > Final note: If we want to use md5 for the setup password, we should 
> > switch _now_ so that less users are affected.
> 
> I thought this would be optional... ? You're saying everyone would be
> FORCED to do so?
> 

Yes. The setup_password is a mandatory step now. Failing to do it
leaves a big security hole open when ever a user upgrades (especially
if it's automatic via e.g. apt)

David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] config.local.php not being read.

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

> 
> We could do it in setup.php like in the Typo3 install tool:
> 
>     "Wrong password! The password you entered has md5 hash ......"
> 
> > If they can read hte file, then they can read/write to the 
> > database....  so there would be bigger things to worry about. 
> 
> If an attacker can read config.inc.php (let's say by some vulnerable 
> other PHP scripts), there's still a difference:
> 
> a) using setup.php with the setup password is easy - just type it.
> b) using the database password requires access to phpMyAdmin etc.
>    which makes it at least slightly harder.
> 

OK. Change to use md5/sha1/whatever (perhaps embed sha1: at the start
of the string??)


> 
> Final note: If we want to use md5 for the setup password, we should 
> switch _now_ so that less users are affected.

OK. Well volunteered :)

David.

-- 
David Goodwin 

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

Re: [Postfixadmin-devel] config.local.php not being read.

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

On 4/13/2009 3:14 PM, Christian Boltz wrote:
> Final note: If we want to use md5 for the setup password, we should 
> switch _now_ so that less users are affected.

I thought this would be optional... ? You're saying everyone would be
FORCED to do so?

-- 

Best regards,

Charles

Re: [Postfixadmin-devel] config.local.php not being read.

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

Hello,

Am Montag, 13. April 2009 schrieb David Goodwin:
> > - What about checking setup_password only in setup.php?
>
> We could do.
>
> > - What about storing the password md5-hashed? That makes it harder
> > for the admin to set it up, but is more secure if someone manages
> > to read config.inc.php...
>
> Hmm... it's a pain for administrators to create a md5-hashed password
> on the command line - isn't it? 

More or less ;-)

We could do it in setup.php like in the Typo3 install tool:

    "Wrong password! The password you entered has md5 hash ......"

> If they can read hte file, then they can read/write to the 
> database....  so there would be bigger things to worry about. 

If an attacker can read config.inc.php (let's say by some vulnerable 
other PHP scripts), there's still a difference:

a) using setup.php with the setup password is easy - just type it.
b) using the database password requires access to phpMyAdmin etc.
   which makes it at least slightly harder.

We could also get rid of the code checking for "changeme" or empty setup 
password - md5(something) will never return "changeme" ;-) and the user 
will simply run into the "wrong setup password" message.

Final note: If we want to use md5 for the setup password, we should 
switch _now_ so that less users are affected.


Regards,

Christian Boltz
-- 
> Hilft vielleicht noch etwas anderes?
Eine genaue Fehlerbeschreibung. (Glaskugel oder Karten versagen bei 
technischen Problemen immer, daher packe ich die auch nicht aus).
[Helga Fischer in suse-linux]

Re: [Postfixadmin-devel] config.local.php not being read.

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

> @GingerDog: 
> - What about checking setup_password only in setup.php?


We could do.

> - What about storing the password md5-hashed? That makes it harder for 
>   the admin to set it up, but is more secure if someone manages to read 
>   config.inc.php...
> 

Hmm... it's a pain for administrators to create a md5-hashed password
on the command line - isn't it? If they can read hte file, then they
can read/write to the database....  so there would be bigger things to
worry about.

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

On Mon, 13 Apr 2009, Christian Boltz wrote:

> Hello,
>
> Am Montag, 13. April 2009 schrieb me...@td...:
>> On Sun, 12 Apr 2009, Christian Boltz wrote:
>>> You have to add a setup password: (that's quite new! - r616)
>>>    $CONF['setup_password'] = "topsecret";
>>
>> That was it. I missed the setup_password parameter but set it in
>> config.inc.local when I needed to add the superuser. It never
>> occurred to me that not having that parameter set would keep
>> config.local.php from working.
>
> Not having the setup_password set will keep postfixadmin from working at
> all.
>
> @GingerDog:
> - What about checking setup_password only in setup.php?
> - What about storing the password md5-hashed? That makes it harder for
>  the admin to set it up, but is more secure if someone manages to read
>  config.inc.php...
>
>> I was thinking that the values set in config.inc.local will over
>> write values set in config.inc.php
>
> Typo? The first filename should be ...local.php ;-)

Yes!! Sorry. :-(

>
>> but if a value parameter does not
>> exist in config.local.php then the value in config.inc.php will be in
>> effect.
>
> Correct.
>
>> This would appear to be wrong since the default
>> config.inc.php was set to $CONF['setup_password'] = 'changeme';
>
> We have a special check if the setup_password is "changeme" ;-)
>
>    if($CONF['setup_password'] == 'changeme') {
>        die("You must specify a password in config.inc.php
>             (\$CONF['setup_password']) in order to access setup.php");
>    }

Hummm, interesting. I did not get that error the first. Wonder what
I did wrong. Oh well it is now working as advertised.

>
> (see also .sig below *g*)

:-)

>
>> So my question is does config.inc.php get read at all if
>> config.local.php exists? It would appear not but I just want to be
>> sure.
>
> First config.inc.php is read, then config.local.php.
>
> This means that settings in config.local.php will overwrite settings
> from config.inc.php.

Thanks., I think I got it now. :-)

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

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

Hello,

Am Montag, 13. April 2009 schrieb me...@td...:
> On Sun, 12 Apr 2009, Christian Boltz wrote:
> > You have to add a setup password: (that's quite new! - r616)
> >    $CONF['setup_password'] = "topsecret";
>
> That was it. I missed the setup_password parameter but set it in
> config.inc.local when I needed to add the superuser. It never
> occurred to me that not having that parameter set would keep
> config.local.php from working.

Not having the setup_password set will keep postfixadmin from working at 
all.

@GingerDog: 
- What about checking setup_password only in setup.php?
- What about storing the password md5-hashed? That makes it harder for 
  the admin to set it up, but is more secure if someone manages to read 
  config.inc.php...

> I was thinking that the values set in config.inc.local will over
> write values set in config.inc.php 

Typo? The first filename should be ...local.php ;-)

> but if a value parameter does not 
> exist in config.local.php then the value in config.inc.php will be in
> effect. 

Correct.

> This would appear to be wrong since the default 
> config.inc.php was set to $CONF['setup_password'] = 'changeme';

We have a special check if the setup_password is "changeme" ;-)

    if($CONF['setup_password'] == 'changeme') {
        die("You must specify a password in config.inc.php
             (\$CONF['setup_password']) in order to access setup.php");
    }

(see also .sig below *g*)

> So my question is does config.inc.php get read at all if
> config.local.php exists? It would appear not but I just want to be
> sure.

First config.inc.php is read, then config.local.php.

This means that settings in config.local.php will overwrite settings 
from config.inc.php.


Regards,

Christian Boltz
-- 
looks like you have some special code in yast for password "x", maybe I
should use the even more secure new password "y" in the future  ?! ;-)
[Harald Koenig in https://bugzilla.novell.com/show_bug.cgi?id=148464]

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

On Sun, 12 Apr 2009, Christian Boltz wrote:

> Hello,
>
> Am Sonntag, 12. April 2009 schrieb me...@td...:
>> On Sun, 12 Apr 2009, David Goodwin wrote:
>>> me...@td... wrote :
>>>> On Sat, 11 Apr 2009, me...@td... wrote:
>>>>> The following is what I have in config.local.php:
>>>>>
>>>>> <?php
>>>>> $CONF['configured'] = true;
> ...
>>> I wasn't aware of config.local.php - this is a new thing to me
>
> Oh, it's quite old ;-)
>
> svn annotate says:
>   151 christian_boltz // If you want to keep most settings at default values and/or want to ensure
>   151 christian_boltz // that future updates work without problems, you can use a separate config
>   151 christian_boltz // file (config.local.php) instead of editing this file and override some
>   151 christian_boltz // settings there.
>   251  GingerDog      if (file_exists(dirname(__FILE__) . '/config.local.php')) { # for /
>   251  GingerDog          include(dirname(__FILE__) . '/config.local.php');
>   251  GingerDog      }
>
> The basic idea was from me (r151, 2007-10-12), and you (GingerDog) then
> made the better inclusion code in r251 (2007-12-02) ;-)
>
>> So should I assume this will not work, is this something that is
>> likely to be fixed or am I asking the wrong person? I like the idea
>> of not having my config file overwritten during upgrades but it is
>> not the end of the earth either.
>
> Using config.local.php works for me without problems.
>
> If you are unsure if config.local.php is read on your system, add something like
>    die ("reading config.local.php works");
> to config.local.php ;-)
>
> After testing with your config.local.php, I'm quite sure it misses a
> setting.
> You have to add a setup password: (that's quite new! - r616)
>    $CONF['setup_password'] = "topsecret";

That was it. I missed the setup_password parameter but set it in
config.inc.local when I needed to add the superuser. It never occurred to me
that not having that parameter set would keep config.local.php from working.

Am I missing how this config.inc.php vs config.inc.local works?

I was thinking that the values set in config.inc.local will over write values
set in config.inc.php but if a value parameter does not exist in 
config.local.php then the value in config.inc.php will be in effect. This would
appear to be wrong since the default config.inc.php was set to
$CONF['setup_password'] = 'changeme';

So my question is does config.inc.php get read at all if config.local.php exists?
It would appear not but I just want to be sure.

If my suspicions are correct then might I suggest indicating that in the
comments to avoid others getting confused.

Thanks for the help.

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

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

Hello,

Am Sonntag, 12. April 2009 schrieb me...@td...:
> On Sun, 12 Apr 2009, David Goodwin wrote:
> > me...@td... wrote :
> >> On Sat, 11 Apr 2009, me...@td... wrote:
> >>> The following is what I have in config.local.php:
> >>>
> >>> <?php
> >>> $CONF['configured'] = true;
...
> > I wasn't aware of config.local.php - this is a new thing to me

Oh, it's quite old ;-)

svn annotate says:
   151 christian_boltz // If you want to keep most settings at default values and/or want to ensure
   151 christian_boltz // that future updates work without problems, you can use a separate config
   151 christian_boltz // file (config.local.php) instead of editing this file and override some
   151 christian_boltz // settings there.
   251  GingerDog      if (file_exists(dirname(__FILE__) . '/config.local.php')) { # for /
   251  GingerDog          include(dirname(__FILE__) . '/config.local.php');
   251  GingerDog      }

The basic idea was from me (r151, 2007-10-12), and you (GingerDog) then 
made the better inclusion code in r251 (2007-12-02) ;-)

> So should I assume this will not work, is this something that is
> likely to be fixed or am I asking the wrong person? I like the idea
> of not having my config file overwritten during upgrades but it is
> not the end of the earth either.

Using config.local.php works for me without problems.

If you are unsure if config.local.php is read on your system, add something like
    die ("reading config.local.php works");
to config.local.php ;-)

After testing with your config.local.php, I'm quite sure it misses a 
setting.
You have to add a setup password: (that's quite new! - r616)
    $CONF['setup_password'] = "topsecret";

After this change (and changing the database secrets to match my 
installation), I can login.

If it still doesn't work, check if you have a typo in the filename ;-)


Regards,

Christian Boltz
-- 
Ich freue mich auf das Eröffnungsspiel Deutschland gegen Costa Rica.
Auf der einen Seite eine Bananenrepublik und auf der anderen Seite:
Costa Rica.   [Thomas Gottschalk, Wetten dass...?, 10.12.2005]

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

On Sun, 12 Apr 2009, David Goodwin wrote:

> me...@td... wrote :
>> Hi,
>>
>> Sorry to followup to my own post but I have more info to add. Please see below.
>>
>> On Sat, 11 Apr 2009, me...@td... wrote:
>>
>>> Hi,
>>>
>>> I did an svn co on trunk today (rev 626). I have a config.local.php that is
>>> not being read when I try to run setup.php. When I try to run setup.php, I
>>> get the following warning:
>>> Please edit config.inc.php - change $CONF['configured'] to true after
>>> setting your database settings
>>>
>>> If I modify config.inc.php as instructed above then the warning goes away
>>> but my database config does not get read since the settings for it are in
>>> config.local.php. I have another test system with svn rev 564 installed
>>> using the same config.local.php except for some machine specific changes and
>>> it works as advertised.
>>>
>>> Can someone give me an idea how to troubleshoot this problem? A diff of
>>> config.inc.php between the 2 systems shows nothing significant. The
>>> following is what I have in config.local.php:
>>>
>>> <?php
>>> $CONF['configured'] = true;
>>>
>>> $CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';
>>>
>>> $CONF['database_type'] = 'mysqli';
>>> $CONF['database_host'] = 'localhost';
>>> $CONF['database_user'] = 'mydb_user';
>>> $CONF['database_password'] = 'my_passwd';
>>> $CONF['database_name'] = 'postfix';
>>> $CONF['database_prefix'] = '';
>>>
>>> $CONF['encrypt'] = 'system';
>>>
>>> $CONF['alias_control'] = 'YES';
>>> $CONF['alias_control_admin'] = 'YES';
>>>
>>> $CONF['create_mailbox_subdirs_prefix']='';
>>
>> In config.inc.php we have he following statement:
>> /*****************************************************************
>>   *  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>>   * The following line needs commenting out or removing before the
>>   * application will run!
>>   * Doing this implies you have changed this file as required.
>>   * i.e. configuring database etc; specifying setup.php password etc.
>> $CONF['configured'] = false;
>>   */
>>
>> If as it says above I simply comment out the configured statement
>> and make all of my local changes to config.local.php, I am then able to
>> run setup.php successfully and add my superuser account. The problem
>> is that I still cannot login to pfa. I never get the login screen, I keep
>> getting the "Welcome to Postfix Admin" screen. If I change the
>> $CONF['configured'] = false; to $CONF['configured'] = true; and uncomment
>> it, then I get a login screen and I am able to login successfully.
>>
>> This is a new install on a test box. No upgrades involved.
>>
>> Is this a bug or a feature? :-) If it is a bug should I file a bug report
>> somewhere?
>>
>
>
> I'd guess that config.local.php isn't being read in, to overwrite
> anything in config.inc.php
>
> I wasn't aware of config.local.php - this is a new thing to me

I was just going by the comments at the bottom of config.inc.php which say:

// If you want to keep most settings at default values and/or want to ensure
// that future updates work without problems, you can use a separate config
// file (config.local.php) instead of editing this file and override some
// settings there.
if (file_exists(dirname(__FILE__) . '/config.local.php')) { # for /
     include(dirname(__FILE__) . '/config.local.php');

So should I assume this will not work, is this something that is likely to
be fixed or am I asking the wrong person? I like the idea of not having
my config file overwritten during upgrades but it is not the end of the
earth either.

Thanks for the response.

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] config.local.php not being read.

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

me...@td... wrote :
> Hi,
> 
> Sorry to followup to my own post but I have more info to add. Please see below.
> 
> On Sat, 11 Apr 2009, me...@td... wrote:
> 
> > Hi,
> >
> > I did an svn co on trunk today (rev 626). I have a config.local.php that is
> > not being read when I try to run setup.php. When I try to run setup.php, I
> > get the following warning:
> > Please edit config.inc.php - change $CONF['configured'] to true after
> > setting your database settings
> >
> > If I modify config.inc.php as instructed above then the warning goes away
> > but my database config does not get read since the settings for it are in
> > config.local.php. I have another test system with svn rev 564 installed
> > using the same config.local.php except for some machine specific changes and
> > it works as advertised.
> >
> > Can someone give me an idea how to troubleshoot this problem? A diff of
> > config.inc.php between the 2 systems shows nothing significant. The
> > following is what I have in config.local.php:
> >
> > <?php
> > $CONF['configured'] = true;
> >
> > $CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';
> >
> > $CONF['database_type'] = 'mysqli';
> > $CONF['database_host'] = 'localhost';
> > $CONF['database_user'] = 'mydb_user';
> > $CONF['database_password'] = 'my_passwd';
> > $CONF['database_name'] = 'postfix';
> > $CONF['database_prefix'] = '';
> >
> > $CONF['encrypt'] = 'system';
> >
> > $CONF['alias_control'] = 'YES';
> > $CONF['alias_control_admin'] = 'YES';
> >
> > $CONF['create_mailbox_subdirs_prefix']='';
> 
> In config.inc.php we have he following statement:
> /*****************************************************************
>   *  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
>   * The following line needs commenting out or removing before the
>   * application will run!
>   * Doing this implies you have changed this file as required.
>   * i.e. configuring database etc; specifying setup.php password etc.
> $CONF['configured'] = false;
>   */
> 
> If as it says above I simply comment out the configured statement
> and make all of my local changes to config.local.php, I am then able to
> run setup.php successfully and add my superuser account. The problem
> is that I still cannot login to pfa. I never get the login screen, I keep
> getting the "Welcome to Postfix Admin" screen. If I change the 
> $CONF['configured'] = false; to $CONF['configured'] = true; and uncomment
> it, then I get a login screen and I am able to login successfully.
> 
> This is a new install on a test box. No upgrades involved.
> 
> Is this a bug or a feature? :-) If it is a bug should I file a bug report
> somewhere?
> 


I'd guess that config.local.php isn't being read in, to overwrite
anything in config.inc.php

I wasn't aware of config.local.php - this is a new thing to me

thanks
David.


-- 
David Goodwin 

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

Re: [Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

Hi,

Sorry to followup to my own post but I have more info to add. Please see below.

On Sat, 11 Apr 2009, me...@td... wrote:

> Hi,
>
> I did an svn co on trunk today (rev 626). I have a config.local.php that is
> not being read when I try to run setup.php. When I try to run setup.php, I
> get the following warning:
> Please edit config.inc.php - change $CONF['configured'] to true after
> setting your database settings
>
> If I modify config.inc.php as instructed above then the warning goes away
> but my database config does not get read since the settings for it are in
> config.local.php. I have another test system with svn rev 564 installed
> using the same config.local.php except for some machine specific changes and
> it works as advertised.
>
> Can someone give me an idea how to troubleshoot this problem? A diff of
> config.inc.php between the 2 systems shows nothing significant. The
> following is what I have in config.local.php:
>
> <?php
> $CONF['configured'] = true;
>
> $CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';
>
> $CONF['database_type'] = 'mysqli';
> $CONF['database_host'] = 'localhost';
> $CONF['database_user'] = 'mydb_user';
> $CONF['database_password'] = 'my_passwd';
> $CONF['database_name'] = 'postfix';
> $CONF['database_prefix'] = '';
>
> $CONF['encrypt'] = 'system';
>
> $CONF['alias_control'] = 'YES';
> $CONF['alias_control_admin'] = 'YES';
>
> $CONF['create_mailbox_subdirs_prefix']='';

In config.inc.php we have he following statement:
/*****************************************************************
  *  !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
  * The following line needs commenting out or removing before the
  * application will run!
  * Doing this implies you have changed this file as required.
  * i.e. configuring database etc; specifying setup.php password etc.
$CONF['configured'] = false;
  */

If as it says above I simply comment out the configured statement
and make all of my local changes to config.local.php, I am then able to
run setup.php successfully and add my superuser account. The problem
is that I still cannot login to pfa. I never get the login screen, I keep
getting the "Welcome to Postfix Admin" screen. If I change the 
$CONF['configured'] = false; to $CONF['configured'] = true; and uncomment
it, then I get a login screen and I am able to login successfully.

This is a new install on a test box. No upgrades involved.

Is this a bug or a feature? :-) If it is a bug should I file a bug report
somewhere?

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

[Postfixadmin-devel] config.local.php not being read.

[<me...@td...>]

Hi,

I did an svn co on trunk today (rev 626). I have a config.local.php that is
not being read when I try to run setup.php. When I try to run setup.php, I
get the following warning:
Please edit config.inc.php - change $CONF['configured'] to true after
setting your database settings

If I modify config.inc.php as instructed above then the warning goes away
but my database config does not get read since the settings for it are in
config.local.php. I have another test system with svn rev 564 installed
using the same config.local.php except for some machine specific changes and
it works as advertised.

Can someone give me an idea how to troubleshoot this problem? A diff of
config.inc.php between the 2 systems shows nothing significant. The
following is what I have in config.local.php:

<?php
$CONF['configured'] = true;

$CONF['postfix_admin_url'] = 'http://foggy.tntechs.com/pfa';

$CONF['database_type'] = 'mysqli';
$CONF['database_host'] = 'localhost';
$CONF['database_user'] = 'mydb_user';
$CONF['database_password'] = 'my_passwd';
$CONF['database_name'] = 'postfix';
$CONF['database_prefix'] = '';

$CONF['encrypt'] = 'system';

$CONF['alias_control'] = 'YES';
$CONF['alias_control_admin'] = 'YES';

$CONF['create_mailbox_subdirs_prefix']='';

Regards,

-- 
Tom			me...@td...		Spamtrap address	 		me...@td...

Re: [Postfixadmin-devel] xmlrpc.php, tests/* and some possible bugs

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

Hello,

Am Samstag, 11. April 2009 schrieb Christian Boltz:
> [several possible bugs]

I commited the fixes as discussed on IRC.

When I now run tests/run.php, I _sometimes_ get 1 failure.

Postfixadmin XMLRPC Unit Tests
1)  at [/home/cb/postfixadmin/HEAD/tests/RemoteAliasTest.php line 44]
        in testUpdateRemoteOnly
        in RemoteAliasTest
        in ./RemoteAliasTest.php
FAILURES!!!
Test cases run: 4/4, Passes: 26, Failures: 1, Exceptions: 0

Some testing shows that it might be a race condition.
Adding a sleep(1) to RemoteAliasTest.php (see patch below) fixes the 
problem and the testcases work without a failure.

Do you have any idea what could cause the race condition in this
specific test?

--- RemoteAliasTest.php (Revision 626)
+++ RemoteAliasTest.php (Arbeitskopie)
@@ -41,7 +41,7 @@
     public function testUpdateRemoteOnly() {
         $this->assertTrue($this->alias->update(array('ro...@ra...'), 'remote_only'));
         $this->assertFalse($this->alias->hasStoreAndForward());
-        $this->assertTrue($this->alias->update(array('ro...@ra...'), 'remote_only'));
+        sleep(1); $this->assertTrue($this->alias->update(array('ro...@ra...'), 'remote_only'));
         $this->assertTrue($this->alias->update(array('ro...@ra...', 'fi...@fi...', 'ro...@ru...'), 'remote_only'));
         $this->assertEqual($this->alias->get(), array('ro...@ra...', 'fi...@fi...', 'ro...@ru...'));
         $this->assertFalse($this->alias->hasStoreAndForward());


Regarding error_reporting:
> IMHO run.php should ini_set() it to be really sure we catch all
> undefined variables etc. which won't cause noticable errors ("just"
> strange bugs) otherwise.

Unfortunately setting error_reporting in tests/run.php doesn't help much.
The reason is that the tests do http calls to xmlrpc.php, and therefore the
setting in php.ini is used on the xmlrpc.php side...

Another small issue: The tests should clean up the database after being 
run IMHO. (Or at least use a random password for the mailbox created by the
tests to avoid abuse if someone runs the tests on a public server.)


Regards,

Christian Boltz
-- 
Das ist die Goldene Regel für das Performancetuning von
UNIX-Systemen: RAM ist nur durch mehr RAM zu ersetzen.
[Kristian Koehntopp in suse-linux]

[Postfixadmin-devel] xmlrpc.php, tests/* and some possible bugs

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

Hello,

I played a bit with the tests/ directory and found some possible bugs.

a) xmlrpc.php
session_start results in a "session already started" notice - common.php
already starts the session

b) model/UserHandler.php
db_log is called with the undefined variable $USERID_USERNAME - 
$username should work

c) tests/RemoteTest.php
- there should be a better way than hardcoding $server_url (using 
  $CONF?)
- the ro...@ex... test mailbox should should have a valid maildir 
  set - otherwise edit_mailbox won't allow any changes for it

A patch for those issues is attached. I didn't commit it yet because I'm 
not sure if my changes do what you (GingerDog) wanted the code to do.

Even with this patch, some problems remain:

---------------------------------------------------------------------------------------------------
Postfixadmin XMLRPC Unit Tests
string(342) "
Notice: Undefined variable: domain in ../model/AliasHandler.php on line 157

Notice: Undefined variable: domain in ../model/AliasHandler.php on line 157
<?xml version="1.0" encoding="UTF-8"?>
<methodResponse><params><param><value><boolean>1</boolean></value></param></params></methodResponse>
"
Exception 1!
Unexpected exception of type [Zend_XmlRpc_Client_FaultException] with message [Failed to parse response] in 
[/usr/share/php5/Zend/XmlRpc/Client.php line 349]
Exception 2!
Unexpected exception of type [Zend_XmlRpc_Client_FaultException] with message [Failed to parse response] in 
[/usr/share/php5/Zend/XmlRpc/Client.php line 349]
Exception 3!
Unexpected exception of type [Zend_XmlRpc_Client_FaultException] with message [Failed to parse response] in 
[/usr/share/php5/Zend/XmlRpc/Client.php line 349]
FAILURES!!!
Test cases run: 4/4, Passes: 11, Failures: 0, Exceptions: 3
---------------------------------------------------------------------------------------------------

Note: I use error_reporting = E_ALL, and I recommend to use this setting 
on every development system. 

IMHO run.php should ini_set() it to be really sure we catch all undefined 
variables etc. which won't cause noticable errors ("just" strange bugs)
otherwise.


Regards,

Christian Boltz
-- 
I tip my hat to the creators of the SomeFool virus, for actually (albeit
temporarily and minimally) affecting my Linux experience. However, if
that's the most damage I can get by running viruses with Wine under a
dummy account, then it's clear that the Wine developers have a long way
to go before Wine is truly Windows compatible.
[http://os.newsforge.com/article.pl?sid=05/01/25/1430222&from=rss]

Re: [Postfixadmin-devel] Moving towards 2.3......

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

Hello,

Am Donnerstag, 2. April 2009 schrieb David Goodwin:
> This is just to make sure this mailing list isn't declared dead....

I'm alive, but (too) busy ;-)

> I've just committed a bug fix (I hope) to edit-alias.php so it
> respects the settings in $CONF (particularly special_alias_admin).
>
> Assuming this hasn't introduced any bugs (my limited testing here
> seems to indicate that it's fine....) I'll release rc4 (if that's the
> next one) within the next day or two (this is dependent on me hearing
> back from someone with regards to whether alias editing is now
> working correctly!).

You mean
https://sourceforge.net/tracker/?func=detail&aid=2745147&group_id=191583&atid=937964
? Good to see that I'm not the only one who creates blocker bugs shortly 
before a release ;-)

(Note: I didn't test this myself yet.)

> Development wise - I've pretty much stalled on my effort to integrate
> amavis support, however some busy people are migrating Postfixadmin
> 2.3 to use Smarty (see postfixadmin-smarty branch in subversion). I'm
> not quite sure where this will lead us yet - someone else is
> undertaking a zend framework migration - and the two will probably
> conflict a little...

Not necessarily - given we find some time to do the long-planned code 
redesign, it will be like switching skins in the best case.

I guess we'll have to do lots of abstraction work to keep both frontends 
in sync more or less automatically, but it is doable and might even 
save us time on the long run.

My favorite example: Adding a field for fetchmail.php:
1. add the field in the database / upgrade.php
2. add _one line_ to the fm_struct array
3. add the field title and description to the language files
4. (optional) use the field in fetchmail.pl
Done :-)

When we have all parts of postfixadmin editable in this easy way, 
changes will be easier than today. (This will probably also extremely 
speed up adding amavis support.)

Oh, and we'll need only two templates: "list view" and "edit view" (with 
subtemplates for different field types). These templates can be used 
for all modules - this gives us a common layout in all modules besides 
saving lots of work.

> (In that although you can use smarty with the 
> Zend Framework, it's probably best to stick with Zend_View - or will
> things like Zend_Layout work with Smarty?).

Good question - since I don't know the Zend framework and didn't do much 
with smarty yet, I have no idea.


Regards,

Christian Boltz
-- 
Microsoft is a cross between The Borg and the Ferengi. Unfortunately
they use Borg to do their marketing and Ferengi to do their programming.
                                               [Simon Slavin in the SDM]

Re: [Postfixadmin-devel] readme suggestion

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

Hello,

Am Sonntag, 22. März 2009 schrieb Daniel Reichelt:
> I just noted that in DOCUMENTS/POSTFIX_CONF the example SQL queries
> for mysql_virtual_alias_domain_maps.cf and
>   mysql_virtual_alias_domain_catchall_maps.cf

You missed mysql_virtual_mailbox_maps.cf ;-)

> should be extended by
>   AND alias_domain.active='1'
> thus taking the active/inactive state of the virtual alias domain
> into account as well, not only the status of the alias.

Thanks for pointing this out.

Commited to SVN r620.


Regards,

Christian Boltz
-- 
PHP bietet einige Möglicheiten etwas falsch zu machen. 
Die phpBB Entwickler haben wohl viele dieser Möglichkeiten genutzt.
[Kommentar auf http://www.pro-linux.de/news/2007/12106.html]

[Postfixadmin-devel] Moving towards 2.3......

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

Hello other postfixadmin-developers...


This is just to make sure this mailing list isn't declared dead....

I've just committed a bug fix (I hope) to edit-alias.php so it
respects the settings in $CONF (particularly special_alias_admin).

Assuming this hasn't introduced any bugs (my limited testing here
seems to indicate that it's fine....) I'll release rc4 (if that's the
next one) within the next day or two (this is dependent on me hearing
back from someone with regards to whether alias editing is now working
correctly!).

If that goes well, I intend to release 2.3 final after a few more days
(probably on/around the 10th of April - which should give people time
to report any problems if there are any).


Development wise - I've pretty much stalled on my effort to integrate
amavis support, however some busy people are migrating Postfixadmin
2.3 to use Smarty (see postfixadmin-smarty branch in subversion). I'm
not quite sure where this will lead us yet - someone else is
undertaking a zend framework migration - and the two will probably
conflict a little... (In that although you can use smarty with the
Zend Framework, it's probably best to stick with Zend_View - or will
things like Zend_Layout work with Smarty?). 


David.
-- 
David Goodwin 

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

Re: [Postfixadmin-devel] Smarty version online

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

Sebastian wrote :
> 
> Message body follows:
> 
> Hi Gingerdog,
> 
> I've commited the working and optimized version of PFA using
> smarty.
> 
> Maybe you've got a bit of time to review. I'll be off next
> week...
> 

Thanks; I've seen the commit messages, but had no chance to look at
it.

thanks
David.

-- 
David Goodwin 

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

[Postfixadmin-devel] readme suggestion

[Daniel R. <ma...@it...>]

Hi list,

I just noted that in DOCUMENTS/POSTFIX_CONF the example SQL queries for
  mysql_virtual_alias_domain_maps.cf and
  mysql_virtual_alias_domain_catchall_maps.cf
should be extended by
  AND alias_domain.active='1'
thus taking the active/inactive state of the virtual alias domain into account
as well, not only the status of the alias.

Cheers,
Daniel

Re: [Postfixadmin-devel] vacation sends message double

[Marko W. | Salondigital.d. <mar...@sa...>]

David,
i found this in the log "messages"

Feb 26 23:58:13 kraftwerk1 Vacation: Orig-To: we...@do... From: 
we...@do... MessageID:  Subject: . Log message: Unexpected error: 
'Duplicate entry 'we...@do...-w...@do...' for key 1' from query 
'INSERT into vacation_notification (on_vacation,notified) values (?,?)'

so is this a bug by "Vacation" ?

marko



Marko Weber | Salondigital.de schrieb:
> Hi David,
> your posted link dont fixed anything. Vacation Messages still come twice.
> The people in the posting talk about dspam sendings and such or ?
> My Problem is, when a user activates vacation, the vacation message is 
> sent twice.
> I tried some tips from the post but it dont worked.
>
> Let me know if you can help a bit and if you need anything maybe 
> master.cf or main.cf
>
> marko
>
>
>
> David Goodwin schrieb:
>   
>> Marko Weber | Salondigital.de wrote :
>>   
>>     
>>> Hello,
>>> when vacation is enabled , the vacation message is sent twice.
>>> i dont get it why.
>>> any ideas ?
>>>
>>> marko
>>>
>>>
>>>     
>>>       
>> See e.g.
>> https://sourceforge.net/forum/forum.php?thread_id=3026548&forum_id=676076
>>
>> David.
>>   
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
>> -Strategies to boost innovation and cut costs with open source participation
>> -Receive a $600 discount off the registration fee with the source code: SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>>
>>
>>   
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Postfixadmin-devel mailing list
>> Pos...@li...
>> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>>
>>
>> 
>>   
>>     
>
> !DSPAM:171,49a6f77f68524591543903!
>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
> -Strategies to boost innovation and cut costs with open source participation
> -Receive a $600 discount off the registration fee with the source code: SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Postfixadmin-devel mailing list
> Pos...@li...
> https://lists.sourceforge.net/lists/listinfo/postfixadmin-devel
>
> !DSPAM:23,49a6f7b068521366920555!
>
>
>   

!DSPAM:171,49a7200068521787718140!

Re: [Postfixadmin-devel] vacation sends message double

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

Marko Weber | Salondigital.de wrote :
> Hi David,
> your posted link dont fixed anything. Vacation Messages still come twice.
> The people in the posting talk about dspam sendings and such or ?
> My Problem is, when a user activates vacation, the vacation message is 
> sent twice.
> I tried some tips from the post but it dont worked.
> 
> Let me know if you can help a bit and if you need anything maybe 
> master.cf or main.cf
> 
> marko
> 

Hi,

I suggest you post your problem + master.cf settings on the forum.

thanks
David.

-- 
David Goodwin 

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