Reset user account back to global mailbox limits

[WTPsyche]

Regarding mailbox limits on Scalix 10...

I have global mailbox limits set at 100 MB (with near limit warning, and over limit notification set, set to send every day). When I add a new user, that user picks up the global quota setting, as expected (as shown with "omscan -A -u -o 2"). If I modify that user to override global limits, the quota change is reflected as expected. However, if I then remove the overriding setting from that particular user, it does not pick up the global limits again, giving that user an unlimited quota. All modifications are being done through the SAC.

How do I get a user account to "pick up" the global settings again?

[Valerion]

You can try (from the command line)

Code: Select all

omlimit -u "User Name" -m 0

(the number, not the letter). According to the omlimit manpage this should reset it to the default, unless a -o is specified as well

Code: Select all

      -m kbytes            Sets  the  message  store size limit in kilobytes.
                           To set no limit, set the value to 0.

       -o                  This option alters  the  effect  of  specifying  a
                           limit  of 0. The -o option with a limit of 0 indi-
                           cates that the specified user should have no limit
                           set, regardless of any global settings.


[/code]

[WTPsyche]

Thanks Valerion, it worked just fine. I appreciate the help. When I read "To set no limit..." I just kept right on looking. I didn't make the connection. I also expected that clearing the users' setting out of the SAC gui should work.

Steve


[quote="Valerion"] You can try (from the command line)

Code: Select all

 omlimit -u "User Name" -m 0

[WTPsyche]

As a followup, not everything is fixed yet. The Mailbox Limits are indeed set correctly for the user with this workaround; however, the global sanctions (u) and (s) are not attached to the user. So, practically speaking, the quota set for the user does nothing.

"omlimit -g -r" gives:

Code: Select all

Name : GLOBAL SETTINGS
Message Store Size Limit     : 100000Kb
Intray Size Limit            : 0Kb
Filing Cabinet Size Limit    : 0Kb
WasteBasket Size Limit       : 0Kb
Pending Tray Size Limit      : 0Kb
Distribution List Area Limit : 0Kb

Omlimit Sanctions Enabled :
        (u)     User receives a message warning of the over limit
        (s)     Messages sent are subject to any delivery rules
                that utilize the OMLIMIT-EXCEEDED message filter attribute

However, "omlimit -u Username -r" for a formerly "overridden" user lists:

Code: Select all

Name : User Name /mail,node/CN=User Name
Message Store Size Limit     : 100000Kb
Intray Size Limit            : 0Kb
Filing Cabinet Size Limit    : 0Kb
WasteBasket Size Limit       : 0Kb
Pending Tray Size Limit      : 0Kb
Distribution List Area Limit : 0Kb

Omlimit Sanctions Enabled :
        (e)     UAL errors are reported to the client when attempting
                to move items to full areas.

Like my problem with the mailbox limits, I can't get the user to pick up the global sanctions. A temporary workaround is either to issue the "omlimit -u Username -e us-e" command, or check both the "Send warning..." and "Send mail to user..." checkboxes on the user's Advanced tab.

Steve

[WTPsyche]

In talking with Florian (Thanks a lot!), he suggested:

Same as with the actual limit, you can also setup negative overrides for the sanctions or set them to just behave like the system wide limit.

Try omlimit -u <lastname> -e -u-e-a-s-r (yes, that is -e <space> -u-e-a-s-r (no spaces in this string!))

That appears to solve the problem. So I imagine my previous workaround could be modified to do everything, as in:
"omlimit -u "User Name" -m 0 -e -u-e-a-s-r"

Steve

[florian]

Steve, thanks for the flowers!

Just a little followup; all the limit settings are stored in system config files, either the system-wide config file general.cfg or the user-specific config file.

If you set any global limit or sanction, you can find some or all of the following lines in /var/opt/scalix/sys/general.cfg

Code: Select all

UAL_SIZE_MSG_TO_USER=TRUE
UAL_SIZE_MSG_TO_ENU=TRUE
UAL_SIZE_ERR_TO_USER=TRUE
UAL_SIZE_ON_SEND=TRUE
UAL_SIZE_ON_RECEIPT=TRUE
UAL_MSTORE_SIZE_LIMIT=300000

if you set them by user, the settings will end up in /var/opt/scalix/sys/user.cfg/<omId> where omId is the internal user Id of the user. This can be determined by the omshowu -G command, as in

Code: Select all

[root@rhel4u2 ~]# omshowu -n sxadmin -G
Authentication ID: sxadmin
User Name : sxadmin /CN=sxadmin
MailNode : scalix,demo
...
Internal user Id : 101
...
User Class : Limited

Now, if a setting appears in both files, the one in the user file takes precedence for this user. The sanction settings can have two values, TRUE or FALSE, so it comes down to the following Matrix:

Code: Select all

general.cfg    user.cfg    Result
-----------------------------------------------------------------------
any setting    NOT SET     general.cfg setting applies
any setting    TRUE        sanction is enabled for the user
any setting    FALSE       sanction is explicitly disabled for the user


So, when you "unset" a sanction for a user you can either set it to false, explicitly disabling the setting for the user independent of the general.cfg setting or you can remove it from user.cfg, thereby returning to the system default set in general.cfg. The very difference between those two possibilities is determined by the "-o" flag in the omlimit command. Specifying -o means that the setting is set to FALSE in user.cfg while not specifying -o means that the user.cfg setting is to be removed. Hence the solution to Steve.

What triggered the problem was the fact that the Scalix Admin Console always seems to have the -o option when executing the omlimit command to remove the sanction, therefore it sets the user.cfg flag to false.

It should actually offer both - disabling the sanction or returning to the system setting; obviously it's not binary logic which is what the checkbox currently implies.

I've filed a bug against this behaviour and we'll see if we can improve this in a future release.

Hope this helps,
Florian.

P.S. By the way, I agree this again shows the complex nature of the beast and I hope not too many readers are scared away by this. For me, the good thing is that it's very powerful, can do a lot of what we like to do at times, is pretty well documented (most of the above is contained in various man pages and guides) and for day2day operations the Scalix Admin console provides a good and robust frontend! :-)