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

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

[Warren V. <wa...@wa...>]

Sorry for the delayed response.

On Sep 27, 2009, at 4:25 PM, Christian Boltz wrote:

> Hello,
>
> Am Samstag, 26. September 2009 schrieb Warren Volz:
>> I just posted a patch against 2.3rc7 that adds support for viewing
>> dovecot v1.2 quotas and fixes a bug that prevents this from working
>> unless 'vacation_control_admin' is set.
>
> Oh yes, another case where we have too many if statements with  
> different
> bugs :-/ and will even have more after applying your patch.
>
> I just wonder if we really need separate queries for
> vacation_control_admin on/off or if we could just skip displaying the
> vacation status (which the template already does anyway).
> I think we should merge the queries and just skip displaying to have
> easier readable code. (I did not do this now to avoid breaking your
> patch.)

Yeah the if statements can get out of control really quick. I think  
your suggestion for not displaying the vacation status would be fine  
by me, but I wonder if there are users that want this. I don't see  
anything about it in the feature request list, but I might be missing  
something.

> Dovecot quota in general seems to be a can of worms ;-) and the table
> format change in dovecot 1.2 doesn't make things easier.

Yeah, it makes things a little more complicated for sure. I think the  
format change for v1.2 does make more sense though.

> An idea how to fix the issue you described in your patch:
>
>    // WARNING: This query will fail if a user does not have a
>    // 'quota/storage' row in the quota table. Not sure how to handle
>    // this now.
>    [...] WHERE [...] AND $table_quota.path='quota/storage'
>
> If there's a list of fixed values dovecot uses, what about using
>    [...] WHERE [...] AND $table_quota.path !='quota/OTHERVALUE'
> (If dovecot has a big list of values it can store in the quota.path
> field, this solution won't work.)
> -> What other values are possible in the quota.path field?

The only other value (that I've seen) is 'quota/messages'. However, I  
don't think revising the query helps because if an admin using PFA  
decides not to send a "welcome" email to a new account, the user will  
have no entries in the quota table at all until a delivery occurs (see http://sourceforge.net/tracker/index.php?func=detail&aid=2794247&group_id=191583&atid=937964 
). The v1.2 quota table doesn't have this problem with the query  
because there is no need to have the quota table in the WHERE part of  
the query.

> Another issue is how to handle the different table formats in dovecot
> 1.1 and 1.2. IMHO we need two(!) quota tables:
> - one in dovecot 1.1 format, named "quota" to stay compatible with the
>  current instructions/documentation (note: the quota table is not
>  auto-created yet)
> - another one (maybe "quota2" or "quota12") in dovecot 1.2 format

Hmm, if you ask me this is isn't the best solution because it breaks  
from what the dovecot wiki suggests thus making things more confusing  
for users. Also, it seems like setup could check the version of  
dovecot (dovecot --version) during install/upgrade and set the correct  
configuration variable for the user. Of course I guess maybe the issue  
then is how to migrate the quota table for the user? Really deleting  
and re-creating the quota table isn't a huge deal except that dovecot  
will be forced to re-compute the quota for each user as they get new  
mail. This would happen anyways when migrating to the new version of  
Dovecot though.

> setup.php should create both tables. (I'll add the code to setup.php
> when the above issues are decided.)
>
> Regarding PostgreSQL: If I get http://wiki.dovecot.org/Quota/Dict  
> right,
> dovecot needs a trigger for updating the quota.
> David, can we let setup.php create this trigger without (permission)
> problems?

Yeah, Postgres doesn't support ON DUPLICATE KEY UPDATE (which has  
never really been an issue) thus the need for the trigger. I'm the one  
that added the v1.1 trigger to the dovecot wiki. Of course, if you add  
support for v1.2 there will need to be two triggers in the setup file  
which goes back to the need to check the version of  dovecot...

-Warren

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

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

Hello,

Am Freitag, 2. Oktober 2009 schrieb Robert Schetterer:
> i have postfixadmin stable up and running with dovecot 1.2
> i dont see the point why there are patches needed in relation to
>  quota

I guess you are talking about quota as in "limit mailbox size". Yes, 
this is working without problems.

The feature we are discussing here is "displaying the used quota in 
postfixadmin". Dovecot can maintain the current quota usage in 
MySQL/postgres - but as you can read in this thread, the table format 
for it has changed with dovecot 1.2.


Regards,

Christian Boltz
-- 
Eine kurze richtige Antwort (mancher mag sie als unfreundlich
bezeichnen) ist besser als eine lange, freundliche, falsche.
[Dirk H. Hohndel, SuSE]

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

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

Christian Boltz schrieb:
> Hallo Leute,
> 
> Am Montag, 28. September 2009 schrieb Tanstaafl:
>> On 9/27/2009, Christian Boltz (pos...@cb...) wrote:
>>> Another issue is how to handle the different table formats in
>>> dovecot 1.1 and 1.2. IMHO we need two(!) quota tables:
>> Personally, I'd just recommend supporting 1.2, and tell people if
>>  they want DC quota support, they have to upgrade dovecot.
> 
> That's not an option IMHO - dovecot 1.2 is too new (released 2009-07-01) 
> to force users to upgrade. The upcoming openSUSE 11.2 will come with 
> 1.1.7 [1], and the usual rumors say it will take years to get 1.2 in 
> debian stable ;-)
> 
> Another important point is that postfixadmin aims to always be backward-
> compatible. Removing support for dovecot 1.1 would break postfixadmin 
> for several users [1]...
> 
> 
> Regards,
> 
> Christian Boltz
> 
> [1] I don't have any numbers about how many users use this features -
>     but given that 2.3rc7 has 6500 downloads, I'm sure that there are
>     people who use the quota feature...

i have postfixadmin stable up and running with dovecot 1.2
i dont see the point why there are patches needed in relation to quota

-- 
Best Regards

MfG Robert Schetterer

Germany/Munich/Bavaria

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

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

Hallo Leute,

Am Montag, 28. September 2009 schrieb Tanstaafl:
> On 9/27/2009, Christian Boltz (pos...@cb...) wrote:
> > Another issue is how to handle the different table formats in
> > dovecot 1.1 and 1.2. IMHO we need two(!) quota tables:
> 
> Personally, I'd just recommend supporting 1.2, and tell people if
>  they want DC quota support, they have to upgrade dovecot.

That's not an option IMHO - dovecot 1.2 is too new (released 2009-07-01) 
to force users to upgrade. The upcoming openSUSE 11.2 will come with 
1.1.7 [1], and the usual rumors say it will take years to get 1.2 in 
debian stable ;-)

Another important point is that postfixadmin aims to always be backward-
compatible. Removing support for dovecot 1.1 would break postfixadmin 
for several users [1]...


Regards,

Christian Boltz

[1] I don't have any numbers about how many users use this features -
    but given that 2.3rc7 has 6500 downloads, I'm sure that there are
    people who use the quota feature...
-- 
Es gibt Leute, bei denen man im Killfile sein sollte, oder
man hat etwas flashc gemacht.    [Henning Sponbiel in doc]

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

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

On 9/27/2009, Christian Boltz (pos...@cb...) wrote:
> Another issue is how to handle the different table formats in dovecot 
> 1.1 and 1.2. IMHO we need two(!) quota tables:

Personally, I'd just recommend supporting 1.2, and tell people if they
want DC quota support, they have to upgrade dovecot.

-- 

Best regards,

Charles

Re: [Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

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

Hello,

Am Samstag, 26. September 2009 schrieb Warren Volz:
> I just posted a patch against 2.3rc7 that adds support for viewing  
> dovecot v1.2 quotas and fixes a bug that prevents this from working  
> unless 'vacation_control_admin' is set.

Oh yes, another case where we have too many if statements with different 
bugs :-/ and will even have more after applying your patch.

I just wonder if we really need separate queries for 
vacation_control_admin on/off or if we could just skip displaying the 
vacation status (which the template already does anyway).
I think we should merge the queries and just skip displaying to have 
easier readable code. (I did not do this now to avoid breaking your 
patch.)

Dovecot quota in general seems to be a can of worms ;-) and the table 
format change in dovecot 1.2 doesn't make things easier.

An idea how to fix the issue you described in your patch:

    // WARNING: This query will fail if a user does not have a 
    // 'quota/storage' row in the quota table. Not sure how to handle 
    // this now. 
    [...] WHERE [...] AND $table_quota.path='quota/storage'

If there's a list of fixed values dovecot uses, what about using
    [...] WHERE [...] AND $table_quota.path !='quota/OTHERVALUE'
(If dovecot has a big list of values it can store in the quota.path 
field, this solution won't work.)
-> What other values are possible in the quota.path field?

Another issue is how to handle the different table formats in dovecot 
1.1 and 1.2. IMHO we need two(!) quota tables:
- one in dovecot 1.1 format, named "quota" to stay compatible with the 
  current instructions/documentation (note: the quota table is not 
  auto-created yet)
- another one (maybe "quota2" or "quota12") in dovecot 1.2 format

setup.php should create both tables. (I'll add the code to setup.php 
when the above issues are decided.)

Regarding PostgreSQL: If I get http://wiki.dovecot.org/Quota/Dict right, 
dovecot needs a trigger for updating the quota.
David, can we let setup.php create this trigger without (permission) 
problems?


Regards,

Christian Boltz
-- 
"Wirklich praxisnah wären Münzen zu EUR 0,99."
[Wolfgang Schwanke in de.etc.sprache.deutsch]

Re: [Postfixadmin-devel] Patch to make domain quota split between all users

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

Hello,

Am Samstag, 26. September 2009 schrieb Warren Volz:
> I added a patch to change the behavior of quotas so that the amount  
> specified for the domain quota is split between all users. This is  
> against 2.3rc7.

Thanks for your patch!
I like your idea of having a per-domain total quota which can be used 
for one big or 100 small mailboxes. However, I'd like to ask to to do 
some changes to your changes ;-)

If I get your patch right (I just had a quick look at it), you are 
_replacing_ the current quota implementation with a per-domain total 
quota. I'd like to have both - a per-domain quota as in your patch and a 
quota limit for each mailbox (as in the current implementation) for some 
reasons:
- admins might still want to have a maximum per-mailbox size
- replacing the meaning of the maxquota field from "max quota per 
  mailbox" to "quota per domain" would cause big problems on upgrade
- we would also break backwards compatibility (by replacing the meaning 
  of maxquota) without a real need
- with a separate field, upgrading would be easy. The per-domain quota 
  could be calculated on upgrade:
      allowed mailboxes * quota per mailbox = quota for the domain

There's an unused column "quota" in the domain table - you can use it 
for the per-domain quota.

Another small issue with your patch: I'd prefer to read the domain from 
the username instead of adding another parameter to check_quota().

If you have questions about my reasoning or need help on implementing my 
wishes, feel free to speak up ;-)


Regards,

Christian Boltz
-- 
Jedes meiner Postings ist alt genug, um für sich selbst zu sprechen.
Ich übernehme keinerlei Verantwortung für das Verhalten meiner Mails.

[Postfixadmin-devel] Patch to make domain quota split between all users

[Warren V. <wa...@wa...>]

I added a patch to change the behavior of quotas so that the amount  
specified for the domain quota is split between all users. This is  
against 2.3rc7.

http://sourceforge.net/tracker/?func=detail&aid=2856577&group_id=191583&atid=937966

Patch attached for convenience.

-Warren

[Postfixadmin-devel] Patch posted for dovecot v1.2 quota viewing

[Warren V. <wa...@wa...>]

I just posted a patch against 2.3rc7 that adds support for viewing  
dovecot v1.2 quotas and fixes a bug that prevents this from working  
unless 'vacation_control_admin' is set.

https://sourceforge.net/tracker/?func=detail&aid=2867629&group_id=191583&atid=937966

Patch attached here as well for your convenience.

-Warren

Re: [Postfixadmin-devel] quota support

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

On Mon, 14 Sep 2009, Papp Tamás wrote:

> me...@td... wrote, On 2009. 09. 10. 23:02:
>> On Mon, 7 Sep 2009, Papp Tamás wrote:
>> 
>>> My system is Ubuntu 9.04 (actually it's upgraded to Karmic, but I
>>> hope, it's really doesn't matter), with postfixadmin2.3-rc7 and
>>> dovecot install.
>> 
>> What version of dovecot are you using? For 1.2+ the quota support in
>> pfa is broken because Timo changed the way quotas work in 1.2+.
>> You need a one or two line patch to pfa and different table structure.
>> 
>
> I'm sorry for the late answer, I'm trying, what the best solution would be 
> for me.
> I'm using Karmic Koala right now, it has 1.1.11-0ubuntu8, so not 1.2+.
>
> BTW, could you send me that patch?

Patch in line at the bottom of this message.

>> If you need more info about this let me know.
>
> And if 1.2.4 is successful, I would change everywhere to it from here:
>
> http://xi.rename-it.nl/debian/pool/dovecot-1.2/
>
> You don't use debian, am I right?

No, I do not. Red Hat/Centos.

> ps.: BTW pfa is a really useful and helpful stuff!

I agree 1000%!!

Hope this helps.

Regards,

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

The patch below is against svn 718.

(vfoggy pts4) # diff -u list-virtual.php.orig list-virtual.php
--- list-virtual.php.orig       2009-09-14 08:29:14.000000000 -0400
+++ list-virtual.php    2009-09-14 08:32:21.000000000 -0400
@@ -161,7 +161,9 @@
  if ($CONF['vacation_control_admin'] == 'YES')
  {
      if (boolconf('used_quotas'))
-        $query = "SELECT $table_mailbox.*, $table_vacation.active AS v_active, $table_quota.current FROM $table_mailbox
+               // Modified the next line to work with Dovecot 1.2+ Quotas as per an email from Christian Boltz dated 29 Apr 09.
+        // $query = "SELECT $table_mailbox.*, $table_vacation.active AS v_active, $table_quota.current FROM $table_mailbox
+        $query = "SELECT $table_mailbox.*, $table_vacation.active AS v_active, $table_quota.bytes as current FROM $table_mailbox
              LEFT JOIN $table_vacation ON $table_mailbox.username=$table_vacation.email
              LEFT JOIN $table_quota ON $table_mailbox.username=$table_quota.username
              WHERE $table_mailbox.domain='$fDomain'
(vfoggy pts4) #

[Postfixadmin-devel] Unable to display mailboxes.

[Warren V. <wa...@wa...>]

I believe this may be the bug I filed a while ago, see bug# 2794247.  
My solution was to disable "vacation_control_admin".

-Warren

Re: [Postfixadmin-devel] quota support

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

On Mon, 7 Sep 2009, Papp Tamás wrote:

> hi All,
>
> I have a problem. I'm not sure, it's a bug or I do something wrong,
> so, I rather send this report here, not to the bugtracker at SF.
>
> Is it OK?
>
>
> My system is Ubuntu 9.04 (actually it's upgraded to Karmic, but I
> hope, it's really doesn't matter), with postfixadmin2.3-rc7 and
> dovecot install.

What version of dovecot are you using? For 1.2+ the quota support in
pfa is broken because Timo changed the way quotas work in 1.2+.
You need a one or two line patch to pfa and different table structure.

>
> There is a table quota:
>
> mysql> select * from quota;
> +----------------------+----------------+---------+
> | username             | path           | current |
> +----------------------+----------------+---------+
> | t1...@ok... | quota/storage  |   88124 |
> | t1...@ok... | quota/messages |     107 |
> +----------------------+----------------+---------+

My table for dovecot 1.2+ looks like the following:

mysql> select * from quota;
+-----------------------------------+------------+----------+
| username                          | bytes      | messages |
+-----------------------------------+------------+----------+
| te...@ex...                  |      15344 |       19 |
+-----------------------------------+------------+----------+

I do not understand the problems you state below but I just wanted to
throw this out in case you are using dovecot 1.2+.

If you need more info about this let me know.

Regards,

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

[Postfixadmin-devel] quota support

[Papp T. <to...@ma...>]

hi All,

I have a problem. I'm not sure, it's a bug or I do something wrong,
so, I rather send this report here, not to the bugtracker at SF.

Is it OK?


My system is Ubuntu 9.04 (actually it's upgraded to Karmic, but I
hope, it's really doesn't matter), with postfixadmin2.3-rc7 and
dovecot install.

There is a table quota:

mysql> select * from quota;
+----------------------+----------------+---------+
| username             | path           | current |
+----------------------+----------------+---------+
| t1...@ok... | quota/storage  |   88124 |
| t1...@ok... | quota/messages |     107 |
+----------------------+----------------+---------+

The problems:

1.
If I enable quota: $CONF['quota'] = 'YES';
In the mailbox list there is a new column named 'Quota (MB)', but its
value is 'Unlimited'
My guess is there should be the used quotas, but only if I enable
'used_quotas'.

2.
If I enable it: $CONF['used_quotas'] = 'YES';
In the mailbox list there is 1 new row for the existing user with the
same data.
The column 'Quota (MB)' there is still 'Unlimited'.


Additional info: if 'quota' is disabled˛ and but 'used_quotas' is enabled, I
see still two rows for one user without 'Quota (MB)'˙

I think, this is not OK.
Do I miss something?

Also I have a question, as why is it create two rows for one use? Why
does not use 1 row with more columns (I'm afraid it's dovecot
specific).


Thank you,

tamas

Re: [Postfixadmin-devel] Problem creating folders.

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

On Thu, 20 Aug 2009, Christian Boltz wrote:

> Hello,
>
> Am Donnerstag, 20. August 2009 schrieb me...@td...:
>> when I enable $CONF['create_mailbox_subdirs']=array('Spam'); and
>> $CONF['create_mailbox_subdirs_host']='localhost'; and add an account
>> the Spam folder is not created and I get the following in the
>> http_error log:
>>
>> [Wed Aug 19 15:32:44 2009] [error] [client 192.168.0.3] Could not log
>> into IMAP/POP server: Certificate failure for localhost: self signed
>> certificate: /OU=IMAP
>> server/CN=imap.example.com/emailAddress=pos...@ex...,
>
> Your problem is that you use a self-signed certificate.

Indeed.

>
> According to http://www.php.net/manual/en/function.imap-open.php you
> should be able to disable this check by using the /novalidate-cert flag.
>
>> I do not see anything in the config file that would allow me to turn
>> of the ssl stuff.
>
> This was my first thought also - but it looks like postfixadmin still
> includes some surprises even for me ;-)

:-)

>
> We indeed have a config setting for this. Try
>   $CONF['create_mailbox_subdirs_hostoptions']=array('novalidate-cert');

Aah!! I missed that after all!! That fixed it. You are correct. The solution
was buried in the comments.

Sorry for the noise.

Regards,

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

Re: [Postfixadmin-devel] Boolean values

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

Hallo Leute,

Am Freitag, 21. August 2009 schrieb David Goodwin:
> > Probably your change in db_get_boolean to return t/f instead of
> > true/false for postgresql (don't say I didn't warn you ;-)
>
> *wonders why he did this*

OK, you wanted it so ;-)

2009-08-04 log from #postfixadmin:

[22:16] <cboltz> GingerDog, I think you are the perfect tester for the bug that was reported about list-domain always showing "not active" ;-)
[22:16] <cboltz> I think this might be a PgSQL issue...
[22:19] <GingerDog> steps to recreate are...
[22:19] <GingerDog> oh, yes...
[22:19] <GingerDog> reproducable
[22:19] <GingerDog> +e
[22:19] <GingerDog> i never use list-domain
[22:19] <cboltz> try the changes I proposed in the bugreport...
[22:20] * GingerDog goes to rummage
[22:23] <cboltz> https://sourceforge.net/tracker/?func=detail&aid=2830001&group_id=191583&atid=937964
[22:23] <cboltz> to save you some searching ;-)
[22:36] <GingerDog> oddly my postgres returns 't' or 'f' for db_get_boolean(true/false)
[22:36] <GingerDog> sorry that's all wrong
[22:36] <GingerDog> the resultset contains 't' or 'f'
[22:37] <GingerDog> db_get_boolean() returns 'true' or 'false'
[22:37] <GingerDog> so even if they should match, they won't as 't' != 'true'
[22:37] * GingerDog wonders if this is a new postgres feature or something else
[22:37] <cboltz> fix db_get_boolean ;-)
[22:38] <cboltz> AFAIK we mostly used db_get_boolean in INSERT and UPDATE statements, so true/false probably "accidently" work
[22:39] <cboltz> however, you might want to just check for "t" / "f" in the list-domain template to avoid breaking something in the 2.3 release ;-)
[22:40] <GingerDog> hah
[22:40] <GingerDog> edit-domain is quite happy with the new style boolean(s) for postgres
[22:41] <GingerDog> date stamps are fubared though
[22:41] * cboltz thinks about switching to something like tinyint so that PgSQL just returns 0 or 1
[22:42] <GingerDog> are your dates in e.g. alias stored like : 2009-08-04 21:45:45.799683+01 ?
[22:43] <GingerDog> too late now ;0)
[22:44] <cboltz> you mean the "last changed" column?
[22:44] <cboltz> I see something like "2007-05-28 21:43:20"
[22:44] <GingerDog> yes, for example
[22:44] <GingerDog> ah
[22:44] <GingerDog> php is getting confused when redisplaying the dates given to it by postgres
[22:46] <GingerDog> again, sometimes you wish date/time was just stored as a value in seconds ;)
[22:46] <cboltz> or pgsql is just tooo exact in the timestamp it returns
[22:46] <cboltz> if you cut off everything after the seconds, you have the format I see with mysql
[22:48] <GingerDog> but putting a lot of strpos() in where dates are shown would be a bit ugly.
[22:48] <cboltz> I'd use strtotime() and then format it again...
[22:55] <GingerDog> hmm
[22:56] <GingerDog> so you don't see anything under mysql to indicate the timezone for a date?
[22:57] <cboltz> at least not in postfixadmin
[22:57] <cboltz> (no idea how it is stored in the database)
[22:59] <GingerDog> that's where the problem is for me atm
[23:00] <GingerDog> yes, it looks like it's the same in the DB


Regards,

Christian Boltz
-- 
> Adding a self-removing SuSEconfig script calling rpm -e --noscripts
> would be an ugly but working work-around. [...]
Wow. Stanislav, after all these years you still manage to scare me :)
[> Stanislav Brabec and Stephan Kulow in
 https://bugzilla.novell.com/show_bug.cgi?id=310640]

Re: [Postfixadmin-devel] Boolean values

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

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


> 
> Probably your change in db_get_boolean to return t/f instead of 
> true/false for postgresql (don't say I didn't warn you ;-)

*wonders why he did this*

> 
> I fixed some more queries (after grepping trough the code) - please test 
> if the files I modified are working with postgresql. (I also still have 
> to test them with MySQL ;-)
> 
>> There is a problem with PHP/PostgreSQL date handling at the moment
>> too - I've not sat down to fix this yet, but you will find problems
>> with the last modified columns etc.
> 
> Do you mean the string formatting problem you mentioned in IRC? Or 
> something else?
> 

Yes

David.
- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqOoHYACgkQ/ISo3RF5V6YdvwCfZct4aepJVPe1UORGCGvxEu9u
RjIAoLOr5p2xsiBofi0fzATq1XVYNS2o
=xL2y
-----END PGP SIGNATURE-----

Re: [Postfixadmin-devel] Boolean values

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

Hello,

Am Freitag, 21. August 2009 schrieb David Goodwin:
> Geoff Shang wrote:
> > I apologise for joining the list and posting immediately on a
> > subject that may well have had some considerable discussion
> > already.

We are always happy about users asking questiosns or reporting bugs - no 
need to apologise ;-)

> >     Invalid query: ERROR: column "t" does not exist LINE 4: AND
> >     domain.active=t ^
[...]
> The main problem is that MySQL has 0 or 1 for boolean values (i.e. I
> think the schema uses a tinyint field, rather than boolean); whereas
> PostgreSQL uses boolean.
>
> Christian did suggest that perhaps we move PostgreSQL to use 0/1, but
> I didn't think this was a good idea.

Well, it would have avoided the quoting issue ;-)
(but it would probably have caused other issues, like a need to change 
the postfix config)

> I /think/ I've fixed functions.inc.php for you - but I suspect it
> [Postfixadmin] will be broken elsewhere.
>
> (*Wonders why this has suddenly become an issue, and what changed to
> screw the boolean values up*)

Probably your change in db_get_boolean to return t/f instead of 
true/false for postgresql (don't say I didn't warn you ;-)

I fixed some more queries (after grepping trough the code) - please test 
if the files I modified are working with postgresql. (I also still have 
to test them with MySQL ;-)

> There is a problem with PHP/PostgreSQL date handling at the moment
> too - I've not sat down to fix this yet, but you will find problems
> with the last modified columns etc.

Do you mean the string formatting problem you mentioned in IRC? Or 
something else?


Regards,

Christian Boltz
-- 
Hmm ... Du meinst das RamA ... Das macht das Frühstück gut ... denn 
wenn Du RamA verwendest, dann meckert die Frau nicht, wenn Du schon
zum Frühstück vor dem Rechner sitzt. [Konrad Neitzel in suse-linux]

Re: [Postfixadmin-devel] Boolean values

[Geoff S. <ge...@Qu...>]

On Fri, 21 Aug 2009, David Goodwin wrote:

> The main problem is that MySQL has 0 or 1 for boolean values (i.e. I
> think the schema uses a tinyint field, rather than boolean); whereas
> PostgreSQL uses boolean.

This is true and affects how one would retrieve stored data.  However my 
suggestion related to building queries, and both mysql and postgresql 
support TRUE and FALSE as constants.  It appears that these are the only 
boolean representations in queries that they have in common, all of PG's 
other alternatives are strings ('t', 'true', 'y', 'yes', 'on', '1'). 
Mysql obviously expects an integer, and TRUE and FALSe are simply 
constants that equal 1 and 0 respectively.  This is all spelled out in the 
documentation for both databases which I provided links for in my previous 
message.

> Christian did suggest that perhaps we move PostgreSQL to use 0/1, but I
> didn't think this was a good idea.

Given that the mysql documentation says that they'll eventually implement 
a proper boolean type, you might want to stick with it the way it is for 
now.

> I /think/ I've fixed functions.inc.php for you - but I suspect it
> [Postfixadmin] will be broken elsewhere.

Am happy to report anything else we find.

> There is a problem with PHP/PostgreSQL date handling at the moment too -
> I've not sat down to fix this yet, but you will find problems with the
> last modified columns etc.

I'm new to pg, having previously used mysql only, and am also new to 
postfixadmin.  But I'm happy to help out and will contribute wherever 
possible.  Still, at least odd last-modified dates shouldn't stop PA form 
working.

Thanks for the quick fix,

Geoff.

Re: [Postfixadmin-devel] Boolean values

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

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

Geoff Shang wrote:
> Hello,
> 
> I apologise for joining the list and posting immediately on a subject that 
> may well have had some considerable discussion already.
> 
> We are deploying PostfixAdmin (SVN as of about 17:00 UTC yesterday) on a 
> new system using PostgreSQL 8.4 and found the following bug.
> 
> If a regular admin (not super) logs in and selects Domain List, the 
> following error is generated:
> 
>     Invalid query: ERROR: column "t" does not exist LINE 4: AND
>     domain.active=t ^
> 
> I tracked this down to functions.inc.php line 783.  Obviously this needs 
> to be quoted, as does the next line.
> 
> I see that there's been some recent commits around boolean handling in 
> PGSQL, so some kind of policy on this might have already been decided. 
> However, looking at the MySQL and PGSQL documentation suggests that it 
> would be much easier to use TRUE and FALSE (unquoted) in queries than to 
> do what is currently done.  Current PGSQL (8.4) supports this[1] and has 
> done since at least version 6.3[2].  MySQL also suppports this[3][4] and 
> has done since probably version 4.0[5] (MySQL 3.23.49 does *not* support 
> this, despite the manual[5] suggesting otherwise).
> 
> It just strikes me that you could eliminate quoting issues and eliminate 
> different boolean handling for each db type at the same time.
> 
> I've not looked at much of the code but would be willing to help with 
> this.


Hi Geoff,

The main problem is that MySQL has 0 or 1 for boolean values (i.e. I
think the schema uses a tinyint field, rather than boolean); whereas
PostgreSQL uses boolean.

Christian did suggest that perhaps we move PostgreSQL to use 0/1, but I
didn't think this was a good idea.

I /think/ I've fixed functions.inc.php for you - but I suspect it
[Postfixadmin] will be broken elsewhere.

(*Wonders why this has suddenly become an issue, and what changed to
screw the boolean values up*)

There is a problem with PHP/PostgreSQL date handling at the moment too -
I've not sat down to fix this yet, but you will find problems with the
last modified columns etc.


thanks
David.
- --
David Goodwin

[ david at codepoets dot co dot uk ]
[ http://www.codepoets.co.uk       ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqOfDMACgkQ/ISo3RF5V6Y3iQCghqJCkkMadfGHG5V7HrG191Hh
vZwAoIk2gh1KfmLpkFVjDnBNhQU9GDBU
=ANHo
-----END PGP SIGNATURE-----

[Postfixadmin-devel] Boolean values

[Geoff S. <ge...@Qu...>]

Hello,

I apologise for joining the list and posting immediately on a subject that 
may well have had some considerable discussion already.

We are deploying PostfixAdmin (SVN as of about 17:00 UTC yesterday) on a 
new system using PostgreSQL 8.4 and found the following bug.

If a regular admin (not super) logs in and selects Domain List, the 
following error is generated:

    Invalid query: ERROR: column "t" does not exist LINE 4: AND
    domain.active=t ^

I tracked this down to functions.inc.php line 783.  Obviously this needs 
to be quoted, as does the next line.

I see that there's been some recent commits around boolean handling in 
PGSQL, so some kind of policy on this might have already been decided. 
However, looking at the MySQL and PGSQL documentation suggests that it 
would be much easier to use TRUE and FALSE (unquoted) in queries than to 
do what is currently done.  Current PGSQL (8.4) supports this[1] and has 
done since at least version 6.3[2].  MySQL also suppports this[3][4] and 
has done since probably version 4.0[5] (MySQL 3.23.49 does *not* support 
this, despite the manual[5] suggesting otherwise).

It just strikes me that you could eliminate quoting issues and eliminate 
different boolean handling for each db type at the same time.

I've not looked at much of the code but would be willing to help with 
this.

Cheers,
Geoff.


References:

1. http://www.postgresql.org/docs/8.4/static/datatype-boolean.html

2. http://www.postgresql.org/docs/6.3/static/c0805.htm

3. http://dev.mysql.com/doc/refman/6.0/en/numeric-type-overview.html

4. http://dev.mysql.com/doc/refman/5.4/en/numeric-type-overview.html

5. http://dev.mysql.com/doc/refman/4.1/en/numeric-type-overview.html

Re: [Postfixadmin-devel] Problem creating folders.

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

Hello,

Am Donnerstag, 20. August 2009 schrieb me...@td...:
> when I enable $CONF['create_mailbox_subdirs']=array('Spam'); and
> $CONF['create_mailbox_subdirs_host']='localhost'; and add an account
> the Spam folder is not created and I get the following in the
> http_error log:
>
> [Wed Aug 19 15:32:44 2009] [error] [client 192.168.0.3] Could not log
> into IMAP/POP server: Certificate failure for localhost: self signed
> certificate: /OU=IMAP
> server/CN=imap.example.com/emailAddress=pos...@ex...,

Your problem is that you use a self-signed certificate.

According to http://www.php.net/manual/en/function.imap-open.php you 
should be able to disable this check by using the /novalidate-cert flag.

> I do not see anything in the config file that would allow me to turn
> of the ssl stuff.

This was my first thought also - but it looks like postfixadmin still 
includes some surprises even for me ;-)

We indeed have a config setting for this. Try
   $CONF['create_mailbox_subdirs_hostoptions']=array('novalidate-cert');


@GingerDog: This option is only available as a _comment_ in 
config.inc.php. Maybe it would be more visible if it was not commented 
out. (This is also true for some other options.)
[If you agree, add it to the ToDo list / SF tracker. I don't want to 
risk breakage before we release 2.3 final ;-) ]


Regards,

Christian Boltz
-- 
Microsoft gives you Windows but Linux gives you the whole house!

[Postfixadmin-devel] Problem creating folders.

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

Hi,

I have setup pfa using the latest svn (r 706) and I an having a minor problem.

when I enable $CONF['create_mailbox_subdirs']=array('Spam'); and 
$CONF['create_mailbox_subdirs_host']='localhost'; and add an account the
Spam folder is not created and I get the following in the http_error log:

[Wed Aug 19 15:32:44 2009] [error] [client 192.168.0.3] Could not log into IMAP/POP server: Certificate failure for localhost: self signed certificate: /OU=IMAP server/CN=imap.example.com/emailAddress=pos...@ex..., referer: http://vrocky.mydomain.com/pfa/create-mailbox.php?domain=example.com
[Wed Aug 19 15:32:44 2009] [error] [client 192.168.0.3] PHP Notice:  Unknown: Certificate failure for localhost: self signed certificate: /OU=IMAP server/CN=imap.example.com/emailAddress=pos...@ex... (errflg=2) in Unknown on line 0, referer: http://vrocky.mydomain.com/pfa/create-mailbox.php?domain=example.com
[Wed Aug 19 15:33:26 2009] [error] [client 192.168.0.3] Could not log into IMAP/POP server: Certificate failure for localhost: self signed certificate: /OU=IMAP server/CN=imap.example.com/emailAddress=pos...@ex..., referer: http://vrocky.mydomain.com/pfa/create-mailbox.php?domain=example.com
[Wed Aug 19 15:33:26 2009] [error] [client 192.168.0.3] PHP Notice:  Unknown: Certificate failure for localhost: self signed certificate: /OU=IMAP server/CN=imap.example.com/emailAddress=pos...@ex... (errflg=2) in Unknown on line 0, referer: http://vrocky.mydomain.com/pfa/create-mailbox.php?domain=example.com

Can someone tell me how to configure pfa to create the folders? Using ssl
on this installation makes no sense given that pfa is talking to localhost
and that I am testing pfa on my local network. Once I am ready to put the
machine into production, I will setup ssl.

I do not see anything in the config file that would allow me to turn of the
ssl stuff.

Is there something else I should be looking at?

Regards,

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

Re: [Postfixadmin-devel] [ postfixadmin-Bugs-2809905 ] .deb package resquest the removal of mysql server

[Ruben L. <r....@is...>]

On Tuesday 28 July 2009 at 13:49 (CET), SourceForge.net wrote:
> I've set in the depend/recommend field to the meta-packages "mysql-server"
> and "mysql-client", which is common practice.

It could be worked around by depending on mysql-server | mysql-server-5.0 | 
mysql-server-5.1. Which, I admit, is kinda nasty.

> Ubuntu 9.04 points that meta-packages to the 5.0 version of mysql. I don't
> know why Ubuntu is shipping two versions of mysql and depend on the old
> one.

MySQL Server 5.0 is in main and thus supported by Canonical. MySQL Server 5.1 
is in universe and thus "supported" by the community.

-- 
Regards,

Ruben Laban
Systems and Network Administrator
ISM eCompany

Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[660] branches/postfixadmin-smarty/smarty

[ja n. <re...@ya...>]

Hi Christian,

sounds reasonable. I use Tortoise and I didn't know what happens if I just overwrite the files. Just didn't want to mess up things. I will consider next time...

Regards,
Sebastian

P.S.: I don't know if I create a new thread. Unfortunately, I'm not subscribed to the list yet.



      

[Postfixadmin-devel] (fwd) SourceForge.net feature deprecation upcoming: forums, DocManager, TaskManager, Diary/Notes

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

FWIW... Looks like we won't need to do much to improve the forums.
Hopefully.

David.

----- Forwarded message from "SourceForge.net Team" <no...@so...> -----

X-Virus-Scanned: by Amavis+SpamAssassin+ClamAV and more at palepurple.co.uk
X-Spam-Flag: NO
X-Spam-Score: -5.25
X-Spam-Level: 
X-Spam-Status: No, score=-5.25 tagged_above=-99 required=5 tests=[AWL=-0.507,
	BAYES_00=-2.599, DCC_CHECK=2.17, RCVD_IN_JMF_W=-5, SPF_NEUTRAL=0.686]
From: "SourceForge.net Team" <no...@so...>
To: me
Subject: SourceForge.net feature deprecation upcoming: forums, DocManager, TaskManager, Diary/Notes

Hello,

This mailing is being sent to all project administrators, and all users who
have used the Diary/Notes feature.  Please forward this to other members of
your team as needed.

The SourceForge.net team has been working for the past few months to expand
and refine our feature offering.  The Hosted Apps offering, launched last
September, has been expanded to include new apps, and is continuing to have
a strong rate of adoption among projects.

To best serve the needs of our community, we are electing to eliminate some
of the older site-integrated features in lieu of more viable replacements
we've launched as Hosted Apps.	These old features will be dropped after
data migration occurs, on a date to be announced later (at least 30 days
from now).  Eliminating these crufty, less-capable built-in applications
will allow us to focus our efforts on providing great service to our
projects, and ensure their needs are met.

We will provide an easy-to-use migration path to move the data to the
provided replacements.	We will also provide dumps of this data in case
projects want to do something different with their data.  Additional
information on how to obtain or migrate your data will be provided when the
timeline is announced, in a future mailing.

The following applications are due to be deprecated, replaced by
high-quality Open Source applications we have in our Hosted Apps offering:

 * TaskManager will be replaced by TaskFreak!, dotProject and Trac
(tickets).
 * DocManager will be replaced by MediaWiki and Trac (wiki).
 * Discussion Forums will be replaced by phpBB.
 * Diary and Notes will be replaced by WordPress.

To solicit your feedback on how the migration should be handled, and
alternate options you would like us to consider, we are running a survey
for the next 30 days for the user base of each of these applications.  For
links to the surveys, please see our Site Status post at:
http://tinyurl.com/q3g8o3

If you have questions or concerns, please contact our Support team at:
http://apps.sourceforge.net/trac/sourceforge/wiki/Support

Thank you,

The SourceForge.net team




----------------------------------------------------------------------

These mailing are sent to all Project administrators of record, 
regardless of Opt-in settings. If you want to inquire about removal, 
contact Support (https://sourceforge.net/projects/alexandria/support/).

This message was sent on behalf of SourceForge.net based on
the existence of your user account on our site.

To unsubscribe from future mailings, login to the SourceForge.net site
and request account removal at:
http://sourceforge.net/account/remove_account.php

Or contact us by postal mail at:
Attn:  SourceForge.net Legal Services - Account Removal
SourceForge, Inc.
650 Castro Street, Suite 450
Mountain View, CA  94041

Unsubscribe requests will be processed within 10 days of receipt. 

----- End forwarded message -----

-- 
David Goodwin 

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