we know that libuuid and mit conflict; don't syslog it

[geofft]

Although we should deal with renumbering mit or whatever we choose to do (see #299) eventually, that's not going to happen soon. In the meantime, it's kind of useless to keep syslogging

Sep  1 13:54:24 tyger hal-acl-tool: nss_nonlocal: removing local group 101 (libuuid) from non-local user geofft 
Sep  1 13:54:24 tyger last message repeated 4 times
Sep  1 13:54:24 tyger getent: nss_nonlocal: removing local group 101 (libuuid) from non-local user geofft 
Sep  1 13:54:24 tyger hal-acl-tool: nss_nonlocal: removing local group 101 (libuuid) from non-local user geofft 
Sep  1 13:54:26 tyger last message repeated 62 times

etc. since that message doesn't help anyone: users don't care, and the Debathena team isn't taking any additional action because that message continues to appear on everyone's system.

I see three mostly-reasonable courses of action:

1. Special-case libuuid/mit in the logging function
2. Suppress this error entirely -- have we seen it be useful for debugging?
3. Don't print the error more than once per session (although "session" probably poorly defined for an NSS module)

[jdreed]

The right answer is probably to change nss_nonlocal so that these messages are logged with priority DEBUG (or INFO) instead of WARNING.

[jdreed]

People have had 8 months to complain that changing the priority was Wrong, and nobody has.

I think this is the best solution, because the whole point of nss_nonlocal is in fact to separate local entities from non-local entities. So when nss_nonlocal is doing its job (removing a local group from a non-local user), it shouldn't be a WARNING, it should be a DEBUG message. I think most of the other conditions are in fact warnings (such as a group not existing locally, or a nonlocal user being removed from a special local group).

Fixed in r24505.

[jdreed]

We are not the upstream for nss_nonlocal. This has been reported to Anders.