Hide Forgot
Description of problem: After deploying a new server, I noticed that our user account uid/gid's were one off - for example: cxc028:x:500:501::/home/cxc028:/bin/bash rjm002:x:501:502::/home/rjm002:/bin/bash nwl002:x:502:503::/home/nwl002:/bin/bash looking in /etc/group gave me my answer: cgred:x:500: Is there a reason this system group wasn't added with the -r flag? The libcgroup rpm runs: [14:41:42][root@LnxBBColl01d][/root]-> rpm -q --scripts libcgroup preinstall scriptlet (using /bin/sh): getent group cgred >/dev/null || groupadd cgred Version-Release number of selected component (if applicable): libcgroup-0.37-2.el6.x86_64 How reproducible: Always Steps to Reproduce: 1. Install libcgroup 2. getent group cgred Actual results: cgred:x:500: Expected results: cgred:x:499: Additional info:
Correction - Expected results should be cgred:x:498: since cyrus-sasl installed with getent group saslauth >/dev/null || groupadd -r saslauth
Agreed. This isn't a huge thing, but it's definitely an annoyance and should be resolved. It also changes the expected user/group relationship so folks may get some unexpected behavior from certain tools.
*** Bug 719226 has been marked as a duplicate of this bug. ***
I just ran into this myself, except cgred stole group 1010 which conflicts with one of my users, and made my puppet manifest crash and burn. Even worse, I think this is getting installed by puppet as some dependency, so it's a somewhat random race condition whether things work right or not. The groupadd command in this RPM should definitely use the -r option.
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Prior to this update, when installing the libcgroup package, a new group "cgred" was erroneously created as a user group (starting with GID 500) and not as a system group (with GID lower than 500). As a result, newly created users could have had UID different to GID. With this update, the "cgred" group is now created correctly as the system group with GID lower than 500. This update does not change GID of the "cgred" group if the group already exists on the system.
tested by removing the libcgroup from RHEL 6.1 and installing 0.37-3.el6 in its place. If the cgred group already exists with gid 500 it is left alone. Removed libcgroup package again and deleted the cgred group. When reinstalling libcgroup I got a cgred group with gid 495 which was the next available gid < 500 so this bug can be verified.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1225.html
Here it is November and libcgroup-0.37-2.el6.x86_64 is still all that's available for RHEL 6. Since it appears that 0.37-3.el6 will never get released to the public, could we get a workaround for this annoyance? That is, what files will need chgrp after we do something like groupmod -g 495 cgred ?
I can see the errata was issued on 2011-08-31 and it was a public one. I dunno why you don't see it. Please contact your Red Hat support. (In reply to comment #15) > That is, what files will need chgrp after we do something like > groupmod -g 495 cgred Only /bin/cgexec. /var/run/cgred.socket should be owned by cgred too, but it's dynamically created (and chown-ed) by cgred service.
Hi Fred, I see the errata was posted, but the package is for some reason not available for download on RHN. I've contacted our release engineering team to resolve this, and will post an update to this BZ once the package is available on RHN. In the interim, Jan has posted the instructions you were looking for. I would also like to offer the source RPM for libcgroup-0.37-3 here: ftp://ftp.redhat.com/pub/redhat/linux/enterprise/6Server/en/os/SRPMS/libcgroup-0.37-3.el6.src.rpm
Thanks Jan and Jeremy. I noticed that the sgid bit turned off when I changed the group for /bin/cgexec, so in case anyone else does this you need groupmod -g 495 cgred chgrp cgred /bin/cgexec chmod g+s /bin/cgexec
Hi Fred, This errata was there all along, pushed out through the FasTrack channel: https://rhn.redhat.com/rhn/software/packages/details/Overview.do?pid=642971 FasTrack provides a means by which errata can be pushed ahead of the next minor release. You can add "RHEL Server FasTrack" to your system's channel entitlements on RHN, then use yum (I just tested this OK), or download the RPM directly from the link above. As a note, an updated libcgroup (libcgroup-0.37-3 is in the beta) will ship in the regular RHEL6.2 channel once that's released.