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

[Postfixadmin-devel] Quota bug

[Bertrand C. <ber...@fr...>]

Hi everyone, 
I'm new in using postfixadmin and I'm french. 
I'm having a bug, I changed quota to 200MB max and it is blocked to 10MB 
When I'm adding a new virtual account and quota more than 10MB, it says in French " La limite que vous avez specifie est trop haute!" it might be like this "The limit you specified is too high!" . 
It thought the config.inc.php wasn't consider into postfixadmin but I launched upgrade.php and setup.php too and it doesn't change anything. 
Sorry for my incompetence and thanks for your help, 

-- 





Bertrand Caplet 

Re: [Postfixadmin-devel] Admin interface is broken and no longer useable

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

On 23 Apr 2012, at 16:12, Johnny Solbu wrote:

> On Monday 23 April 2012 10:41, David Goodwin wrote:
>> I thought we'd removed the ereg() stuff some time ago
> 
> If you did, it's not apparently clear that one /also/ should upgrade the config file, as config files are seldom upgraded unless one must.
> 
>> so I'm skeptical that you're actually using the latest release.
> 
> We upgraded to the latest postfixadmin yesterday.
> The only part we never upgrade in upgrades, unless some acompanying documentation or comments in the new config file (with sufix .dpkg-dist) says otherwise, is the config file. One should always reuse the same config file in most software who's config files resides in the /etc tree.

Hi,

Yes - but we've supported a config.local.php for some time now - which should stop/save you from changing the 'shipped' config.inc.php.

I agree it's not ideal to change the config file…. but sometimes it's necessary (e.g. merging in new features) - and coping with deprecated stuff from PHP!

thanks
David.

Re: [Postfixadmin-devel] Fwd: Admin interface is broken and no longer useable

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

On Monday 23 April 2012 10:41, David Goodwin wrote:
> I thought we'd removed the ereg() stuff some time ago

If you did, it's not apparently clear that one /also/ should upgrade the config file, as config files are seldom upgraded unless one must.

> so I'm skeptical that you're actually using the latest release.

We upgraded to the latest postfixadmin yesterday.
The only part we never upgrade in upgrades, unless some acompanying documentation or comments in the new config file (with sufix .dpkg-dist) says otherwise, is the config file. One should always reuse the same config file in most software who's config files resides in the /etc tree.

-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0xFA687324
********************************
Kom Arbeidslyst og treng deg på,
her skal du motstand finne.

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[1375] tags/postfixadmin-2.3.5/debian

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

On 26 Apr 2012, at 20:51, no...@us... wrote:

> Revision: 1375
>          http://postfixadmin.svn.sourceforge.net/postfixadmin/?rev=1375&view=rev
> Author:   normes
> Date:     2012-04-26 19:51:28 +0000 (Thu, 26 Apr 2012)
> Log Message:
> -----------
> Updated to current Debian package (now accepted official in Debian/testing, yay\!)

Congratulations and thank you!

David.

Re: [Postfixadmin-devel] (SOLVED) Admin interface is broken and no longer useable

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

On Monday 23 April 2012 18:41, Rudi Floren wrote:
> You can delete these lines without care.

And it still works. yay!
Thank you. :-)=

-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0xFA687324
********************************
Kom Arbeidslyst og treng deg på,
her skal du motstand finne.

Re: [Postfixadmin-devel] (SOLVED) Admin interface is broken and no longer useable

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

On Monday 23 April 2012 13:44, Rudi Floren wrote:
> Please post the lines where the ereg in config.inc.php is located. We 
> suggest some fixes for you.

if (ereg ("config.inc.php", $_SERVER['PHP_SELF']))
{
   header ("Location: login.php");
   exit;
}


-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0xFA687324
********************************
Kom Arbeidslyst og treng deg på,
her skal du motstand finne.

Re: [Postfixadmin-devel] Admin interface is broken and no longer useable

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

On Monday 23 April 2012 13:59, Christian Boltz wrote:
> Please upgrade to 2.3.5, which includes some security fixes.

We did that yesterday, prior to googleing and asking on this list,
which is why I am here, as the latest version apparently didn't fix this.

-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0xFA687324
********************************
Kom Arbeidslyst og treng deg på,
her skal du motstand finne.

Re: [Postfixadmin-devel] Admin interface is broken and no longer useable

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

Hello,

Am Montag, 23. April 2012 schrieb Johnny Solbu:
> We have just upgraded to the newest version

The "headers already sent" errors are nearly always follow-up errors. 
The real error is:

> Deprecated: Function ereg() is deprecated in
> /etc/postfixadmin/config.inc.php on line 19 ==

However, PostfixAdmin 2.3.5 and SVN trunk do not include any ereg() call 
(older versions < 2.3 did).

In other words: you are probably using an outdated version of 
PostfixAdmin. Please upgrade to 2.3.5, which includes some security 
fixes.


Regards,

Christian Boltz
-- 
Ich wäre für die Einführung der Scharia: "Ist _dies_ hier die Zunge, mit
der du dummes Zeug geredet hast? Und die Hand hier hat es getippt?" Da
kriegt die Bezeichnung "Hacker" doch eine ganz neue Bedeutung. HARHAR. 
[Ratti über hartnäckige Killfile-Bewohner in suse-linux]

[Postfixadmin-devel] Fwd: Admin interface is broken and no longer useable

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

Stupid mailing list doesn't set itself as the reply-to address…

David.

Begin forwarded message:

> From: David Goodwin <da...@co...>
> Subject: Re: [Postfixadmin-devel] Admin interface is broken and no longer useable
> Date: 23 April 2012 09:40:54 GMT+01:00
> To: Johnny Solbu <jo...@so...>
> 
>> 
>> We /also/ have this message on top of all pages, which seems unrelated to teh other errors:
>> ==
>> Deprecated: Function ereg() is deprecated in /etc/postfixadmin/config.inc.php on line 19
>> ==
>> 
> 
> 
> Your problems are all stemming from the above. You get the deprecation message from PHP, which screws up your HTTP headers and session cookies.
> 
> You have two options :
> 
> 
> 1. Stop PHP outputting error messages - display_errors = Off in php.ini SHOULD do it
> 
> 2. Upgrade to a newer release - I thought we'd removed the ereg() stuff some time ago - so I'm skeptical that you're actually using the latest release.
> 
> thanks
> 
> David.
> 

[Postfixadmin-devel] (SOLVED) Admin interface is broken and no longer useable

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

On Monday 23 April 2012 08:17, Robert Schetterer wrote:
> try google about it

I was using google for 2, 3 hours before I fired away this mail. :-)=

> what php version did you upgrade to ?

We recently did an upgrade from Debian Lenny (5) to Squeeze (6).


And I just stumbled across the solution, a few minutes before you sent your reply.
it seems like the Debian systems upgrade (from lenny to squeeze) changed php.ini's "output_buffering" to "Off".
After many hours of googleing, someone in a forum suggested changing it to 4096, which solved it.

This simple change also fixed our squirrelmail troubles after the systems upgrade.


However, we still have the Deprecated error in all pages on the postfixadmin interface.
But that we can live with, for now. :-)=

-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0xFA687324
********************************
Kom Arbeidslyst og treng deg på,
her skal du motstand finne.

Re: [Postfixadmin-devel] Admin interface is broken and no longer useable

[Robert S. <ro...@sc...>]

Am 23.04.2012 06:56, schrieb Johnny Solbu:
> Function ereg() is deprecated

try google about it
what php version did you upgrade to ?

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

[Postfixadmin-devel] Admin interface is broken and no longer useable

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

Hi.

We have just upgraded to the newest version, and is now aparently unable to login.
When we login, we get this error:
==
Warning: session_regenerate_id() [function.session-regenerate-id]: Cannot regenerate session id - headers already sent in /usr/share/postfixadmin/login.php on line 77

Warning: Cannot modify header information - headers already sent by (output started at /etc/postfixadmin/config.inc.php:19) in /usr/share/postfixadmin/login.php on line 91
==

However when we go back to the login page, we are listed as logged in, and the username which we're logged in as.
But there is no way to go into the admin interface, or nowhere to click to get there. In other words, we are Not beeing redirected to the admin interface. The only way to get there is to locate and open on of the various php files manually, then all is fine, untill we actually change something.
Then we get this error:
==
Warning: Cannot modify header information - headers already sent by (output started at /etc/postfixadmin/config.inc.php:19) in /usr/share/postfixadmin/edit-mailbox.php on line 165
==

And again, there is no way to go further, other than clicking teh browsers Back button.
But, the action/changed was carried out.


We /also/ have this message on top of all pages, which seems unrelated to teh other errors:
==
Deprecated: Function ereg() is deprecated in /etc/postfixadmin/config.inc.php on line 19
==


Any idea on what is going on?

-- 
Johnny A. Solbu
web site,   http://www.solbu.net
PGP key ID: 0xFA687324
********************************
Kom Arbeidslyst og treng deg på,
her skal du motstand finne.

Re: [Postfixadmin-devel] No more pages in mailbox table

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

Hallo Leute,

Am Freitag, 13. April 2012 schrieb Johan Hendriks:
> Hello i use the latest svn release as of today  for testing.
> 
> I have 150 mailboxes, but i see only the First 10, and have no option
> to select the next page.
> 
> http://192.168.50.200/mailadmin/list-virtual.php?domain=mytest.com&tab
> =mailbox

Which database are you using? (I'd guess postgresql...)

The pagebrowser is broken in postgresql, see 
https://sourceforge.net/tracker/?func=detail&aid=3292648&group_id=191583&atid=937964 
for details.

If my guess is correct, I'd welcome some help to get 
create_page_browser() in functions.inc.php working for postgresql ;-)
I can easily integrate the needed queries into the PHP code, but I need 
someone who can provide a set of working postgresql queries.


Regards,

Christian Boltz
-- 
Die beste SuSE glaub ich Dir gern, von mir aus auch gern die beste
Linux Distro, aber die beste Susi kann ich dir nicht unterschreiben...
Da gibt es Features, die wird die SuSE AG nie in eine Linux-Distro
unterbringen ;-) [Manfred Tremmel in suse-linux]

Re: [Postfixadmin-devel] Changing some defaults in trunk/3.0?

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

Hello,

thanks for all the feedback!

I'll take this mail as base for my reply because you were the first to 
respond ;-) and commented on all options. My response is summarized for 
all mails on this topic.

The summarized votes do _not_ include my personal vote.

BTW: Did I really catch every $CONF option that might need a better 
default value? ;-)

Am Freitag, 13. April 2012 schrieb Robert Schetterer:
> Am 13.04.2012 02:04, schrieb Christian Boltz:
> >     $CONF['database_type'] = 'mysqli'; # current value: "mysql"
> > 
> > should be changed to "mysqli". The reason is simple - I don't expect
> > we have too many users using MySQL < 4.1 nowadays ;-) so using the
> > (newer) mysqli interface by default would make sense.
> 
> ACK

That makes a total of +4, which means I'll change this.

>From David's mail:
| Just silently default to mysqli perhaps - i.e. if someone chooses 
| 'mysql' they're actually using 'mysqli' ?

I don't really like this idea - maybe there's someone who intentionally 
uses the "old" mysql functions for whatever reasons.
Besides that, mysqli doesn't bring noticeable advantages for 
postfixadmin besides the "it's newer" argument because we don't use the 
additional features it provides.

We should set mysqli as default, but if someone really want to use the 
old mysql functions, then I won't stop him ;-)

| We could wrap this in a if(function_exists('mysqli_connect')) or 
| something - just incase it's possible to have a php5-mysql installed 
| without a php5-mysqli package?

openSUSE 12.1 ships mysqli in the php5-mysql package, but older releases 
(please don't ask for a version number) had separate php5-mysql and 
php5-mysqli packages IIRC. So it's probably possible to have php5-mysql 
without php5-mysqli.

BTW: we already have function_exists() checks in db_connect().

> >     $CONF['dovecotpw'] = "/usr/sbin/doveadm pw";
> >     # current value: "/usr/sbin/dovecotpw";
> > 
> > reason: dovecot 2.x comes with doveadm instead of dovecotpw
> 
> ACK

That's +1 (and 3 neutral / no comment), so I'll change it to doveadm pw 
(with a comment about dovecotpw for dovecot 1.x)

> >     $CONF['domain_path'] = 'YES'; # was NO
> >     $CONF['domain_in_mailbox'] = 'NO'; # was YES
> > 
> > in other words: domain/username/ instead of username@domain/
> > reason: maybe personal taste ;-)
> 
> there might not be a default for all people satisfy
> reading doku stays mandatory

Indeed. Nevertheless we have a total +3 so I'll change it as proposed.

> >     $CONF['quota'] = 'YES'; # was NO
> > 
> > reason: I'm using quota everywhere - even if I make the mailbox
> > *very* big, just to avoid that a forgotten mailbox can fill up the
> > harddisk.
> NOTACK, using quota isnt so wide spreaded as you think, so stay simple
> default might be better choice

I'm quite surprised by the -4 result ;-) and will of course respect it.

> >     $CONF['vacation'] = 'YES'; # was NO
> > 
> > why should we hide this feature? ;-)
> 
> NOTACK,

That sums up to -1, one neutral and one "we should use sieve", so it 
will stay NO.

> vacation is done via sieve ?

No, it's done by the vacation.pl script we ship with postfixadmin.
There's a feature request to use sieve, but nobody implemented it yet.

> >     $CONF['alias_control'] = 'YES'; # was NO
> >     $CONF['alias_control_admin'] = 'YES'; # was NO
> > 
> > I stopped counting how often users asked to implement this feature
> > ;-) so we should enable it by default
> 
> OK

Total: +3

> >     $CONF['backup'] = 'NO'; # was YES
> > 
> > The backup module is basically unmaintained...
> 
> then it should stay NO

It is currently YES ;-) which makes a total of +4 for NO.

> >     $CONF['show_status']='YES'; # was NO
> > 
> > Why should we hide such a nice feature?
> > Note that some of the related options would also need better
> > defaults, but let's first discuss if enabling show_status by
> > default makes sense.
> just forgot what show status means *g

This got +2 and 2 questionmarks ;-)

It displays color markers for several things based on the alias target. 
I'll paste from config.inc.php because the explanation there is better 
than anything I could write to sum it up ;-)
(Proposals for better default values are welcome ;-)

//set to YES to enable this feature
$CONF['show_status']='NO';
//display a guide to what these colors mean
$CONF['show_status_key']='NO';
// 'show_status_text' will be displayed with the background colors
// associated with each status, you can customize it here
$CONF['show_status_text']='&nbsp;&nbsp;';
// show_undeliverable is useful if most accounts are delivered to this
// postfix system.  If many aliases and mailboxes are forwarded
// elsewhere, you will probably want to disable this.
$CONF['show_undeliverable']='NO';
$CONF['show_undeliverable_color']='tomato';
// mails to these domains will never be flagged as undeliverable
$CONF['show_undeliverable_exceptions']=array("unixmail.domain.ext","exchangeserver.domain.ext","gmail.com");
$CONF['show_popimap']='NO';                                                                                                                                                     
$CONF['show_popimap_color']='darkgrey';
// you can assign special colors to some domains. To do this,
// - add the domain to show_custom_domains
// - add the corresponding color to show_custom_colors
$CONF['show_custom_domains']=array("subdomain.domain.ext","domain2.ext");
$CONF['show_custom_colors']=array("lightgreen","lightblue");
// If you use a recipient_delimiter in your postfix config, you can also
// honor it when aliases are checked.
// Example: $CONF['recipient_delimiter'] = "+";
// Set to "" to disable this check.
$CONF['recipient_delimiter'] = "";

I'd propose the following changes:
$CONF['show_status']='YES'; # was NO
$CONF['show_status_key']='YES'; # was NO
$CONF['show_undeliverable']='YES'; # was NO
$CONF['show_undeliverable_exceptions']=array("unixmail.domain.ext","exchangeserver.domain.ext"); 
# removed "gmail.com"
$CONF['show_popimap']='YES'; # was NO

> >     $CONF['new_quota_table'] = 'YES'; # was NO
> > 
> > new quota table format in dovecot 2.x
> 
> ACK but depend on quota enable defaults

That makes +2, which also makes it compatible with the changed 
$CONF['dovecotpw'] ;-)

If quota support is disabled, it will be ignored regardless of its 
value.

>From Johan's mail:
| Dovecot 1 is not really supported any more.
| So if this could be merged into one quota setting that would be 
| better.

That would mean dropping support for Dovecot 1.x style quota tables, 
which is completely different from changing a default value. I will not 
do this as long as it doesn't cause noticeable maintenance work (at the 
moment it "just works", so there's no reason to drop it).

> is there a changelog preview by new feature sets ?

CHANGELOG.TXT in svn trunk already lists some changes (until 2011-08), 
and the second half is 
    svn log -r 1166:1367
The "svn log" part might sound funny, but it somehow scares me because 
I'll have to read and summarize it. Paperwork... (if someone volunteers 
to do it, I'll be more than happy ;-)


Regards,

Christian Boltz
-- 
Wenn du willst kannst du das so machen,  du kannst dir dann aber auch
genausogut mit ner Hilti ein schickes Schaedel-Piercing machen... Das
tut uebrigens auch nur ganz kurz weh...  [David Haller in suse-linux]

[Postfixadmin-devel] No more pages in mailbox table

[Johan H. <Jo...@do...>]

Hello i use the latest svn release as of today  for testing.

I have 150 mailboxes, but i see only the First 10, and have no option to select the next page.

http://192.168.50.200/mailadmin/list-virtual.php?domain=mytest.com&tab=mailbox

regards
Johan

Re: [Postfixadmin-devel] Changing some defaults in trunk/3.0?

[Johan H. <Jo...@do...>]

Christian Boltz said the following on 13/04/12 02:04:

> $CONF['database_type'] = 'mysqli'; # current value: "mysql" should be 
> changed to "mysqli".

+1 for me also

> $CONF['domain_path'] = 'YES'; # was NO $CONF['domain_in_mailbox'] = 
> 'NO'; # was YES in other words: domain/username/ instead of 
> username@domain/

+1 for me also

> $CONF['quota'] = 'YES'; # was NO

I Use quota, but it is up to the end user if he uses it, so i say leave it to NO.

> $CONF['vacation'] = 'YES'; # was NO why should we hide this feature? 
> ;-)

I use Sieve, but just like quota leave it to the end user.
It is better to Enable things than disable.

> $CONF['alias_control'] = 'YES'; # was NO $CONF['alias_control_admin'] 
> = 'YES'; # was NO I stopped counting how often users asked to 
> implement this feature ;-)

+1 for me also

> $CONF['backup'] = 'NO'; # was YES

+1, like the quota and so on.
If you use it enable it.

> $CONF['show_status']='YES'; # was NO Why should we hide such a nice 
> feature?

+1 it is nice, but i could not care less if it was not enabled by default.

> $CONF['new_quota_table'] = 'YES'; # was NO new quota table format in 
> dovecot 2.x

Dovecot 1 is not really supported any more.
So if this could be merged into one quota setting that would be better.

Gr
Johan Hendriks

Re: [Postfixadmin-devel] Changing some defaults in trunk/3.0?

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

>    $CONF['database_type'] = 'mysqli'; # current value: "mysql"
> should be changed to "mysqli". The reason is simple - I don't expect we 
> have too many users using MySQL < 4.1 nowadays ;-) so using the (newer) 
> mysqli interface by default would make sense.
> 

Just silently default to mysqli perhaps - i.e. if someone chooses 'mysql' they're actually using 'mysqli' ?

We could wrap this in a if(function_exists('mysqli_connect')) or something - just incase it's possible to have a php5-mysql installed without a php5-mysqli package?

So really the user is choosing whether to use MySQL or other.database - not between two flavours of MySQL.


>    $CONF['domain_path'] = 'YES'; # was NO
>    $CONF['domain_in_mailbox'] = 'NO'; # was YES
> in other words: domain/username/ instead of username@domain/
> reason: maybe personal taste ;-)
> 

Yes.

>    $CONF['quota'] = 'YES'; # was NO
> reason: I'm using quota everywhere - even if I make the mailbox *very* 
> big, just to avoid that a forgotten mailbox can fill up the hard disk.

I'd always change this back to 'No'. But that's just me.


>    $CONF['vacation'] = 'YES'; # was NO
> why should we hide this feature? ;-)
> 

I think we should look at using sieve. 
> 
>    $CONF['backup'] = 'NO'; # was YES
> The backup module is basically unmaintained…
> 

+1 - doesn't work for PostgreSQL anyway.


>    $CONF['show_status']='YES'; # was NO

What's this do? Just show whether the database thinks a mailbox/alias is in use? If so, yes.


David.

Re: [Postfixadmin-devel] Changing some defaults in trunk/3.0?

[Luigi R. <li...@lu...>]

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

Christian Boltz said the following on 13/04/12 02:04:

> $CONF['database_type'] = 'mysqli'; # current value: "mysql" should be
> changed to "mysqli".

+1

> $CONF['domain_path'] = 'YES'; # was NO $CONF['domain_in_mailbox'] = 'NO'; #
> was YES in other words: domain/username/ instead of username@domain/

+1

> $CONF['quota'] = 'YES'; # was NO

I don't use quota. Personal taste and no need to use it.

> $CONF['vacation'] = 'YES'; # was NO why should we hide this feature? ;-)

I use YES; problem is that you have to do some "external work" beside enabling
it. Consider this if you want to make it default.


> $CONF['alias_control'] = 'YES'; # was NO $CONF['alias_control_admin'] =
> 'YES'; # was NO I stopped counting how often users asked to implement this
> feature ;-)

+1 expecially for the reason you gave ;)

> $CONF['backup'] = 'NO'; # was YES

+1

> $CONF['show_status']='YES'; # was NO Why should we hide such a nice
> feature?

+1

> $CONF['new_quota_table'] = 'YES'; # was NO new quota table format in
> dovecot 2.x

See my comment about quota above.




Ciao,
luigi

- -- 
/
+--[Luigi Rosa]--
\

Experts warn that the Internet is running out of bandw
    --fark.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+ILqAACgkQ3kWu7Tfl6ZTv8wCfQAthwpUWXZW2YiisLGYG+VE/
4u8AoKEWqfG0D/woPKp8Y4W6B1cmUykJ
=u0CT
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Changing some defaults in trunk/3.0?

[Robert S. <ro...@sc...>]

Am 13.04.2012 02:04, schrieb Christian Boltz:
> Hello,
> 
> 3.0 will be a major release, which means I won't be too strict about 
> keeping the default config 100% backwards compatible (= unchanged).
> We probably have some config options with defaults that are there for 
> historic reasons, but are not the best idea nowadays. 
> 
> Are you aware of any setting in config.inc.php that is
> - outdated (as in "everybody has to change this nowadays")  or
> - "not a good idea"[tm]  or
> - could have better default values
> ?
> 
> If yes, please speak up now and tell me
> - which $CONF option?
> - why would you change its default value?
> - and to which value? (you can obviously ignore this part for YES/NO 
>   options ;-)
>  
> 
> Let me start with some things I noticed while scrolling over 
> config.inc.php:
> 
>     $CONF['database_type'] = 'mysqli'; # current value: "mysql"
> should be changed to "mysqli". The reason is simple - I don't expect we 
> have too many users using MySQL < 4.1 nowadays ;-) so using the (newer) 
> mysqli interface by default would make sense.

ACK

> 
>     $CONF['dovecotpw'] = "/usr/sbin/doveadm pw"; 
>     # current value: "/usr/sbin/dovecotpw";
> reason: dovecot 2.x comes with doveadm instead of dovecotpw

ACK

> 
>     $CONF['domain_path'] = 'YES'; # was NO
>     $CONF['domain_in_mailbox'] = 'NO'; # was YES
> in other words: domain/username/ instead of username@domain/
> reason: maybe personal taste ;-)

there might not be a default for all people satisfy
reading doku stays mandatory

> 
>     $CONF['quota'] = 'YES'; # was NO
> reason: I'm using quota everywhere - even if I make the mailbox *very* 
> big, just to avoid that a forgotten mailbox can fill up the harddisk.

NOTACK, using quota isnt so wide spreaded as you think, so stay simple
default might be better choice

> 
>     $CONF['vacation'] = 'YES'; # was NO
> why should we hide this feature? ;-)

NOTACK,
vacation is done via sieve ?

> 
>     $CONF['alias_control'] = 'YES'; # was NO
>     $CONF['alias_control_admin'] = 'YES'; # was NO
> I stopped counting how often users asked to implement this feature ;-) 
> so we should enable it by default

OK

> 
>     $CONF['backup'] = 'NO'; # was YES
> The backup module is basically unmaintained...

then it should stay NO

> 
>     $CONF['show_status']='YES'; # was NO
> Why should we hide such a nice feature?
> Note that some of the related options would also need better defaults, 
> but let's first discuss if enabling show_status by default makes sense.

just forgot what show status means *g

> 
>     $CONF['new_quota_table'] = 'YES'; # was NO
> new quota table format in dovecot 2.x
> 

ACK but depend on quota enable defaults

> 
> Needless to say that this *must* be documented in a very visible way to 
> avoid "surprising" users on upgrades ;-)
> 
> 
> Regards,
> 
> Christian Boltz

just my thoughts , as you asked, anyway thx for coding !

is there a changelog preview by new feature sets ?

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

[Postfixadmin-devel] Changing some defaults in trunk/3.0?

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

Hello,

3.0 will be a major release, which means I won't be too strict about 
keeping the default config 100% backwards compatible (= unchanged).
We probably have some config options with defaults that are there for 
historic reasons, but are not the best idea nowadays. 

Are you aware of any setting in config.inc.php that is
- outdated (as in "everybody has to change this nowadays")  or
- "not a good idea"[tm]  or
- could have better default values
?

If yes, please speak up now and tell me
- which $CONF option?
- why would you change its default value?
- and to which value? (you can obviously ignore this part for YES/NO 
  options ;-)
 

Let me start with some things I noticed while scrolling over 
config.inc.php:

    $CONF['database_type'] = 'mysqli'; # current value: "mysql"
should be changed to "mysqli". The reason is simple - I don't expect we 
have too many users using MySQL < 4.1 nowadays ;-) so using the (newer) 
mysqli interface by default would make sense.

    $CONF['dovecotpw'] = "/usr/sbin/doveadm pw"; 
    # current value: "/usr/sbin/dovecotpw";
reason: dovecot 2.x comes with doveadm instead of dovecotpw

    $CONF['domain_path'] = 'YES'; # was NO
    $CONF['domain_in_mailbox'] = 'NO'; # was YES
in other words: domain/username/ instead of username@domain/
reason: maybe personal taste ;-)

    $CONF['quota'] = 'YES'; # was NO
reason: I'm using quota everywhere - even if I make the mailbox *very* 
big, just to avoid that a forgotten mailbox can fill up the harddisk.

    $CONF['vacation'] = 'YES'; # was NO
why should we hide this feature? ;-)

    $CONF['alias_control'] = 'YES'; # was NO
    $CONF['alias_control_admin'] = 'YES'; # was NO
I stopped counting how often users asked to implement this feature ;-) 
so we should enable it by default

    $CONF['backup'] = 'NO'; # was YES
The backup module is basically unmaintained...

    $CONF['show_status']='YES'; # was NO
Why should we hide such a nice feature?
Note that some of the related options would also need better defaults, 
but let's first discuss if enabling show_status by default makes sense.

    $CONF['new_quota_table'] = 'YES'; # was NO
new quota table format in dovecot 2.x


Needless to say that this *must* be documented in a very visible way to 
avoid "surprising" users on upgrades ;-)


Regards,

Christian Boltz
-- 
>> Does this suggest to remove this feature completely?
> If you want a browser that doesn't malfunction and crash, yes.
Better: the whole networking code should be removed, so we wont get
any cookies over the network [>> Markus Fischer, > Boris Zbarsky
and Zs. G. in https://bugzilla.mozilla.org/show_bug.cgi?id=430006]

Re: [Postfixadmin-devel] What is the difference between mysql and mysqli in the DB type config option?

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

Hello,

Am Dienstag, 10. April 2012 schrieb Tanstaafl:
> Subject is the question...
> 
> When/why should is use one or the other?

Well, the difference is that with "mysql" the mysql_* PHP functions will 
be used, and with "mysqli" the mysqli_* functions ;-)

The PHP documentation contains lots of details what the difference 
between those functions is, but it comes down to this summary (from 
php.net/manual/de/mysqli.overview.php )

    If you are using MySQL versions 4.1.3 or later it is strongly 
    recommended that you use the mysqli extension

For postfixadmin, the difference isn't too big because we only use some 
basic functions, so you probably won't notice a difference between 
"mysql" and "mysqli". Nevertheless I'd recommend "mysqli" unless you 
have a very old MySQL version.


Regards,

Christian Boltz
-- 
> kennt jemand einen schönen WYSIWYG Editor für SuSE 9.0??
Klar, NEdit natürlich. Damit bekomme ich immer genau die Quelltexte,
die ich vorher sehe. [> Stefan Eggert und Thorsten Haude in suse-linux]

Re: [Postfixadmin-devel] Just curious - how close is 3.0 to being released?

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

On 2012-04-12 8:47 AM, Christian Boltz <pos...@cb...> wrote:
> your $subject is a good question;-)
>
> Let me first answer with a question: Did you test current SVN trunk?

I wish I had the time to do so, but alas, I'm a one man I.T. shop for 
60+ users, so time is something I don't have a lot of...

I may be able to squeeze out a few hours to play with an official 
'preview' release if you decide to do one though...

Will there be a documented 'upgrade' path, so I can dump my current DB 
and restore it to the new/test system?

Re: [Postfixadmin-devel] Just curious - how close is 3.0 to being released?

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

> 
> 
> David, what do you think about doing a "3.0 preview" release?

Gets my vote.


David.

Re: [Postfixadmin-devel] Just curious - how close is 3.0 to being released?

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

Hello,

your $subject is a good question ;-)

Let me first answer with a question: Did you test current SVN trunk? 
What is your impression?

Now to the real answer:

SVN trunk is in a good quite state right now, and a sleepless easter 
night contributed much to that ;-)

There are too many things left to call it 3.0 (for example, the CLI is 
only partially implemented and the migration to the *Handler classes is 
not finished) - OTOH, it contains lots of improvements, some new 
features and probably less bugs than 2.3.5 because the migration to the 
*Handler classes solved several issues automatically).

Known regressions:
- $PALANG is escaped which breaks if a *.lang file contains 
  htmlentities. Should be easy to fix.
- some missing validation in AliasHandler (also easy to fix)

I think we could/should do a "preview" release which is clearly marked 
as "probably unstable" and "class interfaces etc. might change" [1].
This would give interested users the chance to use the new features, and 
in return we'll get (hopefully not too many) bugreports.

BTW: I'd use a version number like 2.9.0 instead of "3.0 preview" to 
avoid confusion in the rpm/deb "what's newer" comparison later when we 
release 3.0 final.


David, what do you think about doing a "3.0 preview" release?


Regards,

Christian Boltz

[1] In general, the *Handler class interface looks good and I don't 
    really expect that I need to do noticeable changes to it, but often 
    the devil is in the detail - see my commits from the last days.
-- 
[ACPI] Du kannst da Deinen Power-Knopf konfigurieren wie Du willst.
Du kannst den auch so konfigurieren, daß der PC anfängt zu singen ...
[Ekkard Gerlach in suse-linux]

[Postfixadmin-devel] What is the difference between mysql and mysqli in the DB type config option?

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

Subject is the question...

When/why should is use one or the other?