| Summary: | kolab in updates_testing since 2011-08-02 | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Samuel Verschelde <stormi-mageia> |
| Component: | RPM Packages | Assignee: | QA Team <qa-bugs> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins, qa-bugs, thomas, tmb |
| Version: | 1 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | kolab-2.2.4-5.2.mga1.src.rpm | CVE: | |
| Status comment: | |||
|
Description
Samuel Verschelde
2012-08-26 14:55:03 CEST
This packages fixes that quota warnings will work (user get warned when they reach or succeed their assigned max mailbox size). I have tested the package. There should be a bug report, but I am not able to find it either. The package can be tests by assigning a relatively low quote to a user and send them e-mails with large attachments that will use up their quota.Then apply the change and do the same. The warning should disappear. Status:
NEW =>
ASSIGNED I'll be testing this one shortly. CC:
(none) =>
davidwhodgins Before installing the update, connecting to the imap server with the account over quota (using opera), I get an error message ... dave@i1v.hodgins.homeip.net The IMAP server reported an error. Mailbox is over quota I can access the messages, and delete them. Now I'll install the update, and see if anything changes. Exactly the same result after the update. What's actually changed? Whiteboard:
(none) =>
feedback David, I apologize. As you said, this has been sitting around for much too long. I changed the permission from 744 to 644. this file should not be executable and there is no need to be executable. If you mean error message = over quote and all else is OK then you passed the test. I use mozilla-thunderbird for testing (In reply to comment #4) > David, I apologize. As you said, this has been sitting around for much too > long. > I changed the permission from 744 to 644. this file should not be executable > and there is no need to be executable. Ah. Ok I see the change, /etc/cron.d/kolabquotawarn is no longer executable, which prevented the script from being run, with an error in syslog ... crond[1674]: (CRON) bad command (/etc/cron.d/kolabquotawarn) $ cat /etc/cron.d/kolabquotawarn */10 * * * * /usr/share/kolab/scripts/kolabquotawarn But, that script is still not going to run. $ cat /usr/share/kolab/scripts/kolabquotawarn cat: /usr/share/kolab/scripts/kolabquotawarn: No such file or directory The perl script is in /usr/bin/kolabquotawarn. > If you mean error message = over quote and all else is OK then you passed the > test. > I use mozilla-thunderbird for testing I'm getting the error when I connect to the imap server, with either version. Looking at the /usr/bin/kolabquotawarn script, it's going to repeatedly send a message to the user, telling them they are over quota, and keep doing that till the file system becomes full. I don't thing using a mail message to tell a user they have too many mail messages is a very good idea. :-) As it is, this fix changes the error message generated by cron, from the bad command message, to a command not found message. I think a better fix would be to just delete the /etc/cron.d/kolabquotawarn file. This is a security update. I have been using this since Mandriva 2011. This file is in upstreams and supposedly in large deployments. You shouldn't see any errors, just a message that the quota has been exceeded. I haven't seen any bugs reporting a problem with logs How is this a security update. Are there changes other then the permissions on the cron file? As per comment 5, the change of the permissions only stops cron from generating a message about a bad command, only to replace it with an error about a command not found, every time the script tries to run, which will happen much more often then restarting of cron. Unless there are other changes not covered in comment 4, I see no point in pushing this update. It will generate more error messages (in emails from crond), while only getting rid of one line in syslog each time cron starts. $ rpmdiff -iT kolab-2.2.4-5.mga1.i586.rpm kolab-2.2.4-5.2.mga1.i586.rpm S.5..... PREIN removed PROVIDES kolab(x86-32) = 2.2.4-5.mga1 added PROVIDES kolab(x86-32) = 2.2.4-5.2.mga1 .M......... /etc/cron.d/kolabquotawarn Assigning Thomas. Please reassign to QA when you've had a chance to look at this. Thanks! CC:
(none) =>
qa-bugs See also Samuel's comment 0 if you decide it should be removed. Thanks. Please push to update. Assignee:
thomas =>
qa-bugs Thomas we are still waiting for a response to comment 7 please. If this change generates more errors than it cures then it is not really suitable to push as an update.
claire robinson
2012-09-14 10:14:24 CEST
Whiteboard:
(none) =>
feedback I went back to a mga1 initial installation. I limited the quota for user xxx to 1 MB and sent emails (using thunderbird) with a 400+kb attachment from user yyy to user xxx. After the second e-mail, user yyy got the message that the inbox exceeds the 80% quota. I continued to resend the same e-mail and ofter reaching the 100% quote, xxx received the message the inbox exceeded the 100% quota and the quota window turned red. I continued to resend the same e-mail from user yyy to user xxx and when it exceeded 120% the message was rejected and user yyy got an e-mail with a long error message. I then reverted to the previous installation state and upgraded kolab from upgrade testing and repeated that same procedure and got exactly the same results with the same length of error message. The bottom line is: there is no regression by pushing the update. The update solves a security issue, kolabquotawarn in /etc/con.d should not be executable. So let's push this and lay it to rest.
claire robinson
2012-09-16 09:40:25 CEST
Whiteboard:
feedback =>
(none) Given that this has been left updates testing for well over a year Thomas please don't push that this is a security update which must now be rushed through QA.. Dave has identified a valid bug, regression or not. /etc/cron.d/kolabquotawarn - which is the the only file being touched by this update - points to a non existent script - /usr/share/kolab/scripts/kolabquotawarn There is a script from perl-kolab in /usr/bin/kolabquotawarn We _could_ of course create a new bug for that, but it seems to be at the extremes of reason to do so in these circumstances. Just to be absolutely clear.. are you saying that the best way to handle this, after 13 months of sitting in testing, is that you'd now like us to push this update with the bug which has been identified and to create a new bug for it? If so, then that is what we will do. (In reply to comment #14) > Given that this has been left updates testing for well over a year Thomas > please don't push that this is a security update which must now be rushed > through QA.. > > Dave has identified a valid bug, regression or not. > I agree with Claire... Since it's been in testing for ages, it definately has not been considered an important security fix by maintainer, so no point in trying to rush it now... Please fix the bug properly, and lets push out a really workning update.... CC:
(none) =>
tmb the location of the script kolabquotawarn is now fixed. We still have errors in case someones sends an e-mail to somebody whose quota is exceeded. I am not going to fix that part because: Those scripts (horde-kolab) have a lot of dependencies and they are not maintained upstreams anymore for kolab. We have no error report for this type of errors, because it's probably never triggered. The default installation has no mailbox quota set and therefor the error never (hardly ever) shows up. I have used this package (kolab) for at least four years in production and never had this error. Mageia 1 changed to end-of-life (EOL) status on ''1st December''. Mageia 1 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- Mageia Bugsquad Status:
ASSIGNED =>
RESOLVED |