We have an (old and grown) infrastructure of linux machines (mostly debian). For user authentication we use LDAP where we have defined several groups with different access rights. Unluckily one of these groups is called staff which has become a standard group name in debian. The consequences are that whenever a package is updated that has something to do with groups (e.g., passwd) it creates a local group staff on the machine that eclipses the LDAP staff group. The consequences are that logins no longer work, etc.

Since the infrastructure is not new, it would be very laborious to change the group name, since it appears in various config files on different machines.

The question is: how to disable the local group file (forever)? Or is there any other workaround?

Currently we have to delete the local staff group manually from /etc/groups after each update that creates it.

What has been tried without success:

  • Changing the order in the nsswitch.conf from group: files ldap to group: ldap files --> Effect: system hangs at boot.
  • The system probably hangs because its waiting for network. – ztron Dec 5 '14 at 20:48
  • If you have a Debian box on the network and on LDAP and you do a groupadd staff what happens? It is supposed to fail if the group already exists in LDAP. If that is working then you are having these groups added when the box is not on the network. – chicks Dec 7 '14 at 18:12
  • groupadd staff fails as expected with groupadd: group 'staff' already exists. The group was added during the upgrade process. Maybe the upgrade does not use groupadd (which would be a bug) or networking gets somehow stopped during upgrade. – masgo Dec 9 '14 at 8:57
  • btw: I could not find an acceptable workaround .. in the end we had to change the name of our 'staff' group. What worked in our favor was the fact that it did not appear in that many config files. But we ran a fulltext search on /etc and /var - just to be sure we did not miss anything. – masgo Jul 20 '15 at 13:37

How to disable the local group file (forever)?

This is not a Good Idea(tm). Attempts to do this would be very "impactful"

Or is there any other workaround? You mention the following, which sounds like this occurs whenever the servers are patched and rebooted. "...whenever a package is updated that has something to do with groups..."

One "least impactful" solution would be to create a custom init script to remove the staff group from /etc/group when the system changed run-levels (exactly which ones depends on what's in the procedure you use to patch the servers)

See the Debian documentation on their init-scripts for details.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.