From dsavage at peaknet.net Thu Dec 1 03:13:00 2011 From: dsavage at peaknet.net (dsavage at peaknet.net) Date: Wed, 30 Nov 2011 21:13:00 -0600 (CST) Subject: [rhelv6-list] setuid helper permission??? Message-ID: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> A critical typo in a revised script totally trashed all permissions on my RHEL6.1 server. Fortunately even in that damaged state it booted to runlevel 1. It's taken me two weeks to reinstall all 2471 packages, restore permissions IAW the RPM database plus the thousands that aren't recorded there. I can now boot to runlevel 3 just fine. Runlevel 5, however, seems just out of reach. It boots to the graphical logon screen, but that's where keyboard and mouse operations quit. Everything in the messages log looks nominal right up to these five lines: Nov 28 20:14:31 lion gdm-simple-slave[3019]: WARNING: Unable to open session: The permission of the setuid helper is not correct Nov 28 20:14:32 lion gnome-session[3042]: devkit-power-gobject-Warning: Couldn't enumerate devices: The permission of the setuid helper is not correct Nov 28 20:14:36 lion gdm-simple-greeter[3064]: devkit-power-gobject-WARNING: Couldn't enumerate devices: The permission of the setuid helper is not correct Nov 28 20:14:36 lion gdm-simple-greeter[3064]: devkit-power-gobject-WARNING: Error involving GetAll() to get properties. The permission of the setuid helper is not correct Nov 28 20:14:36 lion gdm-simple-greeter[3064]: Gtk-WARNING gtkwidget.c5460: widget not within a GtkWindow Five more lines follow, but I doubt these affect the keyboard and mouse: Nov 28 20:14:36 lion pulseaudio[3087]: module-console-kit.c: GetSessionsForUnixUser() call failed: org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of the setuid helper is not correct Nov 28 20:14:36 lion pulseaudio[3087]: module.c: failed to load module "module-console-kit" (argument: ""): initialization failed. Nov 28 20:14:36 lion pulseaudio[3087]: main.c: Module load failed. Nov 28 20:14:36 lion pulseaudio[3087]: main.c: Failed to initialize daemon. Nov 28 20:14:36 lion pulseaudio[3087]: main.c: Daemon startup failed. I presume the "setuid helper" is /usr/bin/sudo: ---s--x--x. 2 root root 212904 Aug 18 05:37 sudo ---s--x--x. 2 root root 212904 Aug 18 05:37 sudoedit ---x--x--x. 1 root root 43120 Aug 18 05:37 sudoreplay I'm sure I've missed something simple, but what??? --Doc Savage Fairview Heights, IL From lists at brimer.org Thu Dec 1 05:12:09 2011 From: lists at brimer.org (Barry Brimer) Date: Wed, 30 Nov 2011 23:12:09 -0600 (CST) Subject: [rhelv6-list] setuid helper permission??? In-Reply-To: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> Message-ID: > A critical typo in a revised script totally trashed all permissions on my > RHEL6.1 server. Fortunately even in that damaged state it booted to > runlevel 1. It's taken me two weeks to reinstall all 2471 packages, > restore permissions IAW the RPM database plus the thousands that aren't > recorded there. I can now boot to runlevel 3 just fine. Runlevel 5, > however, seems just out of reach. It boots to the graphical logon screen, > but that's where keyboard and mouse operations quit. Have you tried using rpm --setperms ?? If it is insisting on setuid you could use find to locate all the setuid binaries and examine the permissions of those that seem relevant to your issue. Of course having a clean working install to compare these perms to would also help! Barry From hbrown at divms.uiowa.edu Thu Dec 1 15:10:42 2011 From: hbrown at divms.uiowa.edu (Hugh Brown) Date: Thu, 01 Dec 2011 09:10:42 -0600 Subject: [rhelv6-list] setuid helper permission??? In-Reply-To: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> Message-ID: <4ED798F2.6030804@divms.uiowa.edu> On 11/30/2011 09:13 PM, dsavage at peaknet.net wrote: > A critical typo in a revised script totally trashed all permissions on my > RHEL6.1 server. Fortunately even in that damaged state it booted to > runlevel 1. It's taken me two weeks to reinstall all 2471 packages, > restore permissions IAW the RPM database plus the thousands that aren't > recorded there. I can now boot to runlevel 3 just fine. Runlevel 5, > however, seems just out of reach. It boots to the graphical logon screen, > but that's where keyboard and mouse operations quit. > > Everything in the messages log looks nominal right up to these five lines: > > Nov 28 20:14:31 lion gdm-simple-slave[3019]: WARNING: Unable to open > session: The permission of the setuid helper is not correct > Nov 28 20:14:32 lion gnome-session[3042]: devkit-power-gobject-Warning: > Couldn't enumerate devices: The permission of the setuid helper is not > correct > Nov 28 20:14:36 lion gdm-simple-greeter[3064]: > devkit-power-gobject-WARNING: Couldn't enumerate devices: The > permission of the setuid helper is not correct > Nov 28 20:14:36 lion gdm-simple-greeter[3064]: > devkit-power-gobject-WARNING: Error involving GetAll() to get > properties. The permission of the setuid helper is not correct > Nov 28 20:14:36 lion gdm-simple-greeter[3064]: Gtk-WARNING > gtkwidget.c5460: widget not within a GtkWindow > > Five more lines follow, but I doubt these affect the keyboard and mouse: > Nov 28 20:14:36 lion pulseaudio[3087]: module-console-kit.c: > GetSessionsForUnixUser() call failed: > org.freedesktop.DBus.Error.Spawn.PermissionsInvalid: The permission of > the setuid helper is not correct > Nov 28 20:14:36 lion pulseaudio[3087]: module.c: failed to load module > "module-console-kit" (argument: ""): initialization failed. > Nov 28 20:14:36 lion pulseaudio[3087]: main.c: Module load failed. > Nov 28 20:14:36 lion pulseaudio[3087]: main.c: Failed to initialize > daemon. > Nov 28 20:14:36 lion pulseaudio[3087]: main.c: Daemon startup failed. > > I presume the "setuid helper" is /usr/bin/sudo: > > ---s--x--x. 2 root root 212904 Aug 18 05:37 sudo > ---s--x--x. 2 root root 212904 Aug 18 05:37 sudoedit > ---x--x--x. 1 root root 43120 Aug 18 05:37 sudoreplay > > I'm sure I've missed something simple, but what??? > > --Doc Savage > Fairview Heights, IL > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list A quick google suggests it might be dbus that is the helper. ls -l /lib64/dbus-1/dbus-daemon-launch-helper -rwsr-x---. 1 root dbus 45592 Jul 27 16:53 /lib64/dbus-1/dbus-daemon-launch-helper It's part of the dbus package. Hugh From timc at cs.wisc.edu Thu Dec 1 16:45:54 2011 From: timc at cs.wisc.edu (Tim Czerwonka) Date: Thu, 01 Dec 2011 10:45:54 -0600 Subject: [rhelv6-list] using buildinstall on rhel6 Message-ID: <201112011645.pB1GjslP025877@tornado.cs.wisc.edu> Can anyone report success using /usr/lib/anaconda-runtime/buildinstall to generate updated install media on rhel6? I'm looking for an updated initrd suitable for booting via pxe. The images/pxeboot/vmlinuz,initrd.img from the 6.1 CD work fine but I'd prefer to start with a newer kernel and modules than 2.6.32-131.0.15. We've used buildinstall extensively in RHEL5 for the same purpose. The options for buildinstall appear to have changed in RHEL6 -- no problem -- but I can't seem to generate an environment or command line options that lead to success. Example: [root at tornado fail]# /usr/lib/anaconda-runtime/buildinstall --version 6.1 --product "CSL foo Linux" --release "csl rhel 6 dot 1" /scratch/extracted/ 2>&1 | tee buildinstall-fail1.txt gives output: http://www.cs.wisc.edu/~timc/buildinstall-fail1.txt I've also experimented using dracut to generate a initrd suitable for pxe but get an initrd that when extracted is remarkably different than the RHEL- supplied pxeboot initrd -- and it doesn't work either. Any insight or links to relevant documentation are appreciated. best-- --Tim Tim Czerwonka, timc at cs.wisc.edu From jas at cse.yorku.ca Thu Dec 1 18:08:12 2011 From: jas at cse.yorku.ca (Jason Keltz) Date: Thu, 01 Dec 2011 13:08:12 -0500 Subject: [rhelv6-list] maximum member unix group in /etc/group In-Reply-To: References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> Message-ID: <4ED7C28C.2090009@cse.yorku.ca> Under RHEL4, as far as I can see, there was no limitation in unix group size in /etc/group in terms of line lengths or number of users, or at least I never came close to hitting the limit. Under RHEL6.1, I hit the limit today - 126 members. It's not clear if this is a bug or a feature, or why such a limitation would be imposed. It's possible that it was imposed by a patch, but after applying many patches, it's not clear which would have caused it. Any ideas??? Jason. From Iain.Morrison at mrc-epid.cam.ac.uk Thu Dec 1 19:17:47 2011 From: Iain.Morrison at mrc-epid.cam.ac.uk (Iain Morrison) Date: Thu, 1 Dec 2011 19:17:47 -0000 Subject: [rhelv6-list] maximum member unix group in /etc/group In-Reply-To: <4ED7C28C.2090009@cse.yorku.ca> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> <4ED7C28C.2090009@cse.yorku.ca> Message-ID: <7F2C60CEE8B98346BD9FBAE010150522323E9A@silicon.mrc-epid.cam.ac.uk> Hi Jason, we had this problem with groups in NIS under RHEL4, and whilst it may be a bug in RHEL 6.1 the workaround we use might work for you. [The length of one entry is limited by the NIS protocol to 1024 characters.] ------------------- There is another way of solving this problem for /etc/group entries. This idea is from Ken Cameron: 1. Break the entry into more than one line and name each group slightly differently. 2. Keep the GID the same for all. 3. Have the first entry with the right group name and the GID. I don't put any user names in this one. What happens is that going by user name you pick up the GID when the code reads it. Then going the other way it stops after the first match of GID and takes that name. It's ugly but works! ------------------------ so for example we have largegroup:x:1234: largegroup1:x:1234:uname01,uname02,... largegroup2:x:1234:uname31,uname31,... largegroup3:x:1234:uname61,uname61,... largegroup4:x:1234: largegroup5:x:1234: thanks iain -- Iain Morrison IT Manager MRC Epidemiology Unit Institute of Metabolic Science Box 285 Addenbrooke's Hospital Hills Road Cambridge CB2 0QQ Tel 01223 769200 -----Original Message----- From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Jason Keltz Sent: 01 December 2011 18:08 To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list Subject: [rhelv6-list] maximum member unix group in /etc/group Under RHEL4, as far as I can see, there was no limitation in unix group size in /etc/group in terms of line lengths or number of users, or at least I never came close to hitting the limit. Under RHEL6.1, I hit the limit today - 126 members. It's not clear if this is a bug or a feature, or why such a limitation would be imposed. It's possible that it was imposed by a patch, but after applying many patches, it's not clear which would have caused it. Any ideas??? Jason. _______________________________________________ rhelv6-list mailing list rhelv6-list at redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-list From paul.krizak at amd.com Thu Dec 1 19:26:43 2011 From: paul.krizak at amd.com (Paul Krizak) Date: Thu, 1 Dec 2011 11:26:43 -0800 Subject: [rhelv6-list] maximum member unix group in /etc/group In-Reply-To: <7F2C60CEE8B98346BD9FBAE010150522323E9A@silicon.mrc-epid.cam.ac.uk> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> <4ED7C28C.2090009@cse.yorku.ca> <7F2C60CEE8B98346BD9FBAE010150522323E9A@silicon.mrc-epid.cam.ac.uk> Message-ID: <4ED7D4F3.3020100@amd.com> Yeah this is SOP for NIS-based orgs with large groups. I wouldn't even call it a hack at this point, it's been in use so long. Paul Krizak 7171 Southwest Pkwy MS B200.3A MTS Systems Engineer Austin, TX 78735 Advanced Micro Devices Desk: (512) 602-8775 Linux/Unix Systems Engineering Cell: (512) 791-0686 Global IT Infrastructure Fax: (512) 602-0468 On 12/01/11 11:17, Iain Morrison wrote: > Hi Jason, > we had this problem with groups in NIS under RHEL4, and whilst it may > be a bug in RHEL 6.1 the workaround we use might work for you. > > [The length of one entry is limited by the NIS protocol to 1024 > characters.] > > > ------------------- > > There is another way of solving this problem for /etc/group entries. > This idea is from Ken Cameron: > > 1. Break the entry into more than one line and name each group > slightly differently. > > 2. Keep the GID the same for all. > > 3. Have the first entry with the right group name and the GID. > I don't put any user names in this one. > > What happens is that going by user name you pick up the GID when the > code > reads it. Then going the other way it stops after the first match of GID > and takes that name. It's ugly but works! > > ------------------------ > > so for example we have > > largegroup:x:1234: > largegroup1:x:1234:uname01,uname02,... > largegroup2:x:1234:uname31,uname31,... > largegroup3:x:1234:uname61,uname61,... > largegroup4:x:1234: > largegroup5:x:1234: > > thanks > > iain > > > -- > > Iain Morrison > IT Manager > MRC Epidemiology Unit > Institute of Metabolic Science > Box 285 > Addenbrooke's Hospital > Hills Road > Cambridge > CB2 0QQ > Tel 01223 769200 > > -----Original Message----- > From: rhelv6-list-bounces at redhat.com > [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Jason Keltz > Sent: 01 December 2011 18:08 > To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list > Subject: [rhelv6-list] maximum member unix group in /etc/group > > Under RHEL4, as far as I can see, there was no limitation in unix group > size in /etc/group in terms of line lengths or number of users, or at > least I never came close to hitting the limit. Under RHEL6.1, I hit the > > limit today - 126 members. It's not clear if this is a bug or a > feature, or why such a limitation would be imposed. It's possible that > it was imposed by a patch, but after applying many patches, it's not > clear which would have caused it. Any ideas??? > > Jason. > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > From paul.krizak at amd.com Thu Dec 1 19:32:40 2011 From: paul.krizak at amd.com (Paul Krizak) Date: Thu, 1 Dec 2011 11:32:40 -0800 Subject: [rhelv6-list] maximum member unix group in /etc/group In-Reply-To: <4ED7D4F3.3020100@amd.com> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> <4ED7C28C.2090009@cse.yorku.ca> <7F2C60CEE8B98346BD9FBAE010150522323E9A@silicon.mrc-epid.cam.ac.uk> <4ED7D4F3.3020100@amd.com> Message-ID: <4ED7D658.40605@amd.com> I should also note that nscd (at least under RHEL4, not sure about 5,6) has the 1024-char limit too for group entries. nscd on RHEL4 will sporadically return bad data (ex. missing groups) if the group entries are > 1024 chars long. Paul Krizak 7171 Southwest Pkwy MS B200.3A MTS Systems Engineer Austin, TX 78735 Advanced Micro Devices Desk: (512) 602-8775 Linux/Unix Systems Engineering Cell: (512) 791-0686 Global IT Infrastructure Fax: (512) 602-0468 On 12/01/11 11:26, Paul Krizak wrote: > Yeah this is SOP for NIS-based orgs with large groups. I wouldn't even > call it a hack at this point, it's been in use so long. > > > Paul Krizak 7171 Southwest Pkwy MS B200.3A > MTS Systems Engineer Austin, TX 78735 > Advanced Micro Devices Desk: (512) 602-8775 > Linux/Unix Systems Engineering Cell: (512) 791-0686 > Global IT Infrastructure Fax: (512) 602-0468 > > On 12/01/11 11:17, Iain Morrison wrote: >> Hi Jason, >> we had this problem with groups in NIS under RHEL4, and whilst it may >> be a bug in RHEL 6.1 the workaround we use might work for you. >> >> [The length of one entry is limited by the NIS protocol to 1024 >> characters.] >> >> >> ------------------- >> >> There is another way of solving this problem for /etc/group entries. >> This idea is from Ken Cameron: >> >> 1. Break the entry into more than one line and name each group >> slightly differently. >> >> 2. Keep the GID the same for all. >> >> 3. Have the first entry with the right group name and the GID. >> I don't put any user names in this one. >> >> What happens is that going by user name you pick up the GID when the >> code >> reads it. Then going the other way it stops after the first match of GID >> and takes that name. It's ugly but works! >> >> ------------------------ >> >> so for example we have >> >> largegroup:x:1234: >> largegroup1:x:1234:uname01,uname02,... >> largegroup2:x:1234:uname31,uname31,... >> largegroup3:x:1234:uname61,uname61,... >> largegroup4:x:1234: >> largegroup5:x:1234: >> >> thanks >> >> iain >> >> >> -- >> >> Iain Morrison >> IT Manager >> MRC Epidemiology Unit >> Institute of Metabolic Science >> Box 285 >> Addenbrooke's Hospital >> Hills Road >> Cambridge >> CB2 0QQ >> Tel 01223 769200 >> >> -----Original Message----- >> From: rhelv6-list-bounces at redhat.com >> [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Jason Keltz >> Sent: 01 December 2011 18:08 >> To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list >> Subject: [rhelv6-list] maximum member unix group in /etc/group >> >> Under RHEL4, as far as I can see, there was no limitation in unix group >> size in /etc/group in terms of line lengths or number of users, or at >> least I never came close to hitting the limit. Under RHEL6.1, I hit the >> >> limit today - 126 members. It's not clear if this is a bug or a >> feature, or why such a limitation would be imposed. It's possible that >> it was imposed by a patch, but after applying many patches, it's not >> clear which would have caused it. Any ideas??? >> >> Jason. >> >> _______________________________________________ >> rhelv6-list mailing list >> rhelv6-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhelv6-list >> >> _______________________________________________ >> rhelv6-list mailing list >> rhelv6-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhelv6-list >> > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > From jas at cse.yorku.ca Thu Dec 1 20:28:37 2011 From: jas at cse.yorku.ca (Jason Keltz) Date: Thu, 01 Dec 2011 15:28:37 -0500 Subject: [rhelv6-list] maximum member unix group in /etc/group In-Reply-To: <7F2C60CEE8B98346BD9FBAE010150522323E9A@silicon.mrc-epid.cam.ac.uk> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> <4ED7C28C.2090009@cse.yorku.ca> <7F2C60CEE8B98346BD9FBAE010150522323E9A@silicon.mrc-epid.cam.ac.uk> Message-ID: <4ED7E375.1070607@cse.yorku.ca> Hi Ian, Thanks for the workaround... While I'm not using NIS, I can say this with certainty: 1) Installed glibc-2.12-1.7.el6.x86_64 (original RHEL6 glibc), and it worked with all of my groups. 2) installed glibc-2.12-1.25.el6_1.3/x86_64 and it did not ... revert system with glibc-2.12-1.25.el6_1.3/x86_64 to glibc-2.12-1.7.el6.x86_64 and it works... HMMM.. seems like a bug to me .. which I will report .. but most of the times I report stuff, it doesn't end up getting fixed anyway. At least I have your fix in the meantime.. Thanks! Jason. On 12/01/2011 02:17 PM, Iain Morrison wrote: > Hi Jason, > we had this problem with groups in NIS under RHEL4, and whilst it may > be a bug in RHEL 6.1 the workaround we use might work for you. > > [The length of one entry is limited by the NIS protocol to 1024 > characters.] > > > ------------------- > > There is another way of solving this problem for /etc/group entries. > This idea is from Ken Cameron: > > 1. Break the entry into more than one line and name each group > slightly differently. > > 2. Keep the GID the same for all. > > 3. Have the first entry with the right group name and the GID. > I don't put any user names in this one. > > What happens is that going by user name you pick up the GID when the > code > reads it. Then going the other way it stops after the first match of GID > and takes that name. It's ugly but works! > > ------------------------ > > so for example we have > > largegroup:x:1234: > largegroup1:x:1234:uname01,uname02,... > largegroup2:x:1234:uname31,uname31,... > largegroup3:x:1234:uname61,uname61,... > largegroup4:x:1234: > largegroup5:x:1234: > > thanks > > iain > > > -- > > Iain Morrison > IT Manager > MRC Epidemiology Unit > Institute of Metabolic Science > Box 285 > Addenbrooke's Hospital > Hills Road > Cambridge > CB2 0QQ > Tel 01223 769200 > > -----Original Message----- > From: rhelv6-list-bounces at redhat.com > [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Jason Keltz > Sent: 01 December 2011 18:08 > To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list > Subject: [rhelv6-list] maximum member unix group in /etc/group > > Under RHEL4, as far as I can see, there was no limitation in unix group > size in /etc/group in terms of line lengths or number of users, or at > least I never came close to hitting the limit. Under RHEL6.1, I hit the > > limit today - 126 members. It's not clear if this is a bug or a > feature, or why such a limitation would be imposed. It's possible that > it was imposed by a patch, but after applying many patches, it's not > clear which would have caused it. Any ideas??? > > Jason. > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -- Jason Keltz Manager of Development Department of Computer Science and Engineering York University, Toronto, Canada Tel: 416-736-2100 x. 33570 Fax: 416-736-5872 From thomas.molina at ngc.com Fri Dec 2 11:33:16 2011 From: thomas.molina at ngc.com (Molina, Thomas (ES)) Date: Fri, 2 Dec 2011 11:33:16 +0000 Subject: [rhelv6-list] EXT :Re: maximum member unix group in /etc/group In-Reply-To: <4ED7E375.1070607@cse.yorku.ca> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> <4ED7C28C.2090009@cse.yorku.ca> <7F2C60CEE8B98346BD9FBAE010150522323E9A@silicon.mrc-epid.cam.ac.uk> <4ED7E375.1070607@cse.yorku.ca> Message-ID: <711A5FADCDFBA344AD012C8E7E57AA5C06488F16@XMBVAG77.northgrum.com> Ian's workaround is a good one. I use it in my installation also. However, there is a "gotcha" in there also. When an external nis client authenticates against the server it gets the proper gid, but the group name is that of the last entry. In Ian's case: > largegroup:x:1234: > largegroup1:x:1234:uname01,uname02,... > largegroup2:x:1234:uname31,uname31,... > largegroup3:x:1234:uname61,uname61,... > largegroup4:x:1234: > largegroup5:x:1234: the name reported to external clients would be largegroup5. This is not a problem for Unix/Linux clients who use the numeric id, but clients who use the literal name can be confused. In our installation we have an RHEL6 nis server, Linux clients, Solaris clients, and Windows clients working through Samba. When a Rational Clearcase Windows client works through Samba to access the database, the Clearcase client would pass its group as largegroup, and access would fail because the database server was expecting largegroup5. -----Original Message----- From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Jason Keltz Sent: Thursday, December 01, 2011 3:29 PM To: rhelv6-list at redhat.com Subject: EXT :Re: [rhelv6-list] maximum member unix group in /etc/group Hi Ian, Thanks for the workaround... While I'm not using NIS, I can say this with certainty: 1) Installed glibc-2.12-1.7.el6.x86_64 (original RHEL6 glibc), and it worked with all of my groups. 2) installed glibc-2.12-1.25.el6_1.3/x86_64 and it did not ... revert system with glibc-2.12-1.25.el6_1.3/x86_64 to glibc-2.12-1.7.el6.x86_64 and it works... HMMM.. seems like a bug to me .. which I will report .. but most of the times I report stuff, it doesn't end up getting fixed anyway. At least I have your fix in the meantime.. Thanks! Jason. On 12/01/2011 02:17 PM, Iain Morrison wrote: > Hi Jason, > we had this problem with groups in NIS under RHEL4, and whilst it may > be a bug in RHEL 6.1 the workaround we use might work for you. > > [The length of one entry is limited by the NIS protocol to 1024 > characters.] > > > ------------------- > > There is another way of solving this problem for /etc/group entries. > This idea is from Ken Cameron: > > 1. Break the entry into more than one line and name each group > slightly differently. > > 2. Keep the GID the same for all. > > 3. Have the first entry with the right group name and the GID. > I don't put any user names in this one. > > What happens is that going by user name you pick up the GID when the > code > reads it. Then going the other way it stops after the first match of GID > and takes that name. It's ugly but works! > > ------------------------ > > so for example we have > > largegroup:x:1234: > largegroup1:x:1234:uname01,uname02,... > largegroup2:x:1234:uname31,uname31,... > largegroup3:x:1234:uname61,uname61,... > largegroup4:x:1234: > largegroup5:x:1234: > > thanks > > iain > > > -- > > Iain Morrison > IT Manager > MRC Epidemiology Unit > Institute of Metabolic Science > Box 285 > Addenbrooke's Hospital > Hills Road > Cambridge > CB2 0QQ > Tel 01223 769200 > > -----Original Message----- > From: rhelv6-list-bounces at redhat.com > [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Jason Keltz > Sent: 01 December 2011 18:08 > To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list > Subject: [rhelv6-list] maximum member unix group in /etc/group > > Under RHEL4, as far as I can see, there was no limitation in unix group > size in /etc/group in terms of line lengths or number of users, or at > least I never came close to hitting the limit. Under RHEL6.1, I hit the > > limit today - 126 members. It's not clear if this is a bug or a > feature, or why such a limitation would be imposed. It's possible that > it was imposed by a patch, but after applying many patches, it's not > clear which would have caused it. Any ideas??? > > Jason. > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -- Jason Keltz Manager of Development Department of Computer Science and Engineering York University, Toronto, Canada Tel: 416-736-2100 x. 33570 Fax: 416-736-5872 _______________________________________________ rhelv6-list mailing list rhelv6-list at redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-list From jiannma at gmail.com Sun Dec 4 13:56:40 2011 From: jiannma at gmail.com (=?UTF-8?B?6aas5bCP5biD?=) Date: Sun, 4 Dec 2011 21:56:40 +0800 Subject: [rhelv6-list] RHEL6 Wireless problem Message-ID: Hi, guys: I have a problem about the RHEL6 x64 wireless, please help me ... When I restart the network setting, like this : [root at genius ~]# /etc/init.d/network restart Shutting down interface eth0: Device state: 3 (disconnected) [ OK ] Shutting down interface wlan0: Error: Device 'wlan0' (/org/freedesktop/NetworkManager/Devices/1) disconnecting failed: This device is not active [FAILED] Shutting down loopback interface: [ OK ] Bringing up loopback interface: [ OK ] Bringing up interface eth0: Active connection state: activating Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/3 state: activated Connection activated [ OK ] Bringing up interface wlan0: RTNETLINK answers: File exists [ OK As you can see, the wireless does not start successfully. I googled for a long time, but it did not been solved now. By the way, the following message is my wirless device : [root at genius ~]# lspci |grep Wire 06:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dsavage at peaknet.net Sun Dec 4 23:34:28 2011 From: dsavage at peaknet.net (dsavage at peaknet.net) Date: Sun, 4 Dec 2011 17:34:28 -0600 (CST) Subject: [rhelv6-list] yum reinstall permissions bug? Message-ID: <46500.99.105.127.132.1323041668.squirrel@www.peaknet.net> I recently found myself needing to use yum to reinstall all the packages on my RHEL6.1 server to correct their ownerships inadvertently changed by a rogue script. Afterwards I noticed that there were still several dozen packages with the wrong permissions (Modes, according to 'rpm -V'). These same packages had just been reinstalled by yum. If yum's reinstall does not restore permissions to their original values, is that a bug? Or is there another preferred way to do that? --Doc Savage Fairview Heights, IL From ajb at elrepo.org Mon Dec 5 00:02:30 2011 From: ajb at elrepo.org (Alan Bartlett) Date: Mon, 5 Dec 2011 00:02:30 +0000 Subject: [rhelv6-list] yum reinstall permissions bug? In-Reply-To: <46500.99.105.127.132.1323041668.squirrel@www.peaknet.net> References: <46500.99.105.127.132.1323041668.squirrel@www.peaknet.net> Message-ID: On 4 December 2011 23:34, wrote: > I recently found myself needing to use yum to reinstall all the packages > on my RHEL6.1 server to correct their ownerships inadvertently changed by > a rogue script. Afterwards I noticed that there were still several dozen > packages with the wrong permissions (Modes, according to 'rpm -V'). These > same packages had just been reinstalled by yum. > > If yum's reinstall does not restore permissions to their original values, > is that a bug? Or is there another preferred way to do that? An answer to your second question can be found on the rpm manual page, under the MISCELLANEOUS heading, rpm {--setperms|--setugids} PACKAGE_NAME ... As for your first question, yes, it might be a bug. Alan. From rprice at redhat.com Mon Dec 5 16:24:36 2011 From: rprice at redhat.com (Robin Price II) Date: Mon, 05 Dec 2011 11:24:36 -0500 Subject: [rhelv6-list] yum reinstall permissions bug? In-Reply-To: <46500.99.105.127.132.1323041668.squirrel@www.peaknet.net> References: <46500.99.105.127.132.1323041668.squirrel@www.peaknet.net> Message-ID: <4EDCF044.5080002@redhat.com> On 12/04/2011 06:34 PM, dsavage at peaknet.net wrote: > I recently found myself needing to use yum to reinstall all the packages > on my RHEL6.1 server to correct their ownerships inadvertently changed by > a rogue script. Afterwards I noticed that there were still several dozen > packages with the wrong permissions (Modes, according to 'rpm -V'). These > same packages had just been reinstalled by yum. > > If yum's reinstall does not restore permissions to their original values, > is that a bug? Or is there another preferred way to do that? > Mr. Savage, You should be able to recover by following this kbase: How do I reset the ownership and permissions of files installed by the Red Hat Package Manager (RPM) under Red Hat Enterprise Linux? https://access.redhat.com/kb/docs/DOC-25162 I have done this myself and ended up scripting something up like: for p in $(rpm -qa); do rpm --setperms $p; done for p in $(rpm -qa); do rpm --setugids $p; done And for home directorys.. for u in `ls /home`; do chown -Rh $u.$u /home/$u/; done I have never done this from yum. HTHs, ~rp -- +-----------------------------[ robin at redhat.com ]----+ | Robin Price II - RHCE, RHCDS, RHCVA | | Technical Account Manager | | Red Hat, Inc. | | w: +1 (919) 754 4412 | | c: +1 (252) 474 3525 | | | +---------[ Dissenters will inevitably abhor. ]-------+ From rprice at redhat.com Mon Dec 5 16:37:47 2011 From: rprice at redhat.com (Robin Price II) Date: Mon, 05 Dec 2011 11:37:47 -0500 Subject: [rhelv6-list] RHEL6 Wireless problem In-Reply-To: References: Message-ID: <4EDCF35B.2040400@redhat.com> On 12/04/2011 08:56 AM, ??? wrote: > Hi, guys: > > > I have a problem about the RHEL6 x64 wireless, please help me ... > > When I restart the network setting, like this : > [root at genius ~]# /etc/init.d/network restart > Shutting down interface eth0: Device state: 3 (disconnected) > [ OK ] > Shutting down interface wlan0: Error: Device 'wlan0' > (/org/freedesktop/NetworkManager/Devices/1) disconnecting failed: This > device is not active > [FAILED] > Shutting down loopback interface: [ OK ] > Bringing up loopback interface: [ OK ] > Bringing up interface eth0: Active connection state: activating > Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/3 > state: activated > Connection activated > [ OK ] > Bringing up interface wlan0: RTNETLINK answers: File exists > [ OK > > > As you can see, the wireless does not start successfully. > I googled for a long time, but it did not been solved now. > > > > By the way, the following message is my wirless device : > [root at genius ~]# lspci |grep Wire > 06:00.0 Network controller: Atheros Communications Inc. AR928X Wireless > Network Adapter (PCI-Express) (rev 01 > > Hello. Have you tried with the latest RHEL6.1? I would also suggest restarting NetworkManager vs restarting the networking service for wireless controllers. Are you using the correct module? Is the module (driver) installed? A good way to check would be getting the output of 'lspci' and 'lspci -n'. Using my x200 laptop as an example, lspci will return a line like: ... 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03) ... What is important from this line is the 00:19.0. At this point, we are going to check if the above Ethernet controller is supported. We need to now get the output from 'lspci -n' on the same machine and look at the line with 00:19.0 in it. ... 00:19.0 0200: 8086:10f5 (rev 03) ... The important part here is the 8086:10f5. This is the hardware pci id. We can compare this information to the kernel drivers and 'modinfo'. RHEL{5,6}: $ find /lib/modules/$(uname -r)/kernel/drivers -type f|xargs modinfo|grep -B 200 -i 8086 | grep -B 50 -i 10f5 | grep filename | tail -n1 filename: /lib/modules/2.6.32-131.21.1.el6.x86_64/kernel/drivers/net/e1000e/e1000e.ko Sorry for the ugly command but this information tells us that the card is supported and in this case tells us the module that it uses. You may or may not get the module information. If you do not, that is a good indication the piece of hardware is not supported. You should also search for one part of the hardware pci id to get more results but a good rule of thumb is if you don't get anything back, then you _may_ (not always) need to get the driver from the vendor. HTHs, ~rp -- +-----------------------------[ robin at redhat.com ]----+ | Robin Price II - RHCE,RHCDS,RHCVA | | Technical Account Manager | | Red Hat, Inc. | | w: +1 (919) 754 4412 | | c: +1 (252) 474 3525 | | | +---------[ Dissenters will inevitably abhor. ]-------+ From alois at astro.ch Mon Dec 5 17:05:01 2011 From: alois at astro.ch (Alois Treindl) Date: Mon, 05 Dec 2011 18:05:01 +0100 Subject: [rhelv6-list] [rhelv6-beta-list] where are RHEL6 source rpms In-Reply-To: <7AADEC3A-FFFE-4AB8-B6A1-92592B45A408@mimectl> References: <4EDCC668.4090603@astro.ch> <7AADEC3A-FFFE-4AB8-B6A1-92592B45A408@mimectl> Message-ID: <4EDCF9BD.7050004@astro.ch> I get: yumdownloader --source httpd Loaded plugins: product-id, refresh-packagekit, rhnplugin No source RPM found for httpd-2.2.15-9.el6.x86_64 No source RPM found for httpd-2.2.15-9.el6.x86_64 No source RPM found for httpd-2.2.15-9.el6_1.3.x86_64 No source RPM found for httpd-2.2.15-5.el6.x86_64 No source RPM found for httpd-2.2.15-9.el6_1.2.x86_64 Nothing to download On 05.12.11 14:56, Brian Long (brilong) wrote: > Use the yum utility "yumdownloader". yumdownloader--source httpdand the > rhel-source repo does not have to be enabled. yumdownloaderwill enable > it on-the-fly. > > Also, you should probably be writing to rhel6-list instead of the beta > list so you'll get more responses. > > /Brian/ > > -- > Brian Long | | > Corporate Security Programs Org . | | | . | | | . > ' ' > C I S C O > ------------------------------------------------------------------------ > *From:* rhelv6-beta-list-bounces at redhat.com > [rhelv6-beta-list-bounces at redhat.com] on behalf of > AloisTreindl[alois at astro.ch] > *Sent:* Monday, December 05, 2011 8:26 AM > *To:* rhelv6-beta-list at redhat.com > *Subject:* [rhelv6-beta-list] where are RHEL6source rpms > > I would like tpinstall some source rpmswith yum. > I have this file /etc/yum.repos.d/rhel-source.repo > [rhel-source] > name=Red Hat Enterprise Linux $releasever- $basearch- Source > baseurl=ftp://ftp.redhat.com/pub/redhat/linux/enterprise/$releasever/en/os/SRPMS/ > enabled=1 > gpgcheck=1 > gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release > > But with > yum install httpd*src > I do not get anything. > > I would like to install httpdsource because I need to make a small > modification to the mod_logconfigcode. > > (My reason is: it logs by default the time for the begin of the httpd > request. But the log entry is only written at the end of the request. > Earlier writing is not possible because it needs to log the numbrof > bytes transmitted, and this is only known at the end. > > I prefer it to log the time of the end of request, because this way the > access_logentries are in strict temporal order. > > I have a modification to mod_logconfig.cwhich does that.) > > _______________________________________________ > rhelv6-beta-list mailing list > rhelv6-beta-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-beta-list > > > _______________________________________________ > rhelv6-beta-list mailing list > rhelv6-beta-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-beta-list From amyagi at gmail.com Mon Dec 5 17:24:16 2011 From: amyagi at gmail.com (Akemi Yagi) Date: Mon, 5 Dec 2011 09:24:16 -0800 Subject: [rhelv6-list] [rhelv6-beta-list] where are RHEL6 source rpms In-Reply-To: <4EDCF9BD.7050004@astro.ch> References: <4EDCC668.4090603@astro.ch> <7AADEC3A-FFFE-4AB8-B6A1-92592B45A408@mimectl> <4EDCF9BD.7050004@astro.ch> Message-ID: On Mon, Dec 5, 2011 at 9:05 AM, Alois Treindl wrote: > I get: > yumdownloader --source httpd > Loaded plugins: product-id, refresh-packagekit, rhnplugin > No source RPM found for httpd-2.2.15-9.el6.x86_64 > No source RPM found for httpd-2.2.15-9.el6.x86_64 > No source RPM found for httpd-2.2.15-9.el6_1.3.x86_64 > No source RPM found for httpd-2.2.15-5.el6.x86_64 > No source RPM found for httpd-2.2.15-9.el6_1.2.x86_64 > Nothing to download These bugzilla reports might help resolve the issue: https://bugzilla.redhat.com/show_bug.cgi?id=710469 https://bugzilla.redhat.com/show_bug.cgi?id=719654 Akemi From alois at astro.ch Mon Dec 5 17:51:09 2011 From: alois at astro.ch (Alois Treindl) Date: Mon, 05 Dec 2011 18:51:09 +0100 Subject: [rhelv6-list] [rhelv6-beta-list] where are RHEL6 source rpms In-Reply-To: References: <4EDCC668.4090603@astro.ch> <7AADEC3A-FFFE-4AB8-B6A1-92592B45A408@mimectl> <4EDCF9BD.7050004@astro.ch> Message-ID: <4EDD048D.7080602@astro.ch> Thanks. I this bugzilla report I find these instructions: --quote I edited the /etc/yum.repos.d/rhel-source.repo file and changed: [rhel-source] to [rhel-x86_64-server-6-source] 'yumdownloader --source' now works with this temporary fix. ---- end quote It works. On 05.12.11 18:24, Akemi Yagi wrote: > > These bugzilla reports might help resolve the issue: > > https://bugzilla.redhat.com/show_bug.cgi?id=710469 > https://bugzilla.redhat.com/show_bug.cgi?id=719654 > > Akemi > From rprice at redhat.com Mon Dec 5 20:18:48 2011 From: rprice at redhat.com (Robin Price II) Date: Mon, 05 Dec 2011 15:18:48 -0500 Subject: [rhelv6-list] [rhelv6-beta-list] where are RHEL6 source rpms In-Reply-To: <4EDD048D.7080602@astro.ch> References: <4EDCC668.4090603@astro.ch> <7AADEC3A-FFFE-4AB8-B6A1-92592B45A408@mimectl> <4EDCF9BD.7050004@astro.ch> <4EDD048D.7080602@astro.ch> Message-ID: <4EDD2728.5040403@redhat.com> On 12/05/2011 12:51 PM, Alois Treindl wrote: > Thanks. I this bugzilla report I find these instructions: > --quote > I edited the /etc/yum.repos.d/rhel-source.repo file and changed: > > [rhel-source] > > to > > [rhel-x86_64-server-6-source] > > 'yumdownloader --source' now works with this temporary fix. > ---- end quote > > It works. > > On 05.12.11 18:24, Akemi Yagi wrote: > >> >> These bugzilla reports might help resolve the issue: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=710469 >> https://bugzilla.redhat.com/show_bug.cgi?id=719654 For anyone wanting an official kbase: How do I use the yumdownloader command to get source packages for Red Hat Enterprise Linux? https://access.redhat.com/kb/docs/DOC-15838 ~rp -- +-----------------------------[ robin at redhat.com ]----+ | Robin Price II - RHCE,RHCDS,RHCVA | | Technical Account Manager | | Red Hat, Inc. | | w: +1 (919) 754 4412 | | c: +1 (252) 474 3525 | | | +---------[ Dissenters will inevitably abhor. ]-------+ From jiannma at gmail.com Tue Dec 6 14:12:53 2011 From: jiannma at gmail.com (=?UTF-8?B?6aas5bCP5biD?=) Date: Tue, 6 Dec 2011 22:12:53 +0800 Subject: [rhelv6-list] RHEL6 Wireless problem In-Reply-To: <4EDCF35B.2040400@redhat.com> References: <4EDCF35B.2040400@redhat.com> Message-ID: > >> > Hello. Have you tried with the latest RHEL6.1? > Yes, I really am sure that I installed the lasted RHEL6.1? [Sync at genius tmp]$ uname -a Linux genius 2.6.32-131.0.15.el6.x86_64 #1 SMP Tue May 10 15:42:40 EDT 2011 x86_64 x86_64 x86_64 GNU/Linux [Sync at genius tmp]$ cat /etc/issue Red Hat Enterprise Linux Server release 6.1 (Santiago) Kernel \r on an \m > > I would also suggest restarting NetworkManager vs restarting the > networking service for wireless controllers. > I restart that service , when I click the "enable wireless" on NetWorkManager applet , then the machine display the following message: root at genius ~: tailf /var/log/message ...... ..... Dec 6 22:05:37 genius dbus: [system] Rejected send message, 1 matched rules; type="method_return", sender=":1.75" (uid=0 pid=3588 comm="NetworkManager) interface="(unset)" member="(unset)" error name="(unset)" requested_reply=0 destination=":1.52" (uid=500 pid=2548 comm="nm-applet)) > Are you using the correct module? Is the module (driver) installed? A > good way to check would be getting the output of 'lspci' and 'lspci -n'. > > Using my x200 laptop as an example, lspci will return a line like: > > ... > 00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network > Connection (rev 03) > ... > > What is important from this line is the 00:19.0. At this point, we are > going to check if the above Ethernet controller is supported. We need to > now get the output from 'lspci -n' on the same machine and look at the line > with 00:19.0 in it. > > ... > 00:19.0 0200: 8086:10f5 (rev 03) > ... > > The important part here is the 8086:10f5. This is the hardware pci id. > We can compare this information to the kernel drivers and 'modinfo'. > > RHEL{5,6}: > > $ find /lib/modules/$(uname -r)/kernel/drivers -type f|xargs modinfo|grep > -B 200 -i 8086 | grep -B 50 -i 10f5 | grep filename | tail -n1 > > filename: /lib/modules/2.6.32-131.21.1.**el6.x86_64/kernel/drivers/net/** > e1000e/e1000e.ko > As you told me , the following message is my wireless controller: [Sync at genius drivers]$ lspci 06:00.0 Network controller: Atheros Communications Inc. AR928X Wireless Network Adapter (PCI-Express) (rev 01) [Sync at genius drivers]$ lspci -n 06:00.0 0280: 168c:002a (rev 01) [Sync at genius drivers]$ find . -type f |xargs modinfo |grep -B 200 -i 168c |grep -B 50 -i 002a |grep filename|tail -n1 filename: ./net/wireless/ath/ath9k/ath9k.ko [Sync at genius drivers]$ pwd /lib/modules/2.6.32-131.0.15.el6.x86_64/kernel/drivers So the card is supported , isn't it ? > > Sorry for the ugly command but this information tells us that the card is > supported and in this case tells us the module that it uses. You may or > may not get the module information. If you do not, that is a good > indication the piece of hardware is not supported. You should also search > for one part of the hardware pci id to get more results but a good rule of > thumb is if you don't get anything back, then you _may_ (not always) need > to get the driver from the vendor. > > HTHs, > > ~rp > > -- > +-----------------------------**[ robin at redhat.com ]----+ > | Robin Price II - RHCE,RHCDS,RHCVA | > | Technical Account Manager | > | Red Hat, Inc. | > | w: +1 (919) 754 4412 | > | c: +1 (252) 474 3525 | > | | > +---------[ Dissenters will inevitably abhor. ]-------+ > > ______________________________**_________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/**mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Tue Dec 6 18:10:52 2011 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Tue, 06 Dec 2011 13:10:52 -0500 Subject: [rhelv6-list] Red Hat Enterprise Linux 6.2 Announcement Message-ID: <4EDE5AAC.80208@redhat.com> Today Red Hat announces the general availability of Red Hat Enterprise Linux 6.2, which delivers to customers a second wave of feature enhancements and demonstrates the continued value that Red Hat delivers as part of the Red Hat Enterprise Linux 6 lifecycle. Red Hat Enterprise Linux 6.2 delivers significant improvements in virtualization, resource management and high availability, and offers new features in storage and file system performance and identity management. The key benefits for organizations employing Red Hat Enterprise Linux 6.2 are higher levels of efficiency realized through resource management and performance optimization, along with enhanced business agility through additional security and flexibility for virtualized and clustered deployments. Specifically, Red Hat Enterprise Linux 6.2: * provides simplified management tools for storage, clusters, filesystems, and virtualized resources including capabilities for resource management, SLAs, and user identity; * improves performance out of the box for virtualized guests, storage, networked filesystems, and clusters; * delivers additional scalability across file systems and virtualized resources; and; * achieves critical security certifications required by large enterprises and government agencies. These features and enhancements highlight Red Hat Enterprise Linux advantages as an operating system platform for the next generation enterprise. Although there are dozens of enhancements and new features for Red Hat Enterprise Linux 6 being introduced with the 6.2 release, below are several notable ones. Virtualization Optimizations Workload consolidation demands doing everything possible to reduce the overhead costs of CPU consumption in hosting virtual guests. Red Hat Enterprise Linux 6.2 includes several networking optimizations that can reduce data copies and reduce context switching. Another initiative is to provide similar diagnostic capabilities as bare-metal for virtualized guests in pre-boot environments and for system backtracing capabilities. Further usability enhancements are included making it easier to dedicate both CPU and memory resources for performance optimization of high priority virtualized guests. Resource Management Red Hat Enterprise Linux 6.2 provides additional capabilities to manage system resources. For service providers or internal IT organization who deliver applications or hosted services via multi-tenant environments, maximums can be set for CPU time associated with a given application, business process or a virtual machine. This allows for more efficient management of SLAs and enables the ability to implement service priorities, similar to those associated with network Quality of Service (QoS). High Availability When an enterprise deploys its applications to run in a Red Hat Enterprise Linux 6.2 guest hosted by VMware, the container can now be configured for High Availability (HA). This also includes full support for use of GFS2 shared storage file system in the environment. The result is additional deployment flexibility for those customer who require HA within a portion of their virtualized environment, as well as full support for Red Hat Enterprise Linux on the VMware hypervisor. Storage and File System Performance Red Hat Enterprise Linux 6.2 adds the capability for full support of iSCSI extension for RDMA. Now, the benefits of low latency and high throughput through a standard SAN implementation based on 10Gb Ethernet are available to even the most demanding storage environments. This allows developers to opt out of expensive Infiniband hardware or other dedicated interconnect fabrics. Other enhancements around file system (delayed meta data logging, asynchronous and parallel file system writes) and clustering (for large Samba deployments) also drive performance benefits. Identity Management Identity Management in Red Hat Enterprise Linux 6.2 provides the administrative tools to quickly install, configure and manage server authentication and authorization in Linux/Unix enterprise environments, while still providing the option to interoperate with Microsoft Active Directory. This enables enterprises to manage Linux infrastructure easily and cost-effectively. Centralized identity management and host-based access control can reduce administrative overhead, streamlines provisioning and improves security. Performance Performance is key to all customers and Red Hat Enterprise Linux 6.2 continues to put an emphasis on accelerating I/O with features such as network traffic steering. As a result, numerous filesystem enhancements that reduce read-write times and boosts overall system utilization are delivered, and network throughput is improved by as much as 30 percent, in performance tests conducted by Red Hat. Enterprises can confidently migrate to the latest multi-core technology with Red Hat Enterprise Linux 6. On the latest two-tier SAP SD standard application benchmark, Red Hat Enterprise Linux 6 achieved more than 22,000 SAP SD benchmark users on a single system. On this same benchmark, the HP DL980 system running Red Hat Enterprise Linux 6 fully utilized all 80 cores and 160 threads in the 8-processor system running MaxDB 7.8 and the SAP enhancement package 4 for the SAP ERP 6.0 application. This is the largest Linux result submitted to SAP to-date. Results as of December 2, 2011, certification number 2011052. We look forward to our customer feedback, and to the continued adoption of Red Hat Enterprise Linux 6, the foundation for the next generation enterprise. For more information about what?s new in Red Hat Enterprise Linux 6.2, please visit: http://www.redhat.com/rhel/server/whats_new For a detailed overview of the technical features and benefits, see this document: http://www.redhat.com/f/pdf/RHEL_6_2_features_benefits.pdf To see the Red Hat Enterprise Linux 6.2 press release look here: http://www.redhat.com/about/news/prarchive/2011/first-anniversary-of-red-hat-enterprise-linux-6 For overall information about Red Hat Enterprise Linux 6 please visit: http://www.redhat.com/rhel Sincerely, The Red Hat Enterprise Linux team From rprice at redhat.com Tue Dec 6 18:42:57 2011 From: rprice at redhat.com (Robin Price II) Date: Tue, 06 Dec 2011 13:42:57 -0500 Subject: [rhelv6-list] RHEL6 Wireless problem In-Reply-To: References: <4EDCF35B.2040400@redhat.com> Message-ID: <4EDE6231.1030806@redhat.com> On 12/06/2011 09:12 AM, ??? wrote: > So the card is supported , isn't it ? Yes. Should be. This is from RHEL6u2 (released today). [root at rhel6-kvm ~]# find /lib/modules/$(uname -r)/kernel/drivers -type f|xargs modinfo|grep -B 200 -i 168c | grep -B 50 -i 002a | grep filename | tail -n1 filename: /lib/modules/2.6.32-220.el6.x86_64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko [root at rhel6-kvm ~]# modinfo ath9k filename: /lib/modules/2.6.32-220.el6.x86_64/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko license: Dual BSD/GPL description: Support for Atheros 802.11n wireless LAN cards. author: Atheros Communications srcversion: 68B4927988FC4377BC6640E alias: pci:v0000168Cd0000002Esv*sd*bc*sc*i* alias: pci:v0000168Cd0000002Dsv*sd*bc*sc*i* alias: pci:v0000168Cd0000002Csv*sd*bc*sc*i* alias: pci:v0000168Cd0000002Bsv*sd*bc*sc*i* alias: pci:v0000168Cd0000002Asv*sd*bc*sc*i* alias: pci:v0000168Cd00000029sv*sd*bc*sc*i* alias: pci:v0000168Cd00000027sv*sd*bc*sc*i* alias: pci:v0000168Cd00000024sv*sd*bc*sc*i* alias: pci:v0000168Cd00000023sv*sd*bc*sc*i* depends: mac80211,ath,cfg80211 vermagic: 2.6.32-220.el6.x86_64 SMP mod_unload modversions parm: nohwcrypt:Disable hardware encryption (int) My question is, what run level are you in and are you doing this strictly from command line? Because, for me, I let NetworkManager (GUI) handle any of my wireless connections since I boot into Gnome in RHEL6. ~rp -- +-----------------------------[ robin at redhat.com ]----+ | Robin Price II - RHCE,RHCDS,RHCVA | | Technical Account Manager | | Red Hat, Inc. | | w: +1 (919) 754 4412 | | c: +1 (252) 474 3525 | | | +---------[ Dissenters will inevitably abhor. ]-------+ From rprice at redhat.com Tue Dec 6 18:56:33 2011 From: rprice at redhat.com (Robin Price II) Date: Tue, 06 Dec 2011 13:56:33 -0500 Subject: [rhelv6-list] RHEL6 Wireless problem In-Reply-To: References: Message-ID: <4EDE6561.9050601@redhat.com> On 12/04/2011 08:56 AM, ??? wrote: > [root at genius ~]# /etc/init.d/network restart > Shutting down interface eth0: Device state: 3 (disconnected) > [ OK ] > Shutting down interface wlan0: Error: Device 'wlan0' > (/org/freedesktop/NetworkManager/Devices/1) disconnecting failed: This > device is not active > [FAILED] > Shutting down loopback interface: [ OK ] > Bringing up loopback interface: [ OK ] > Bringing up interface eth0: Active connection state: activating > Active connection path: /org/freedesktop/NetworkManager/ActiveConnection/3 > state: activated > Connection activated > [ OK ] > Bringing up interface wlan0: RTNETLINK answers: File exists > [ OK Now that I think about it. Since you are using the network init script vs NetworkManager, have you gone through your networking scripts and removed "NM_CONTROLLED=yes", stopped NetworkManager, and then started network? example: vim /etc/sysconfig/network-script/ifcfg-eth* Remove "NM_CONTROLLED=yes" line from every script in order to be able for the network daemon to control it. # service NetworkManager stop # chkconfig NetworkManager off # service network start # chkconfig network on Also, would want to enable the device with 'ifconfig wlan0 up', but here are some kbases that talk about the 'RTNETLINK answers: File exists' error. https://access.redhat.com/kb/docs/DOC-48573 https://access.redhat.com/kb/docs/DOC-50709 HTHs, ~rp -- +-----------------------------[ robin at redhat.com ]----+ | Robin Price II - RHCE,RHCDS,RHCVA | | Technical Account Manager | | Red Hat, Inc. | | w: +1 (919) 754 4412 | | c: +1 (252) 474 3525 | | | +---------[ Dissenters will inevitably abhor. ]-------+ From dsavage at peaknet.net Wed Dec 7 05:59:48 2011 From: dsavage at peaknet.net (Robert G. (Doc) Savage) Date: Tue, 06 Dec 2011 23:59:48 -0600 Subject: [rhelv6-list] setuid helper permission??? - RESOLVED! In-Reply-To: <4ED798F2.6030804@divms.uiowa.edu> References: <48171.99.105.127.132.1322709180.squirrel@www.peaknet.net> <4ED798F2.6030804@divms.uiowa.edu> Message-ID: <1323237588.26285.94.camel@lion.protogeek.org> Three weeks ago I ran a newly-edited script that was missing one critical character. My first indication that something was wrong was when all attempts to "su -" to root failed with a wrong password error. I rebooted to single user mode, ran passwd, then rebooted again. I knew I had serious trouble when it booted to a black screen. I hard reset, rebooted to single user mode again. In retrospect it seems a miracle it could do that because I found everything -- every file, every directory -- was owned by me:me. With more than 2,500 packages installed, recovery would take time: three weeks, with help. Steve Pritchard, a local friend who maintains several hundred Fedora hardware packages, helped me cob together a script that tried to use rpm to restore proper ownerships: # cat rpmowners.sh #!/bin/sh rpm -qalv | grep -v '^(contains no files)$' | grep -v '^l' \ | while read perm nlink user group size month day time filename ; do chown -v "$user":"$group" "$filename" done After a 24-hour run there were still thousands of files owned by me:me, but even with several errors I was able to boot to runlevel 3. Progress. All the soft links in /etc/rc.d/ and below were still owned by me:me, so I manually re-created those as root:root. That didn't help much. A close examination of /var/log/messages showed some sort of "setuid helper" permissions problem. A Google search seemed to point to /usr/bin/sudo. After posting that info to this list, Hugh Brown told me there were several other setuid executables besides sudo. He had me run this script to identify what rpm calls "Mode" problems: # cat setuid-check.sh #!/bin/sh cat /root/rpmlist.txt | while read pkg; do echo "########## Testing $pkg ##########" rpm -V $pkg | grep -E "^.M" done | tee rpm-pkg-mode-problems This identified more than a dozen packages with ownership and/or permission ("Mode") problems. While it told me there was a problem, it didn't say what those ownerships and permissions needed to be. So, I tried reinstalling everything in the RPM database: # rpm -qa | sort > ~/rpmlist.txt # cat reinstall.sh #!/bin/sh for i in `cat /root/rpmlist.txt` ; do \ yum -y reinstall $i done After that script also ran for 24 hours, the setuid-check.sh script still showed more than a dozen Mode errors. Yum should have fixed those, so there's probably a bug in its reinstall option. Barry Brimer and a couple of others suggested using rpm itself rather than yum, so for each of those Mode error packages I ran: # rpm --force --setperms --setugids --replacefiles After that I tried rebooting to runlevel 5 and got the graphical logon screen -- Hooray!! But the keyboard and mouse which worked fine at runlevel 3 were totally inop. Hugh Brown suggested I try manually starting X from runlevel 3: # startx -- -logverbose 5 and check /var/log/Xorg.0.log. BINGO! There it was: the haldaemon wasn't running. That made sense: no haldaemon, no mouse or keyboard. I ran "chkconfig haldaemon on", rebooted, and Voila! What killed my system in the first? Whatever you do, try not to make this mistake in a script: set LOCAL_USER=me:me set LOCAL_DEST1=/pub/ScientificLinux/scientific/6.0/ set LOCAL_DEST2=/pub/ScientificLinux/scientific/6.x/ ... cd LOCAL_DEST <-- ERROR cd .. chown -R me:me See it? The undefined variable "LOCAL_DEST" (not LOCAL_DEST1 or LOCAL_DEST2) will evaluate to "~" for the user running the script -- in this case /root. The script promptly cd'd to / and did what it was told. OH NO!! --Doc Savage Fairview Heights, IL From bda20 at cam.ac.uk Thu Dec 8 09:31:39 2011 From: bda20 at cam.ac.uk (Ben) Date: Thu, 8 Dec 2011 09:31:39 +0000 (GMT) Subject: [rhelv6-list] KVM issues post RHEL6-1->6.2 update Message-ID: Just thought I'd share my experiences of updating a KVM host and guests this morning. I'll acknowledge up front that I didn't do things in the right order so the mistakes were mine. Start: RHEL6.1 KVM host, x2 RHEL6.1 guests using .img files (LVM partitions inside). Fully up to date as of just before the RHEL6.2 errata release. I did "yum clean all ; yum update" on both the host and the guests at the same time (yeah, I know). In my defence, a seemingly identical setup I did this on yesterday worked without issues. At the point at which the host was completing its cleanup this happened in /var/log/messages: Dec 8 07:14:47 frazil libvirtd: 07:14:47.926: 14778: warning : qemudDispatchSignalEvent:403 : Shutting down on signal 15 Dec 8 07:14:49 frazil yum[1235]: Updated: libvirt-0.9.4-23.el6_2.1.x86_64 and further down Dec 8 07:15:00 frazil kernel: br1: port 2(vnet1) entering disabled state Dec 8 07:15:00 frazil kernel: device vnet1 left promiscuous mode Dec 8 07:15:00 frazil kernel: br1: port 2(vnet1) entering disabled state Dec 8 07:15:02 frazil ntpd[2194]: Deleting interface #23 vnet1, fe80::fc54:ff:fe01:6b3b#123, interface stats: received=0, sent=0, dropped=0, active_time=7241352 secs Dec 8 07:15:05 frazil kernel: br0: port 2(vnet0) entering disabled state Dec 8 07:15:05 frazil kernel: device vnet0 left promiscuous mode Dec 8 07:15:05 frazil kernel: br0: port 2(vnet0) entering disabled state Dec 8 07:15:07 frazil ntpd[2194]: Deleting interface #25 vnet0, fe80::fc54:ff:fe49:fae6#123, interface stats: received=0, sent=0, dropped=0, active_time=7238050 secs At this point I lost connection to the guests, which (according to the SSH connections I had open to them) had apparently finished cleaning up after the yum update (according to the right-hand side X/Y counter) but hadn't returned a prompt yet so were obviously still busy doing stuff. I guess the restart of the libvirtd service dropped the guests (except the same lines appear in the messages file of the server on which the guests didn't get killed). Given I was rebooting the host anyway I didn't bother to bring the guests back up again and rebooted the host (yeah, I know). On reboot neither of the guests autostarted, so I logged in to the host and tried to start them with "virsh start ". Both complained that error: internal error unable to reserve PCI address 0:0:2.0 and didn't start. Checking the .xml files for both guests I noted that
was listed for the 'disk' device. I also noticed that the following lines were missing