Courier+maildrop are not updating maildirsize

Discussion in 'Developers' Forum' started by quentusrex, Oct 30, 2008.

  1. quentusrex

    quentusrex New Member

    It seems that the file /home/vmail/domain/user/maildirsize is not being updated with the new quota size when the quota is changed by ISPConfig. The hack that seems to fix it is to run the commands:

    maildirmake -q {quota}S /home/vmail/domain/user/
    chown vmail:vmail /home/vmail/domain/user/maildirsize

    right after the quota is changed. I don't know where to add this hack to ISPConfig to fix the bug, if this is even the right hack to do it.
     
  2. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    Courier and maildrop are configured to read the maildir size directly from the mysql database in the file /etc/courier/authmysqlrc
     
  3. quentusrex

    quentusrex New Member

    It is configured to read it when creating the maildir the first time, but it seems to ignore the database after the user is created. I could be wrong, but so far all my tests show that it only looks to the database during initial creation, then ignores the database afterthat(atleast when it comes to quota). But if you manually tell it to recalculate the maildirsize file then it accurately handles changes in mail dir sizes.
     
  4. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    Ok, then we should add this in the user_update function in the plugin file /usr/local/ispconfig/server/plugins-available/mail_plugin.inc.php

    Maybe we find later a reason why maildrop is not recognizing it in the db.
     
  5. quentusrex

    quentusrex New Member

    Till, you or me?

    I think if I program it I think the code will still need to be cleaned up, but I think I can make it 'work' quickly.

    Do you know where I can find an example plugin that executes a command on the command line? Should exec() be used? or avoided?
     
  6. quentusrex

    quentusrex New Member

    Ok, never mind. Found it, and a sample.


    exec('mkdir -p '.escapeshellcmd($data['new']['maildir']));
    exec('chown '.$mail_config['mailuser_name'].':'.$mail_config['mailuser_group'].' '.escapeshellcmd($data['new']['maildir']));
     
  7. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    It is fine to use exec, we dont have a wrapper function for exec (at least yet).
     
  8. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    I will try to fix some of the bugs that are in the bugtracker over the weekend.
     
  9. quentusrex

    quentusrex New Member

    I'll see if I can get this bug atleast started. I might be able to make it work.

    Till, of the bugs I've seen I would say the one I would need help tracking down in the mail quota size. It's an int overflow bug. It could be a security concern. I don't know if the over flow is in the AJAX side of things, or in the php processing side.
     
  10. quentusrex

    quentusrex New Member

    Till, also there seems to be no way to change the log level.
     
  11. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    The Loglevel is set in the ISPConfig configuration file:

    /usr/local/ispconfig/server/lib/config.inc.php

    I changed it there and it worked on my setup.
     
  12. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    I guess its a database problem, it should be solved if we set the database field from int to "bigint unsigned" as we do not need negative values there as courier recognizs 0 as unlimited.
     
  13. quentusrex

    quentusrex New Member

    Alright, I've fixed this bug. it has a bit of a delay. Either that or it waits for something.
     
  14. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    The update scripts are run as cronjob because they need root priveliges, so it takes up to 1 minute until they get executed.
     
  15. quentusrex

    quentusrex New Member

    It's not a database problem. I changed the database structure on my test install to a mysql int(30) from an int(11) and it didn't fix the problem.

    I think it's in the AJAX interface, or the php handling of the AJAX int. Where does the value get converted from MB's to bytes? I think that could be where the bug is located.
     
  16. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    It is converted in PHP. The file is interface/web/mail/mail_user_edit.php if I remember correctly.
     
  17. quentusrex

    quentusrex New Member

    Do you think it would be under

    Submit, Insert, or update?
     
  18. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    Most likely line 178 under submit:

    // Convert quota from MB to Bytes
    $this->dataRecord["quota"] = $this->dataRecord["quota"] * 1024 * 1024;

    But as far as I know, there is no limit in PHP which might cause problems with big integer numbers *confused*
     
  19. quentusrex

    quentusrex New Member

    I've tracked down that it isn't failing there. It's failing in relation to interface/web/mail/form/mail_user.tform.php

    I think it's bugging out around line 91. Somewhere in the int check.
     
  20. till

    till Super Moderator Howtoforge Staff HowtoForge Supporter ISPConfig Developer

    Then the problem is maybe in interface/lib/classes/tform.inc.php line 619:

    $tmpval = intval($field_value);

    The complete conversion of values and the generation of the sql for inserts and updates is in this library.
     

Share This Page