postfixadmin-tracker Mailing List for PostfixAdmin (Page 32)
Brought to you by:
christian_boltz,
gingerdog
Menu
▾
▴
postfixadmin-tracker — Postfix Admin tracker notification - READ ONLY!
You can subscribe to this list here.
| 2007 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(5) |
Oct
(67) |
Nov
(83) |
Dec
(47) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2008 |
Jan
(57) |
Feb
(15) |
Mar
(21) |
Apr
(38) |
May
(27) |
Jun
(38) |
Jul
(35) |
Aug
(50) |
Sep
(8) |
Oct
(9) |
Nov
(59) |
Dec
(59) |
| 2009 |
Jan
(27) |
Feb
(42) |
Mar
(63) |
Apr
(46) |
May
(26) |
Jun
(25) |
Jul
(40) |
Aug
(19) |
Sep
(17) |
Oct
(35) |
Nov
(26) |
Dec
(21) |
| 2010 |
Jan
(11) |
Feb
(19) |
Mar
(40) |
Apr
(25) |
May
(23) |
Jun
(17) |
Jul
(10) |
Aug
(18) |
Sep
(21) |
Oct
(12) |
Nov
(10) |
Dec
(22) |
| 2011 |
Jan
(30) |
Feb
(23) |
Mar
(23) |
Apr
(38) |
May
(32) |
Jun
(19) |
Jul
(20) |
Aug
(36) |
Sep
(11) |
Oct
(28) |
Nov
(4) |
Dec
(4) |
| 2012 |
Jan
(6) |
Feb
(3) |
Mar
(16) |
Apr
(28) |
May
(29) |
Jun
(10) |
Jul
(2) |
Aug
(3) |
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(1) |
| 2013 |
Jan
(11) |
Feb
(7) |
Mar
(29) |
Apr
(2) |
May
(3) |
Jun
(15) |
Jul
(8) |
Aug
(5) |
Sep
(5) |
Oct
(4) |
Nov
(27) |
Dec
(81) |
| 2014 |
Jan
(12) |
Feb
(13) |
Mar
(5) |
Apr
|
May
(41) |
Jun
(16) |
Jul
(7) |
Aug
(10) |
Sep
(24) |
Oct
(50) |
Nov
|
Dec
(2) |
| 2015 |
Jan
(5) |
Feb
(2) |
Mar
(7) |
Apr
(20) |
May
(1) |
Jun
(3) |
Jul
(12) |
Aug
(1) |
Sep
(17) |
Oct
(5) |
Nov
(20) |
Dec
(10) |
| 2016 |
Jan
(10) |
Feb
(11) |
Mar
(22) |
Apr
(30) |
May
(33) |
Jun
(3) |
Jul
|
Aug
(12) |
Sep
(20) |
Oct
(11) |
Nov
(15) |
Dec
(8) |
| 2017 |
Jan
(1) |
Feb
(11) |
Mar
(10) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
(3) |
| 2018 |
Jan
(2) |
Feb
|
Mar
(1) |
Apr
|
May
(4) |
Jun
(2) |
Jul
(4) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: SourceForge.net <no...@so...> - 2009-08-06 16:26:55
|
Feature Requests item #2833239, was opened at 2009-08-06 17:26 Message generated for change (Settings changed) made by zordrak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2833239&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zordrak (zordrak) Assigned to: Nobody/Anonymous (nobody) >Summary: Configurable per-address reply options Initial Comment: Need to be able to provide per-address actions in the config so that certain addresses may have their own reply configurations. e.g. if ($recipient == fo...@ex...) { reply_each_time; else { reply once; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2833239&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-08-06 16:26:04
|
Feature Requests item #2833239, was opened at 2009-08-06 17:26 Message generated for change (Tracker Item Submitted) made by zordrak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2833239&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Zordrak (zordrak) Assigned to: Nobody/Anonymous (nobody) Summary: Secondary config Initial Comment: Need to be able to provide per-address actions in the config so that certain addresses may have their own reply configurations. e.g. if ($recipient == fo...@ex...) { reply_each_time; else { reply once; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937967&aid=2833239&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-08-04 20:48:11
|
Bugs item #2830001, was opened at 2009-07-31 00:14 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830001&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: v 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Shawn Djernes (sdjernes) Assigned to: Nobody/Anonymous (nobody) Summary: Domain List says all domains not active Initial Comment: 2.3rc6 All Domains are listed as "NO" in the active field. Even though when you go into the "Edit" screen they are active and they work. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-08-04 20:48 Message: fixed in subversion; note the db_get_boolean() function was changed to use 't' and 'f' and not 'true' and 'false' thanks for reporting the bug ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-08-04 20:48 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- Comment By: Christian Boltz (christian_boltz) Date: 2009-08-01 14:33 Message: I tested with 2.3 rc6 and also the latest SVN version (which has some unrelated changes) and can't reproduce this bug (using MySQL). What database do you use? If you use PosgreSQL, try a little change in templates/admin-list-domain.php line 74 and 77: (line 74) $backupmx = ($domain_properties[$i]['backupmx'] == 1) ? $PALANG['YES'] : $PALANG['NO']; (line 77) $active = ($domain_properties[$i]['active'] == 1) ? $PALANG['YES'] : $PALANG['NO']; Replace "== 1" with "== db_get_boolean(true)" - does this solve the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830001&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-08-01 14:35:36
|
Bugs item #2830002, was opened at 2009-07-31 02:17 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830002&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) >Group: v 2.3 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Shawn Djernes (sdjernes) Assigned to: Nobody/Anonymous (nobody) Summary: Domain List shows "NO" in columb for Backup MX when set Initial Comment: 2.3rc6 On the Domain List a Domain setup for Backup MX displays as no. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2009-08-01 16:35 Message: This bug probably has the same cause as bug 2830001, even if it is a different field. Closing as duplicate to avoid discussing the same thing two times. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830002&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-08-01 14:33:14
|
Bugs item #2830001, was opened at 2009-07-31 02:14 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830001&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shawn Djernes (sdjernes) Assigned to: Nobody/Anonymous (nobody) Summary: Domain List says all domains not active Initial Comment: 2.3rc6 All Domains are listed as "NO" in the active field. Even though when you go into the "Edit" screen they are active and they work. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2009-08-01 16:33 Message: I tested with 2.3 rc6 and also the latest SVN version (which has some unrelated changes) and can't reproduce this bug (using MySQL). What database do you use? If you use PosgreSQL, try a little change in templates/admin-list-domain.php line 74 and 77: (line 74) $backupmx = ($domain_properties[$i]['backupmx'] == 1) ? $PALANG['YES'] : $PALANG['NO']; (line 77) $active = ($domain_properties[$i]['active'] == 1) ? $PALANG['YES'] : $PALANG['NO']; Replace "== 1" with "== db_get_boolean(true)" - does this solve the problem? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830001&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-31 00:17:31
|
Bugs item #2830002, was opened at 2009-07-30 19:17 Message generated for change (Tracker Item Submitted) made by sdjernes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830002&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shawn Djernes (sdjernes) Assigned to: Nobody/Anonymous (nobody) Summary: Domain List shows "NO" in columb for Backup MX when set Initial Comment: 2.3rc6 On the Domain List a Domain setup for Backup MX displays as no. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830002&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-31 00:14:45
|
Bugs item #2830001, was opened at 2009-07-30 19:14 Message generated for change (Tracker Item Submitted) made by sdjernes You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830001&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Interface (example) Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Shawn Djernes (sdjernes) Assigned to: Nobody/Anonymous (nobody) Summary: Domain List says all domains not active Initial Comment: 2.3rc6 All Domains are listed as "NO" in the active field. Even though when you go into the "Edit" screen they are active and they work. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2830001&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-30 07:35:26
|
Bugs item #2829452, was opened at 2009-07-30 06:06 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2829452&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v 2.3 >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Ryow (ryowsuzuki) Assigned to: Nobody/Anonymous (nobody) Summary: backup.php sometimes needs directory_separator Initial Comment: Hi developers. I did backup but the content of sql file was php errors, saying, upload_tmp_dir setting is "/var/lib/php/tmp" and backup.php tried to open "/var/lib/php/tmppostfixadmin-20090730-19251.sql", witch is out of open_basedir setting "/var/lib/php/tmp". ini_get('upload_tmp_dir') doesn't have a last slash in my environment, but backup.php just attaches a file name to the upload_tmp_dir without slash. I just fixed to work in 57 to 59 like below. $path = (ini_get('upload_tmp_dir') != '') ? ini_get('upload_tmp_dir') : '/tmp'; // '/tmp/' -> '/tmp' $filename = "postfixadmin-" . date ("Ymd") . "-" . getmypid() . ".sql"; $backup = $path . DIRECTORY_SEPARATOR . $filename; // added a DIRECTORY_SEPARATOR I hope this bugfix will be applied in the next release. Best regards ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-30 07:35 Message: patch merged; thank you. see changeset 697 ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-30 07:35 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2829452&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-30 06:06:38
|
Bugs item #2829452, was opened at 2009-07-30 15:06 Message generated for change (Tracker Item Submitted) made by ryowsuzuki You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2829452&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ryow (ryowsuzuki) Assigned to: Nobody/Anonymous (nobody) Summary: backup.php sometimes needs directory_separator Initial Comment: Hi developers. I did backup but the content of sql file was php errors, saying, upload_tmp_dir setting is "/var/lib/php/tmp" and backup.php tried to open "/var/lib/php/tmppostfixadmin-20090730-19251.sql", witch is out of open_basedir setting "/var/lib/php/tmp". ini_get('upload_tmp_dir') doesn't have a last slash in my environment, but backup.php just attaches a file name to the upload_tmp_dir without slash. I just fixed to work in 57 to 59 like below. $path = (ini_get('upload_tmp_dir') != '') ? ini_get('upload_tmp_dir') : '/tmp'; // '/tmp/' -> '/tmp' $filename = "postfixadmin-" . date ("Ymd") . "-" . getmypid() . ".sql"; $backup = $path . DIRECTORY_SEPARATOR . $filename; // added a DIRECTORY_SEPARATOR I hope this bugfix will be applied in the next release. Best regards ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2829452&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 23:02:14
|
Bugs item #2814820, was opened at 2009-06-30 22:18 Message generated for change (Comment added) made by christian_boltz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: nls (nls) Assigned to: Nobody/Anonymous (nobody) Summary: crypt() is not used according to specs Initial Comment: In functions.inc.php, pacrypt() uses the php crypt() function the wrong way when processing MD5 hashes. For the salt, all 12 characters of the input password hash salt must be used, including the magic sequence and the closing dollar sign, for example: "$1$abcdefgh$". Otherwise the crypt() function generates the shorter DES password hashes and password comparison always fails. This problem has become apparent for me when I was trying to migrate a user db for postfixadmin, where user password hashes are stored as DES for some users, and as MD5 for others. pacrypt() would be able to handle both, but currently it doesn't because of the forementioned mistake. Simply using $salt = "\$1\$${split_salt[2]}\$"; solves the problem. ---------------------------------------------------------------------- >Comment By: Christian Boltz (christian_boltz) Date: 2009-07-29 01:02 Message: Your patch re-introduced an ereg() call which is deprecated in PHP 5.3. I replaced it with preg_match(). Please test with SVN r696 to make sure I didn't accidently break it ;-) ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 23:34 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 23:33 Message: patch applied; see 2.3rc7 . thanks. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-24 19:46 Message: Patch attached. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 21:08 Message: a patch against svn-current would be great -then there's no chance for me to fsck stuff up ;-) David ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 17:42 Message: Additionally, please have a look at the official examples provided on the documentation page you have linked (and their included comments). Althought they're not explicitly formed documentation paragraphs, they seem to back what I have already said on the subject. If you see my reasoning acceptable, I'm happy to provide a patch you might want to apply. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 17:35 Message: Indeed, but it does work this way: if the salt length is less than 12, the short crypt sequence is used. If it is 12, then the salted MD5 crypt variant is used. If you pass the 12 characters of the salt that includes all separator dollar signs, it creates the proper MD5 hash. Otherwise it falls back to the shorter variant. I've applied the mentioned fixes in my installation and they work as I have already described; encodes both kind of hashes properly and all my users can log in. Maybe I should ask for a clarification of the PHP docs from the PHP documentation maintainers? Whatever the case, it is not working properly in PostfixAdmin right now. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 15:04 Message: err http://php.net/crypt doesn't mention anything about a trailing $ for crypt's salt field. David. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-06-30 23:20 Message: And one thing i forgot, related to this problem: the ereg expression is written as ereg ("\$1\$", $pw_db), and that is wrong. Instead it should be written as ereg ("\\$1\\$", $pw_db)), with double backslashes. Otherwise the if () will never evaluate true when an MD5 hash is passed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 13:18:19
|
Bugs item #2821172, was opened at 2009-07-14 09:33 Message generated for change (Comment added) made by ulfsimmer You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2821172&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ulf Simmer (ulfsimmer) Assigned to: Nobody/Anonymous (nobody) Summary: \r\n visible in automatic answer Initial Comment: When enabling vacation, the original sender gets the (automatic) answer with visible \r\n (carriage return, new line). Perl is v5.8.9 2009/07/14 09:14:04 DEBUG> /home/vacation/vacation.pl:401 main::send_vacation_email - Vacation response sent, Mail::Sendmail said : Mail::Sendmail v. 0.79 - Tue Jul 1 4 09:14:04 2009 ---------------------------------------------------------------------- >Comment By: Ulf Simmer (ulfsimmer) Date: 2009-07-28 15:18 Message: it's from 2.3rc2 #!/usr/bin/perl -w # # Virtual Vacation 4.0 # $Revision: 535 $ # Originally by Mischa Peters <mischa at high5 dot net> # ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-28 13:48 Message: any idea of what version of vacation.pl you are using? Is it from e.g. svn or an older release? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2821172&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 11:50:39
|
Bugs item #2823018, was opened at 2009-07-17 11:40 Message generated for change (Settings changed) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: v 2.2 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Oskar Szafraniec (oscarek) Assigned to: Nobody/Anonymous (nobody) Summary: already_notified subroutine - _pkey problem Initial Comment: I’m writing in subject of already_notified subroutine. As it’s written in comment there, violation of primary key can happen, and this is true. But after this comment is a line like this: if ($e !~ /_pkey/) { On my system it started to produce 2 things… First, the condition was always true, because the error message didn’t include the “_pkey” string. This can be because of mysql version (I have 5.0.81). Instead of key name the error message had only “key 1” string. Next, because of the above vacation.pl was sending response every time. On our system this was producing 2 vacation-response per email, because emails goes first to localhost for virus-check and then are sent again to the recipient. Both was also served by vacation.pl and produced an “out-of-office” email. This is my free-thoughts about why this was, as I don’t know so much how postfix works (this is our admin’s domain :) So my suggestion is to change maybe the condition to something like this: if ($e !~ /key 1/ && $e !~ /_pkey/) { Key 1 (I think) is always a PRIMARY key, so on my system I’m using just line like this now, with 100% success: if ($e !~ /key 1/) { As English is not my native language, if something is not clear, feel free to ask questions :) My MySQL version is 5.0.81. vacation_notification is as it should be, so it’s structure is not a case (I was checking this number of times today :) I hope my email will be useful. ---------------------------------------------------------------------- Comment By: Oskar Szafraniec (oscarek) Date: 2009-07-28 09:41 Message: for your information, freebsd postfixadmin port is 1 year out of date and this is why we have very old version of vacation.pl with the bug above. so mayby it's time to get the port for freebsd updated? ;) ---------------------------------------------------------------------- Comment By: Oskar Szafraniec (oscarek) Date: 2009-07-28 09:33 Message: you are right, I have old version :( my mistake. sorry. in the current version everything is OK. please feel free to delete above. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 20:21 Message: Hmm. Looking at the code - I think you're using an out of date version; any chance of updating and letting me know whether this fixes the issue? {{{ # Violation of a primay key constraint may happen here, and that's # fine. All other error conditions are not fine, however. if ($e !~ /(?:_pkey|^Duplicate entry)/) { $logger->error("Failed to insert into vacation_notification table (to:$to from:$from error:'$e' query:'$query')"); # Let's play safe and notify anyway return 1; } }}} ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 20:19 Message: Hi, I thought it was the case that MySQL didn't have a primary key on the table, and so never raised that error message. Perhaps this changed somewhere... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 11:49:05
|
Bugs item #2809905, was opened at 2009-06-21 15:23 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2809905&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Database Group: v 2.3 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Filipe Fagundes (piovisqui) Assigned to: Nobody/Anonymous (nobody) Summary: .deb package resquest the removal of mysql server Initial Comment: I have download the postfixadmin_2.3_RC5_all.deb on Ubuntu 9.04. When I asked the install the package requires the REMOVAL of mysql server 5.1 and mysql client 5.1 and the installation of mysql client 5.0. It does not ask the install of mysql server 5.0. I downloaded RC4 and it installed successful. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-28 11:49 Message: blame ubuntu ;-) ---------------------------------------------------------------------- Comment By: Norman Messtorff (normes) Date: 2009-07-12 16:47 Message: As I've expected, this isn't a fault in the PA package. In my fresh installed and up-to-date Ubuntu 9.04 test installation I installed the packages mysql-client-5.1 and mysql-server-5.1 via synaptic. When I tried to install the PA .deb, I got also asked to remove the packages and install mysql-client-5.0 and mysql-server-5.0. I've set in the depend/recommend field to the meta-packages "mysql-server" and "mysql-client", which is common practice. 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. ---------------------------------------------------------------------- Comment By: Norman Messtorff (normes) Date: 2009-06-28 21:15 Message: I'll check this behaviour in a fresh Ubuntu 9.04 environment the next days. We could have this issue in Ubuntu and possible Debian too, but i can't see the problem at first view. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-06-22 10:11 Message: the dependency on wwwconfig-common is now not an issue; the debian control file doesn't specify any version requirements for mysql/postgresql, so i'm not sure why you'd get these problem(s). ---------------------------------------------------------------------- Comment By: Bjorn (bjornnilsen) Date: 2009-06-22 00:14 Message: The dependancies on this latest deb are very restrictive and have caused issues for me as well. The new wwwconfig-common dependency means that this deb is no longer supported with Ubuntu 8.04. $ sudo dpkg -i postfixadmin_2.3rc5_all.deb Selecting previously deselected package postfixadmin. (Reading database ... 25961 files and directories currently installed.) Unpacking postfixadmin (from postfixadmin_2.3rc5_all.deb) ... dpkg: dependency problems prevent configuration of postfixadmin: postfixadmin depends on wwwconfig-common (>= 0.2.0); however: Version of wwwconfig-common on system is 0.0.48. dpkg: error processing postfixadmin (--install): dependency problems - leaving unconfigured Errors were encountered while processing: postfixadmin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2809905&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 11:48:00
|
Bugs item #2821172, was opened at 2009-07-14 07:33 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2821172&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Ulf Simmer (ulfsimmer) Assigned to: Nobody/Anonymous (nobody) Summary: \r\n visible in automatic answer Initial Comment: When enabling vacation, the original sender gets the (automatic) answer with visible \r\n (carriage return, new line). Perl is v5.8.9 2009/07/14 09:14:04 DEBUG> /home/vacation/vacation.pl:401 main::send_vacation_email - Vacation response sent, Mail::Sendmail said : Mail::Sendmail v. 0.79 - Tue Jul 1 4 09:14:04 2009 ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-28 11:48 Message: any idea of what version of vacation.pl you are using? Is it from e.g. svn or an older release? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2821172&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 11:46:58
|
Bugs item #2827499, was opened at 2009-07-26 22:34 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2827499&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Patryk Sciborek (scibi) Assigned to: Nobody/Anonymous (nobody) Summary: /usr/share/postfixadmin/confd-link.sh: No such file or direc Initial Comment: I cannot install/remove Postfix Admin 2.3rc6 on Debian Lenny because postinst and prerm scripts try to run /usr/share/postfixadmin/confd-link.sh which doesn't exists: root@node1:/root# LC_ALL=C dpkg --purge postfixadmin (Reading database ... 14008 files and directories currently installed.) Removing postfixadmin ... /var/lib/dpkg/info/postfixadmin.prerm: line 20: /usr/share/postfixadmin/confd-link.sh: No such file or directory dpkg: error processing postfixadmin (--purge): subprocess pre-removal script returned error exit status 1 Errors were encountered while processing: postfixadmin ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-28 11:46 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 21:00 Message: Hi, If you have wwwconfig-common 0.2.1 installed there's no problem.... the problem occurs when/if you're using wwwconfig-common 0.1.2 (at least this was what my limited testing seemed to imply) I think I've patched the latest version to fix this problem, but you may need to mess with /var/lib/dpkg/postfixadmin.prerm to remove the reference to the script that doesn't exist any longer. I'll merge one other patch in, and then release 2.3rc7. Thanks! ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 21:00 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2827499&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 09:41:02
|
Bugs item #2823018, was opened at 2009-07-17 13:40 Message generated for change (Comment added) made by oscarek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oskar Szafraniec (oscarek) Assigned to: Nobody/Anonymous (nobody) Summary: already_notified subroutine - _pkey problem Initial Comment: I’m writing in subject of already_notified subroutine. As it’s written in comment there, violation of primary key can happen, and this is true. But after this comment is a line like this: if ($e !~ /_pkey/) { On my system it started to produce 2 things… First, the condition was always true, because the error message didn’t include the “_pkey” string. This can be because of mysql version (I have 5.0.81). Instead of key name the error message had only “key 1” string. Next, because of the above vacation.pl was sending response every time. On our system this was producing 2 vacation-response per email, because emails goes first to localhost for virus-check and then are sent again to the recipient. Both was also served by vacation.pl and produced an “out-of-office” email. This is my free-thoughts about why this was, as I don’t know so much how postfix works (this is our admin’s domain :) So my suggestion is to change maybe the condition to something like this: if ($e !~ /key 1/ && $e !~ /_pkey/) { Key 1 (I think) is always a PRIMARY key, so on my system I’m using just line like this now, with 100% success: if ($e !~ /key 1/) { As English is not my native language, if something is not clear, feel free to ask questions :) My MySQL version is 5.0.81. vacation_notification is as it should be, so it’s structure is not a case (I was checking this number of times today :) I hope my email will be useful. ---------------------------------------------------------------------- >Comment By: Oskar Szafraniec (oscarek) Date: 2009-07-28 11:41 Message: for your information, freebsd postfixadmin port is 1 year out of date and this is why we have very old version of vacation.pl with the bug above. so mayby it's time to get the port for freebsd updated? ;) ---------------------------------------------------------------------- Comment By: Oskar Szafraniec (oscarek) Date: 2009-07-28 11:33 Message: you are right, I have old version :( my mistake. sorry. in the current version everything is OK. please feel free to delete above. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 22:21 Message: Hmm. Looking at the code - I think you're using an out of date version; any chance of updating and letting me know whether this fixes the issue? {{{ # Violation of a primay key constraint may happen here, and that's # fine. All other error conditions are not fine, however. if ($e !~ /(?:_pkey|^Duplicate entry)/) { $logger->error("Failed to insert into vacation_notification table (to:$to from:$from error:'$e' query:'$query')"); # Let's play safe and notify anyway return 1; } }}} ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 22:19 Message: Hi, I thought it was the case that MySQL didn't have a primary key on the table, and so never raised that error message. Perhaps this changed somewhere... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-28 09:33:09
|
Bugs item #2823018, was opened at 2009-07-17 13:40 Message generated for change (Comment added) made by oscarek You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oskar Szafraniec (oscarek) Assigned to: Nobody/Anonymous (nobody) Summary: already_notified subroutine - _pkey problem Initial Comment: I’m writing in subject of already_notified subroutine. As it’s written in comment there, violation of primary key can happen, and this is true. But after this comment is a line like this: if ($e !~ /_pkey/) { On my system it started to produce 2 things… First, the condition was always true, because the error message didn’t include the “_pkey” string. This can be because of mysql version (I have 5.0.81). Instead of key name the error message had only “key 1” string. Next, because of the above vacation.pl was sending response every time. On our system this was producing 2 vacation-response per email, because emails goes first to localhost for virus-check and then are sent again to the recipient. Both was also served by vacation.pl and produced an “out-of-office” email. This is my free-thoughts about why this was, as I don’t know so much how postfix works (this is our admin’s domain :) So my suggestion is to change maybe the condition to something like this: if ($e !~ /key 1/ && $e !~ /_pkey/) { Key 1 (I think) is always a PRIMARY key, so on my system I’m using just line like this now, with 100% success: if ($e !~ /key 1/) { As English is not my native language, if something is not clear, feel free to ask questions :) My MySQL version is 5.0.81. vacation_notification is as it should be, so it’s structure is not a case (I was checking this number of times today :) I hope my email will be useful. ---------------------------------------------------------------------- >Comment By: Oskar Szafraniec (oscarek) Date: 2009-07-28 11:33 Message: you are right, I have old version :( my mistake. sorry. in the current version everything is OK. please feel free to delete above. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 22:21 Message: Hmm. Looking at the code - I think you're using an out of date version; any chance of updating and letting me know whether this fixes the issue? {{{ # Violation of a primay key constraint may happen here, and that's # fine. All other error conditions are not fine, however. if ($e !~ /(?:_pkey|^Duplicate entry)/) { $logger->error("Failed to insert into vacation_notification table (to:$to from:$from error:'$e' query:'$query')"); # Let's play safe and notify anyway return 1; } }}} ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 22:19 Message: Hi, I thought it was the case that MySQL didn't have a primary key on the table, and so never raised that error message. Perhaps this changed somewhere... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-27 21:34:34
|
Bugs item #2814820, was opened at 2009-06-30 20:18 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: nls (nls) Assigned to: Nobody/Anonymous (nobody) Summary: crypt() is not used according to specs Initial Comment: In functions.inc.php, pacrypt() uses the php crypt() function the wrong way when processing MD5 hashes. For the salt, all 12 characters of the input password hash salt must be used, including the magic sequence and the closing dollar sign, for example: "$1$abcdefgh$". Otherwise the crypt() function generates the shorter DES password hashes and password comparison always fails. This problem has become apparent for me when I was trying to migrate a user db for postfixadmin, where user password hashes are stored as DES for some users, and as MD5 for others. pacrypt() would be able to handle both, but currently it doesn't because of the forementioned mistake. Simply using $salt = "\$1\$${split_salt[2]}\$"; solves the problem. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 21:34 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 21:33 Message: patch applied; see 2.3rc7 . thanks. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-24 17:46 Message: Patch attached. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 19:08 Message: a patch against svn-current would be great -then there's no chance for me to fsck stuff up ;-) David ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 15:42 Message: Additionally, please have a look at the official examples provided on the documentation page you have linked (and their included comments). Althought they're not explicitly formed documentation paragraphs, they seem to back what I have already said on the subject. If you see my reasoning acceptable, I'm happy to provide a patch you might want to apply. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 15:35 Message: Indeed, but it does work this way: if the salt length is less than 12, the short crypt sequence is used. If it is 12, then the salted MD5 crypt variant is used. If you pass the 12 characters of the salt that includes all separator dollar signs, it creates the proper MD5 hash. Otherwise it falls back to the shorter variant. I've applied the mentioned fixes in my installation and they work as I have already described; encodes both kind of hashes properly and all my users can log in. Maybe I should ask for a clarification of the PHP docs from the PHP documentation maintainers? Whatever the case, it is not working properly in PostfixAdmin right now. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 13:04 Message: err http://php.net/crypt doesn't mention anything about a trailing $ for crypt's salt field. David. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-06-30 21:20 Message: And one thing i forgot, related to this problem: the ereg expression is written as ereg ("\$1\$", $pw_db), and that is wrong. Instead it should be written as ereg ("\\$1\\$", $pw_db)), with double backslashes. Otherwise the if () will never evaluate true when an MD5 hash is passed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-27 21:33:47
|
Bugs item #2814820, was opened at 2009-06-30 20:18 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: nls (nls) Assigned to: Nobody/Anonymous (nobody) Summary: crypt() is not used according to specs Initial Comment: In functions.inc.php, pacrypt() uses the php crypt() function the wrong way when processing MD5 hashes. For the salt, all 12 characters of the input password hash salt must be used, including the magic sequence and the closing dollar sign, for example: "$1$abcdefgh$". Otherwise the crypt() function generates the shorter DES password hashes and password comparison always fails. This problem has become apparent for me when I was trying to migrate a user db for postfixadmin, where user password hashes are stored as DES for some users, and as MD5 for others. pacrypt() would be able to handle both, but currently it doesn't because of the forementioned mistake. Simply using $salt = "\$1\$${split_salt[2]}\$"; solves the problem. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-27 21:33 Message: patch applied; see 2.3rc7 . thanks. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-24 17:46 Message: Patch attached. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 19:08 Message: a patch against svn-current would be great -then there's no chance for me to fsck stuff up ;-) David ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 15:42 Message: Additionally, please have a look at the official examples provided on the documentation page you have linked (and their included comments). Althought they're not explicitly formed documentation paragraphs, they seem to back what I have already said on the subject. If you see my reasoning acceptable, I'm happy to provide a patch you might want to apply. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 15:35 Message: Indeed, but it does work this way: if the salt length is less than 12, the short crypt sequence is used. If it is 12, then the salted MD5 crypt variant is used. If you pass the 12 characters of the salt that includes all separator dollar signs, it creates the proper MD5 hash. Otherwise it falls back to the shorter variant. I've applied the mentioned fixes in my installation and they work as I have already described; encodes both kind of hashes properly and all my users can log in. Maybe I should ask for a clarification of the PHP docs from the PHP documentation maintainers? Whatever the case, it is not working properly in PostfixAdmin right now. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 13:04 Message: err http://php.net/crypt doesn't mention anything about a trailing $ for crypt's salt field. David. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-06-30 21:20 Message: And one thing i forgot, related to this problem: the ereg expression is written as ereg ("\$1\$", $pw_db), and that is wrong. Instead it should be written as ereg ("\\$1\\$", $pw_db)), with double backslashes. Otherwise the if () will never evaluate true when an MD5 hash is passed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-27 21:00:32
|
Bugs item #2827499, was opened at 2009-07-26 22:34 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2827499&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 Status: Open >Resolution: Fixed Priority: 5 Private: No Submitted By: Patryk Sciborek (scibi) Assigned to: Nobody/Anonymous (nobody) Summary: /usr/share/postfixadmin/confd-link.sh: No such file or direc Initial Comment: I cannot install/remove Postfix Admin 2.3rc6 on Debian Lenny because postinst and prerm scripts try to run /usr/share/postfixadmin/confd-link.sh which doesn't exists: root@node1:/root# LC_ALL=C dpkg --purge postfixadmin (Reading database ... 14008 files and directories currently installed.) Removing postfixadmin ... /var/lib/dpkg/info/postfixadmin.prerm: line 20: /usr/share/postfixadmin/confd-link.sh: No such file or directory dpkg: error processing postfixadmin (--purge): subprocess pre-removal script returned error exit status 1 Errors were encountered while processing: postfixadmin ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-27 21:00 Message: Hi, If you have wwwconfig-common 0.2.1 installed there's no problem.... the problem occurs when/if you're using wwwconfig-common 0.1.2 (at least this was what my limited testing seemed to imply) I think I've patched the latest version to fix this problem, but you may need to mess with /var/lib/dpkg/postfixadmin.prerm to remove the reference to the script that doesn't exist any longer. I'll merge one other patch in, and then release 2.3rc7. Thanks! ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 21:00 Message: Thanks for the bug report; we believe this has been fixed in subversion. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2827499&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-27 20:22:02
|
Bugs item #2823018, was opened at 2009-07-17 11:40 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oskar Szafraniec (oscarek) Assigned to: Nobody/Anonymous (nobody) Summary: already_notified subroutine - _pkey problem Initial Comment: I’m writing in subject of already_notified subroutine. As it’s written in comment there, violation of primary key can happen, and this is true. But after this comment is a line like this: if ($e !~ /_pkey/) { On my system it started to produce 2 things… First, the condition was always true, because the error message didn’t include the “_pkey” string. This can be because of mysql version (I have 5.0.81). Instead of key name the error message had only “key 1” string. Next, because of the above vacation.pl was sending response every time. On our system this was producing 2 vacation-response per email, because emails goes first to localhost for virus-check and then are sent again to the recipient. Both was also served by vacation.pl and produced an “out-of-office” email. This is my free-thoughts about why this was, as I don’t know so much how postfix works (this is our admin’s domain :) So my suggestion is to change maybe the condition to something like this: if ($e !~ /key 1/ && $e !~ /_pkey/) { Key 1 (I think) is always a PRIMARY key, so on my system I’m using just line like this now, with 100% success: if ($e !~ /key 1/) { As English is not my native language, if something is not clear, feel free to ask questions :) My MySQL version is 5.0.81. vacation_notification is as it should be, so it’s structure is not a case (I was checking this number of times today :) I hope my email will be useful. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-27 20:21 Message: Hmm. Looking at the code - I think you're using an out of date version; any chance of updating and letting me know whether this fixes the issue? {{{ # Violation of a primay key constraint may happen here, and that's # fine. All other error conditions are not fine, however. if ($e !~ /(?:_pkey|^Duplicate entry)/) { $logger->error("Failed to insert into vacation_notification table (to:$to from:$from error:'$e' query:'$query')"); # Let's play safe and notify anyway return 1; } }}} ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-27 20:19 Message: Hi, I thought it was the case that MySQL didn't have a primary key on the table, and so never raised that error message. Perhaps this changed somewhere... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-27 20:19:36
|
Bugs item #2823018, was opened at 2009-07-17 11:40 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Vacation Group: v 2.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Oskar Szafraniec (oscarek) Assigned to: Nobody/Anonymous (nobody) Summary: already_notified subroutine - _pkey problem Initial Comment: I’m writing in subject of already_notified subroutine. As it’s written in comment there, violation of primary key can happen, and this is true. But after this comment is a line like this: if ($e !~ /_pkey/) { On my system it started to produce 2 things… First, the condition was always true, because the error message didn’t include the “_pkey” string. This can be because of mysql version (I have 5.0.81). Instead of key name the error message had only “key 1” string. Next, because of the above vacation.pl was sending response every time. On our system this was producing 2 vacation-response per email, because emails goes first to localhost for virus-check and then are sent again to the recipient. Both was also served by vacation.pl and produced an “out-of-office” email. This is my free-thoughts about why this was, as I don’t know so much how postfix works (this is our admin’s domain :) So my suggestion is to change maybe the condition to something like this: if ($e !~ /key 1/ && $e !~ /_pkey/) { Key 1 (I think) is always a PRIMARY key, so on my system I’m using just line like this now, with 100% success: if ($e !~ /key 1/) { As English is not my native language, if something is not clear, feel free to ask questions :) My MySQL version is 5.0.81. vacation_notification is as it should be, so it’s structure is not a case (I was checking this number of times today :) I hope my email will be useful. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-27 20:19 Message: Hi, I thought it was the case that MySQL didn't have a primary key on the table, and so never raised that error message. Perhaps this changed somewhere... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2823018&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-26 22:34:55
|
Bugs item #2827499, was opened at 2009-07-27 00:34 Message generated for change (Tracker Item Submitted) made by scibi You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2827499&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Patryk Sciborek (scibi) Assigned to: Nobody/Anonymous (nobody) Summary: /usr/share/postfixadmin/confd-link.sh: No such file or direc Initial Comment: I cannot install/remove Postfix Admin 2.3rc6 on Debian Lenny because postinst and prerm scripts try to run /usr/share/postfixadmin/confd-link.sh which doesn't exists: root@node1:/root# LC_ALL=C dpkg --purge postfixadmin (Reading database ... 14008 files and directories currently installed.) Removing postfixadmin ... /var/lib/dpkg/info/postfixadmin.prerm: line 20: /usr/share/postfixadmin/confd-link.sh: No such file or directory dpkg: error processing postfixadmin (--purge): subprocess pre-removal script returned error exit status 1 Errors were encountered while processing: postfixadmin ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2827499&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-24 17:46:40
|
Bugs item #2814820, was opened at 2009-06-30 22:18 Message generated for change (Comment added) made by nls You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: nls (nls) Assigned to: Nobody/Anonymous (nobody) Summary: crypt() is not used according to specs Initial Comment: In functions.inc.php, pacrypt() uses the php crypt() function the wrong way when processing MD5 hashes. For the salt, all 12 characters of the input password hash salt must be used, including the magic sequence and the closing dollar sign, for example: "$1$abcdefgh$". Otherwise the crypt() function generates the shorter DES password hashes and password comparison always fails. This problem has become apparent for me when I was trying to migrate a user db for postfixadmin, where user password hashes are stored as DES for some users, and as MD5 for others. pacrypt() would be able to handle both, but currently it doesn't because of the forementioned mistake. Simply using $salt = "\$1\$${split_salt[2]}\$"; solves the problem. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-24 19:46 Message: Patch attached. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 21:08 Message: a patch against svn-current would be great -then there's no chance for me to fsck stuff up ;-) David ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 17:42 Message: Additionally, please have a look at the official examples provided on the documentation page you have linked (and their included comments). Althought they're not explicitly formed documentation paragraphs, they seem to back what I have already said on the subject. If you see my reasoning acceptable, I'm happy to provide a patch you might want to apply. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 17:35 Message: Indeed, but it does work this way: if the salt length is less than 12, the short crypt sequence is used. If it is 12, then the salted MD5 crypt variant is used. If you pass the 12 characters of the salt that includes all separator dollar signs, it creates the proper MD5 hash. Otherwise it falls back to the shorter variant. I've applied the mentioned fixes in my installation and they work as I have already described; encodes both kind of hashes properly and all my users can log in. Maybe I should ask for a clarification of the PHP docs from the PHP documentation maintainers? Whatever the case, it is not working properly in PostfixAdmin right now. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 15:04 Message: err http://php.net/crypt doesn't mention anything about a trailing $ for crypt's salt field. David. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-06-30 23:20 Message: And one thing i forgot, related to this problem: the ereg expression is written as ereg ("\$1\$", $pw_db), and that is wrong. Instead it should be written as ereg ("\\$1\\$", $pw_db)), with double backslashes. Otherwise the if () will never evaluate true when an MD5 hash is passed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 |
|
From: SourceForge.net <no...@so...> - 2009-07-19 19:08:32
|
Bugs item #2814820, was opened at 2009-06-30 20:18 Message generated for change (Comment added) made by gingerdog You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Core Group: v 2.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: nls (nls) Assigned to: Nobody/Anonymous (nobody) Summary: crypt() is not used according to specs Initial Comment: In functions.inc.php, pacrypt() uses the php crypt() function the wrong way when processing MD5 hashes. For the salt, all 12 characters of the input password hash salt must be used, including the magic sequence and the closing dollar sign, for example: "$1$abcdefgh$". Otherwise the crypt() function generates the shorter DES password hashes and password comparison always fails. This problem has become apparent for me when I was trying to migrate a user db for postfixadmin, where user password hashes are stored as DES for some users, and as MD5 for others. pacrypt() would be able to handle both, but currently it doesn't because of the forementioned mistake. Simply using $salt = "\$1\$${split_salt[2]}\$"; solves the problem. ---------------------------------------------------------------------- >Comment By: GingerDog (gingerdog) Date: 2009-07-19 19:08 Message: a patch against svn-current would be great -then there's no chance for me to fsck stuff up ;-) David ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 15:42 Message: Additionally, please have a look at the official examples provided on the documentation page you have linked (and their included comments). Althought they're not explicitly formed documentation paragraphs, they seem to back what I have already said on the subject. If you see my reasoning acceptable, I'm happy to provide a patch you might want to apply. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-07-19 15:35 Message: Indeed, but it does work this way: if the salt length is less than 12, the short crypt sequence is used. If it is 12, then the salted MD5 crypt variant is used. If you pass the 12 characters of the salt that includes all separator dollar signs, it creates the proper MD5 hash. Otherwise it falls back to the shorter variant. I've applied the mentioned fixes in my installation and they work as I have already described; encodes both kind of hashes properly and all my users can log in. Maybe I should ask for a clarification of the PHP docs from the PHP documentation maintainers? Whatever the case, it is not working properly in PostfixAdmin right now. ---------------------------------------------------------------------- Comment By: GingerDog (gingerdog) Date: 2009-07-19 13:04 Message: err http://php.net/crypt doesn't mention anything about a trailing $ for crypt's salt field. David. ---------------------------------------------------------------------- Comment By: nls (nls) Date: 2009-06-30 21:20 Message: And one thing i forgot, related to this problem: the ereg expression is written as ereg ("\$1\$", $pw_db), and that is wrong. Instead it should be written as ereg ("\\$1\\$", $pw_db)), with double backslashes. Otherwise the if () will never evaluate true when an MD5 hash is passed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=937964&aid=2814820&group_id=191583 |
700 messages has been excluded from this view by a project administrator.
