From KCollins at chevron.com Wed Jul 3 18:32:21 2013 From: KCollins at chevron.com (Collins, Kevin [Contractor Acquisition Program]) Date: Wed, 3 Jul 2013 18:32:21 +0000 Subject: [rhelv6-list] ISO downloads hang... Message-ID: <6F56410FBED1FC41BCA804E16F594B0B32DEE898@chvpkw8xmbx05.chvpk.chevrontexaco.net> Hi all, Is anyone else experiencing issues trying to download RHEL6 or RHEL5 ISO images from RHN? I have been trying off and on for 3 days, and have not completed a download yet. I have tried: IE in Windows Firefox in Windows Wget in Windows Firefox in Linux Wget in Linux Curl in Linux In all cases, the ISO starts to download and then gets up to a couple hundred MB (at most) before stoppping progress. In the case of Firefox, I can pause/resume and the DL will pick up again, but usually stops again after less than 100MB... and then fails completely on the 4th or 5th pause/resume. I have opened a support ticket within my company to see if it could be being impacted by our corporate firewall/proxy, but I was able to completely DL a Centos ISO today with no issue. Any suggestions welcome... Thanks, Kevin -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.j.smith at ieee.org Wed Jul 3 18:47:14 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Wed, 3 Jul 2013 14:47:14 -0400 Subject: [rhelv6-list] ISO downloads hang... In-Reply-To: <6F56410FBED1FC41BCA804E16F594B0B32DEE898@chvpkw8xmbx05.chvpk.chevrontexaco.net> References: <6F56410FBED1FC41BCA804E16F594B0B32DEE898@chvpkw8xmbx05.chvpk.chevrontexaco.net> Message-ID: On Wed, Jul 3, 2013 at 2:32 PM, Collins, Kevin [Contractor Acquisition Program] wrote: > Curl in Linux > In all cases, the ISO starts to download and then gets up to a couple > hundred MB (at most) before stoppping progress. > In the case of Firefox, I can pause/resume and the DL will pick up again, > but usually stops again after less than 100MB? and then fails completely on > the 4th or 5th pause/resume. > I use Curl with resume. I haven't had any issues with RH/Portal at all, and it's always my ISP acting up with infrequent loss-of-signal. In the areas where my ISP is better (given I sometimes have multiple residences near clients), I usually never have to restart, or maybe just once over a 4GiB download, maximum. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith -------------- next part -------------- An HTML attachment was scrubbed... URL: From eli.heady at gmail.com Wed Jul 3 19:42:41 2013 From: eli.heady at gmail.com (Eli Heady) Date: Wed, 3 Jul 2013 15:42:41 -0400 Subject: [rhelv6-list] ISO downloads hang... In-Reply-To: <6F56410FBED1FC41BCA804E16F594B0B32DEE898@chvpkw8xmbx05.chvpk.chevrontexaco.net> References: <6F56410FBED1FC41BCA804E16F594B0B32DEE898@chvpkw8xmbx05.chvpk.chevrontexaco.net> Message-ID: I downloaded a DVD image yesterday without issue using chromium. I'll echo Bryan's suggestion. Curl and wget have reliable resume options. Eli On Jul 3, 2013 2:35 PM, "Collins, Kevin [Contractor Acquisition Program]" < KCollins at chevron.com> wrote: > Hi all,**** > > ** ** > > Is anyone else experiencing issues trying to download RHEL6 or > RHEL5 ISO images from RHN? I have been trying off and on for 3 days, and > have not completed a download yet. I have tried:**** > > ** ** > > IE in Windows**** > > Firefox in Windows**** > > Wget in Windows**** > > ** ** > > Firefox in Linux**** > > Wget in Linux**** > > Curl in Linux**** > > ** ** > > In all cases, the ISO starts to download and then gets up to a couple > hundred MB (at most) before stoppping progress. **** > > ** ** > > In the case of Firefox, I can pause/resume and the DL will pick up again, > but usually stops again after less than 100MB? and then fails completely on > the 4th or 5th pause/resume.**** > > ** ** > > I have opened a support ticket within my company to see if it could be > being impacted by our corporate firewall/proxy, but I was able to > completely DL a Centos ISO today with no issue.**** > > ** ** > > Any suggestions welcome?**** > > ** ** > > Thanks,**** > > ** ** > > Kevin**** > > _______________________________________________ > 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 russell at jonesmail.me Fri Jul 5 14:13:24 2013 From: russell at jonesmail.me (Russell Jones) Date: Fri, 05 Jul 2013 09:13:24 -0500 Subject: [rhelv6-list] _rpm.error: rpmdb open failed Message-ID: <51D6D484.3070302@jonesmail.me> Hi all, I have an issue on 6.4 where doing a "yum install" into a rootdir utilizing RHEL 5 packages on a RHEL 6.4 box results in the following error: Installing : compat-gcc-34-c++-3.4.6-4.x86_64 713/714 Installing : compat-libstdc++-296-2.96-138.i386 714/714 Traceback (most recent call last): File "/usr/bin/yum", line 29, in yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 285, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 219, in main return_code = base.doTransaction() File "/usr/share/yum-cli/cli.py", line 586, in doTransaction resultobject = self.runTransaction(cb=cb) File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 1588, in runTransaction self.rpmdb.dropCachedDataPostTransaction(list(self.tsInfo)) File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 343, in dropCachedDataPostTransaction pkg = self.searchNevra(n, e, v, r, a) File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 1197, in searchNevra return self._search(name, epoch, ver, rel, arch) File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 1271, in _search mi = ts.dbMatch('name', name) _rpm.error: rpmdb open failed yum invocation failed Doing the exact same command on a RHEL 6.3 box works fine. This only happens after I upgrade the server to 6.4. I've tried tracking down the changes in yum between 6.3 (3.2.29-30) and 6.4 (3.2.29-40) and do not see any changes that seem like they would result in this behavior. I am not sure what the above error means, or where to begin on resolving this problem. Thoughts? Thanks for the help! -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca.cecchi at gmail.com Tue Jul 9 09:10:13 2013 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 9 Jul 2013 11:10:13 +0200 Subject: [rhelv6-list] clustat -fx command doesn't detect quorum disk Message-ID: Hello, with rgmanager-3.0.12.1-12.el6.x86_64 on RHEL 6.3 and same configuration as in RHEL 5.9 the command clustat -fx returns somwthing like: $ sudo clustat -fx So that my checks on cluster status return error because don't understand that the quorum disk is a particular host.... On 5.9 with similar configuration I get: quorum disk lines are for both somthing like this: Any clue? Thanks in advance, Gianluca From yskchu at gmail.com Thu Jul 11 05:27:03 2013 From: yskchu at gmail.com (Kelvin Chu) Date: Thu, 11 Jul 2013 13:27:03 +0800 Subject: [rhelv6-list] RHEL versions, kernel versions, and supportability In-Reply-To: References: Message-ID: Hi guys, Have a question on red hat version and kernel version supportability. I understand that each minor release comes with an updated kernel; for example, 6.2 comes with 2.6.32-220, and 6.3 comes with 2.6.32-279, and 6.4 comes with 32-358 and 6.0 originally came with 32-71. Is using a old kernel for a newer release supported? Thanks, Kelvin -------------- next part -------------- An HTML attachment was scrubbed... URL: From brilong at cisco.com Thu Jul 11 12:36:49 2013 From: brilong at cisco.com (Brian Long (brilong)) Date: Thu, 11 Jul 2013 12:36:49 +0000 Subject: [rhelv6-list] RHEL versions, kernel versions, and supportability In-Reply-To: References: Message-ID: On Jul 11, 2013, at 1:27 AM, Kelvin Chu > wrote: Hi guys, Have a question on red hat version and kernel version supportability. I understand that each minor release comes with an updated kernel; for example, 6.2 comes with 2.6.32-220, and 6.3 comes with 2.6.32-279, and 6.4 comes with 32-358 and 6.0 originally came with 32-71. Is using a old kernel for a newer release supported? Nope. Red Hat implements a kernel ABI (application binary interface) which means there is a way to compile kernel modules which are universal between all kernel versions in a specific RHEL release. This means vendors can provide a single kernel module and it _should_ work across any kernel in RHEL 6. VMware does this with their "Guest Tools", for example. For this reason, you should try to run the latest kernel possible assuming there are no regressions. You should definitely test your applications when new kernels are released because most of the time you'll want the security updates and possible bug-fixes provided. /Brian/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.j.smith at ieee.org Thu Jul 11 13:18:38 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Thu, 11 Jul 2013 09:18:38 -0400 Subject: [rhelv6-list] RHEL versions, kernel versions, and supportability In-Reply-To: References: Message-ID: On Thu, Jul 11, 2013 at 1:27 AM, Kelvin Chu wrote: > Hi guys, > Have a question on red hat version and kernel version supportability. > > I understand that each minor release comes with an updated kernel; for > example, 6.2 comes with 2.6.32-220, and 6.3 comes with 2.6.32-279, and 6.4 > comes with 32-358 and 6.0 originally came with 32-71. > > Is using a old kernel for a newer release supported? > It is _strongly_ recommended that you use the kernel build appropriate for the user space. E.g., RHEL 6.4 userspace with 2.6.32-358[.y.z] (which are 6.4) [errata] kernels. Yes, the RHEL kABI exists so many interfaces are mitigated against change throughout the entire RHEL lifecycle. That's so most IHV/ISV software and even kernel modules can remain unchanged, _if_ they are written to the kABI, and do not use structures outside of it (more on that in a bit). However ... with each new Update (aka Point Release), in addition to Security Errata (RHSA) and limited Bugfix Errata (RHBA) that are normally released mid-Update (same Point Release), there are more Bugfix Errata (RHBA) and Enhancement Errata (RHEA) for the new Update (new Point Release). These additional changes -- especially Enhancements which are always by and for Customers -- may require newer and/or different userspace to support. So ... coming back to IHV/ISVs who go "outside" the kABI ... is that why you're looking to stick with an old kernel on a new Update userspace? E.g., RHEL 6.4 userspace with 2.6.32-279[.y.z] (6.3 series) [errata] kernel because your IHV or ISV requires the 6.3 kernel series for their modules? If so ... you should get Extended Update Support (EUS) entitlement(s) for your system(s). [1] EUS started out, and is also known as, the "Z-stream," where errata kernels (and select other packages, as required) are maintained for an older Update (Point Release) after a newer Update comes out. E.g., RHEL 6.3 EUS would continue to have newer 2.6.32-279.y.z kernels, even after 6.4 was released and 2.6.32-358[.y.z] builds now the "HEAD" tag. This Z-stream mitigates changes to select Security fixes and only required Bugfix errata to mitigate any changes to the kernel and its structures. So ... EUS and its Z-stream mitigates problems with IHVs and ISVs that go outside the Red Hat kABI and modify other structures and interfaces. All the while EUS releases are still maintained as if the old Update was still the "HEAD" tag. It gives your IHV and ISV 18-24+ months to migrate to a newer Update, much longer than the typical Update cycle of 6-9 months. In fact, some IHV and ISVs virtually _never_ seem to even release during the "HEAD" update, so EUS is absolutely required to deal with such situations. See the RHEL Lifecycle document for more information on typical release cycles, including EUS dates for RHEL6. [2] EUS is very advantageous in Enterprises, and I've worked in several where policy _required_ all RHEL systems to be subscribed to the EUS channels unless there was an exception, or the solution itself always required the "HEAD" Update (latest Point Release). EUS and access to the Z-streams are a very minimal charge beyond a RHEL entitlement, and I highly recommend it to improve management and other aspects of your enterprise if you are finding you are deploying older Updates. Again, if you have troubling IHV and ISV solutions that require older Updates that are not receiving security updates like the "HEAD" Update, you really should get your enterprise on EUS. Every single enterprise, and even some smaller shops, I've been at that went EUS have never wanted to go back, and cannot believe they didn't know about it before. ;) -- bjs P.S. If you do _not_ have EUS, you _should_ be on the latest Update (latest Point Release), kernel and userspace. E.g., everyone without an EUS subscription should be on RHEL 6.4 (or RHEL 5.9 in the case of RHEL5 -- ignoring ELS for RHEL3/4, which is different than EUS). If not, then issues may arise and/or you may accidentally "re-cover ground" with Red Hat GSS that has already been addressed in the new Update, and would have solved your issue. I've seen this several times myself, hence why this is my strong, professional recommendation. YMMV. [1] Extended Update Support - http://www.redhat.com/products/enterprise-linux-add-ons/extended-update-support/ [2] Red Hat Enterprise Linux Life Cycle - https://access.redhat.com/support/policy/updates/errata/ "In Red Hat Enterprise Linux 6, EUS is available for the following minor releases: - 6.0 (ends November 30, 2012) - 6.1 (ends May 31, 2013) - 6.2 (ends December 31, 2013) - 6.3 (ends June 30, 2014) - 6.4 (ends February 28, 2015)" -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith -------------- next part -------------- An HTML attachment was scrubbed... URL: From we.hopkins at gmail.com Wed Jul 17 18:59:38 2013 From: we.hopkins at gmail.com (William Hopkins) Date: Wed, 17 Jul 2013 14:59:38 -0400 Subject: [rhelv6-list] LDAP without the cruft Message-ID: <20130717185938.GA28374@liamdesk.na.acncorp.com> Hello all, Is it possible in RHEL6 to have LDAP authentication substantially similar to how it was configured in RHEL5? I don't wish to run SSSD, D-BUS, NSCD, or NSLCD. I don't need anything cached, I don't need anything mediated or federated, I don't want to run additional services on all of my servers. I have as yet not completely understood the new model, but thought I would reach out to the community with this question directly. I have a working LDAP-over-TLS solution currently in my RHEL5 environment that involves installing nss_ldap and modifying one configuration file. Thanks, -- William Hopkins -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From corey.kovacs at gmail.com Thu Jul 18 00:55:23 2013 From: corey.kovacs at gmail.com (Corey Kovacs) Date: Wed, 17 Jul 2013 18:55:23 -0600 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <20130717185938.GA28374@liamdesk.na.acncorp.com> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> Message-ID: Absolutely, just configure it the same way. by the way, configuring authentication is as easy as using the authconfig tool in non-ui mode just as is done during a kickstart. On Wed, Jul 17, 2013 at 12:59 PM, William Hopkins wrote: > Hello all, > > Is it possible in RHEL6 to have LDAP authentication substantially similar > to > how it was configured in RHEL5? I don't wish to run SSSD, D-BUS, NSCD, or > NSLCD. I don't need anything cached, I don't need anything mediated or > federated, I don't want to run additional services on all of my servers. I > have > as yet not completely understood the new model, but thought I would reach > out > to the community with this question directly. I have a working > LDAP-over-TLS > solution currently in my RHEL5 environment that involves installing > nss_ldap > and modifying one configuration file. > > Thanks, > > -- > William Hopkins > > _______________________________________________ > 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 i.mortimer at uq.edu.au Thu Jul 18 01:26:20 2013 From: i.mortimer at uq.edu.au (Ian Mortimer) Date: Thu, 18 Jul 2013 11:26:20 +1000 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <20130717185938.GA28374@liamdesk.na.acncorp.com> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> Message-ID: <51E7443C.5030501@uq.edu.au> On 18/07/13 04:59, William Hopkins wrote: > Is it possible in RHEL6 to have LDAP authentication substantially similar to > how it was configured in RHEL5? I managed to configure auth from a very old ldap server with: authconfig --enableshadow --enablemd5 --enableldap --enableldapauth --disablesssd --disablesssdauth --enableforcelegacy --disableldaptls --ldapserver=ldap.net --ldapbasedn=dc=... -- Ian i.mortimer at uq.edu.au Ian Mortimer Tel: +61 7 3346 8528 Science IT University of Queensland From we.hopkins at gmail.com Thu Jul 18 01:44:13 2013 From: we.hopkins at gmail.com (William Hopkins) Date: Wed, 17 Jul 2013 21:44:13 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <51E7443C.5030501@uq.edu.au> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> Message-ID: <20130718014413.GC5991@vinzclortho> On 07/18/13 at 11:26am, Ian Mortimer wrote: > On 18/07/13 04:59, William Hopkins wrote: > > >Is it possible in RHEL6 to have LDAP authentication substantially similar to > >how it was configured in RHEL5? > > I managed to configure auth from a very old ldap server with: > > authconfig --enableshadow --enablemd5 --enableldap --enableldapauth > --disablesssd --disablesssdauth --enableforcelegacy --disableldaptls > --ldapserver=ldap.net --ldapbasedn=dc=... > > Do you have NSCLD running? I can't seem to get it running without. It seems the new nss-pam-ldapd (replacement for nss_ldap) relies on the running daemon rather than calling directly to the LDAP server. I've also tried installing a copy of nss_ldap from a RHEL5 server and bizarrely it didn't work.. the nss_ldap component does but the pam_ldap doesn't. Of course I'm sure you're aware how hard it can be to get reasonable troubleshooting data out of pam. -- William -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From we.hopkins at gmail.com Thu Jul 18 01:46:00 2013 From: we.hopkins at gmail.com (William Hopkins) Date: Wed, 17 Jul 2013 21:46:00 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: References: <20130717185938.GA28374@liamdesk.na.acncorp.com> Message-ID: <20130718014600.GD5991@vinzclortho> On 07/17/13 at 06:55pm, Corey Kovacs wrote: > > On Wed, Jul 17, 2013 at 12:59 PM, William Hopkins wrote: > > > Hello all, > > > > Is it possible in RHEL6 to have LDAP authentication substantially similar > > to > > how it was configured in RHEL5? I don't wish to run SSSD, D-BUS, NSCD, or > > NSLCD. I don't need anything cached, I don't need anything mediated or > > federated, I don't want to run additional services on all of my servers. I > > have > > as yet not completely understood the new model, but thought I would reach > > out > > to the community with this question directly. I have a working > > LDAP-over-TLS > > solution currently in my RHEL5 environment that involves installing > > nss_ldap > > and modifying one configuration file. > > > Absolutely, just configure it the same way. by the way, configuring > authentication is as easy as using the authconfig tool in non-ui mode just > as is done during a kickstart. Please don't top post to mailing lists. At any rate, this is helpful to know. Can you see if you have NSCLD running on a server you've successfully configured for LDAP? The package doesn't set it to start on boot but I can't seem to get LDAP working without it. -- William -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From i.mortimer at uq.edu.au Thu Jul 18 02:28:27 2013 From: i.mortimer at uq.edu.au (Ian Mortimer) Date: Thu, 18 Jul 2013 12:28:27 +1000 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <20130718014413.GC5991@vinzclortho> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> Message-ID: <51E752CB.8060107@uq.edu.au> On 18/07/13 11:44, William Hopkins wrote: > Do you have NSCLD running? Yes. -- Ian i.mortimer at uq.edu.au Ian Mortimer Tel: +61 7 3346 8528 Science IT University of Queensland From we.hopkins at gmail.com Thu Jul 18 02:48:26 2013 From: we.hopkins at gmail.com (William Hopkins) Date: Wed, 17 Jul 2013 22:48:26 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <51E752CB.8060107@uq.edu.au> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> Message-ID: <20130718024826.GE5991@vinzclortho> On 07/18/13 at 12:28pm, Ian Mortimer wrote: > On 18/07/13 11:44, William Hopkins wrote: > > >Do you have NSCLD running? > > Yes. > My intention is to authenticate using LDAP without running NSCLD. That was in my original post. But thanks for the update. -- William -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From wes.hardin at maximintegrated.com Thu Jul 18 15:31:33 2013 From: wes.hardin at maximintegrated.com (Wes Hardin) Date: Thu, 18 Jul 2013 10:31:33 -0500 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <20130718024826.GE5991@vinzclortho> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> <20130718024826.GE5991@vinzclortho> Message-ID: <51E80A55.8080600@maximintegrated.com> On 07/17/2013 09:48 PM, William Hopkins wrote: > On 07/18/13 at 12:28pm, Ian Mortimer wrote: >> On 18/07/13 11:44, William Hopkins wrote: >> >>> Do you have NSCLD running? >> Yes. >> > My intention is to authenticate using LDAP without running NSCLD. That was in > my original post. But thanks for the update. > Then you need to remove the nss-pam-ldapd package and compile your own NSS LDAP library using the PADL sources. nss-pam-ldapd replaces the old libnss_ldap library with a lightweight NSS library and a daemon. nslcd is the daemon that actually does the lookups. nscld is not cruft. It's new, but it's not unnecessary. Read /usr/share/doc/nss-pam-ldapd-0.7.5/README if you want more information. --wes From we.hopkins at gmail.com Thu Jul 18 18:41:42 2013 From: we.hopkins at gmail.com (William Hopkins) Date: Thu, 18 Jul 2013 14:41:42 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <51E80A55.8080600@maximintegrated.com> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> <20130718024826.GE5991@vinzclortho> <51E80A55.8080600@maximintegrated.com> Message-ID: <20130718184142.GB18421@liamdesk.na.acncorp.com> On 07/18/13 at 10:31am, Wes Hardin wrote: > On 07/17/2013 09:48 PM, William Hopkins wrote: > >On 07/18/13 at 12:28pm, Ian Mortimer wrote: > >>On 18/07/13 11:44, William Hopkins wrote: > >> > >>>Do you have NSCLD running? > >>Yes. > >> > >My intention is to authenticate using LDAP without running NSCLD. That was in > >my original post. But thanks for the update. > > > Then you need to remove the nss-pam-ldapd package and compile your > own NSS LDAP library using the PADL sources. > > nss-pam-ldapd replaces the old libnss_ldap library with a > lightweight NSS library and a daemon. nslcd is the daemon that > actually does the lookups. nscld is not cruft. It's new, but it's > not unnecessary. > I see it is clearly now necessary, but that doesn't make it not cruft. There is a decided direction in Linux engineering going towards more system daemons and more layers of abstraction (D-BUS, GConf, Dconf, gsettings, consolekit, network-manager, policykit, udisks, upower, etc. etc. etc.) I understand for many of them they gain popularity because they make desktop maintenance easier, but I resist their encroachment in the server world; philosophically they don't line up with the UNIX/Linux mindset. Luckily, in the Linux world we are still allowed to choose. Anyway, that's my little rant on that subject, thanks for your help. -- William -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From KCollins at chevron.com Fri Jul 19 04:16:35 2013 From: KCollins at chevron.com (Collins, Kevin [Contractor Acquisition Program]) Date: Fri, 19 Jul 2013 04:16:35 +0000 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <20130718184142.GB18421@liamdesk.na.acncorp.com> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> <20130718024826.GE5991@vinzclortho> <51E80A55.8080600@maximintegrated.com> <20130718184142.GB18421@liamdesk.na.acncorp.com> Message-ID: <6F56410FBED1FC41BCA804E16F594B0B32E057DB@chvpkw8xmbx05.chvpk.chevrontexaco.net> Just as an FYI, the new model with nslcd makes for a much more resilient model when your LDAP server(s) have issues. In the prior model, if one LDAP server has an issue there is the potential for MANY processes to be directly impacted by timeouts. With the new model, only the nslcd process has to face the timeout... If you have ever had to deal with those problems you will definitely appreciate nslcd :) Kevin -----Original Message----- From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of William Hopkins Sent: Thursday, July 18, 2013 11:42 AM To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list Subject: Re: [rhelv6-list] LDAP without the cruft On 07/18/13 at 10:31am, Wes Hardin wrote: > On 07/17/2013 09:48 PM, William Hopkins wrote: > >On 07/18/13 at 12:28pm, Ian Mortimer wrote: > >>On 18/07/13 11:44, William Hopkins wrote: > >> > >>>Do you have NSCLD running? > >>Yes. > >> > >My intention is to authenticate using LDAP without running NSCLD. That was in > >my original post. But thanks for the update. > > > Then you need to remove the nss-pam-ldapd package and compile your > own NSS LDAP library using the PADL sources. > > nss-pam-ldapd replaces the old libnss_ldap library with a > lightweight NSS library and a daemon. nslcd is the daemon that > actually does the lookups. nscld is not cruft. It's new, but it's > not unnecessary. > I see it is clearly now necessary, but that doesn't make it not cruft. There is a decided direction in Linux engineering going towards more system daemons and more layers of abstraction (D-BUS, GConf, Dconf, gsettings, consolekit, network-manager, policykit, udisks, upower, etc. etc. etc.) I understand for many of them they gain popularity because they make desktop maintenance easier, but I resist their encroachment in the server world; philosophically they don't line up with the UNIX/Linux mindset. Luckily, in the Linux world we are still allowed to choose. Anyway, that's my little rant on that subject, thanks for your help. -- William From b.j.smith at ieee.org Fri Jul 19 05:55:46 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Fri, 19 Jul 2013 01:55:46 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <20130718184142.GB18421@liamdesk.na.acncorp.com> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> <20130718024826.GE5991@vinzclortho> <51E80A55.8080600@maximintegrated.com> <20130718184142.GB18421@liamdesk.na.acncorp.com> Message-ID: William Hopkins wrote: > I understand for many of them they gain popularity because they make > desktop maintenance easier, but I resist their encroachment in the server > world; > This is probably the most over-stated falsehood. Most of the new solutions actually target Server solutions more better than Desktop integration. There is a heavy request for many features, including resource and other management, not just services. E.g., when it comes to system control and management, I've been at sites who run either Cluster Suite (Luci/Ricci) on a standalone system just to track/handle resource changes, or monit from EPEL as an alternative. Both are not remotely as effective as something that uses the pre-existing, message passing in the kernel and device layers, let alone looks at sockets to ... gasp ... verifies if a service is actually running. It's also going to finally standardize monitoring tools, instead of a lot of different solutions out there that "poll" things (quite inefficient). More on the system security side, SSSD finally updates some very, very legacy and aged, disseparate modules, and vastly improve them. E.g., in its LDAP modules, SSSD actually uses more updated OpenLDAP client libraries than some of the older ones (some are way out of compliance too). Even many in the Debian world has a lot of praise for SSSD. I know many Ubuntu users who don't want to go back. ;) philosophically they don't line up with the UNIX/Linux mindset. > And probably the second most over-stated falsehood. This was also stated when System-V like init came about during UNIX standardization efforts in the '80s and early '90s. And then it was stated again when people were Red Hat "pushing SysV-init on everyone" in the later '90s. Many other UNIX flavors have moved to modern system control and management solutions, and dropped "static" shell files as well. > Luckily, in the Linux world we are still allowed to choose. > Depends. A lot of the old solutions just don't do much in comparison. They don't have features or modules for many things. And some are way outta compliance in several respects. > Anyway, that's my little rant on that subject, thanks for your help. > Unfamiliarity bothers a lot of people. But most of the "common arguments" are actually falsehoods that have no basis in UNIX history, only UNIX assumption. ;) -- bjs -------------- next part -------------- An HTML attachment was scrubbed... URL: From we.hopkins at gmail.com Fri Jul 19 14:43:43 2013 From: we.hopkins at gmail.com (William Hopkins) Date: Fri, 19 Jul 2013 10:43:43 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> <20130718024826.GE5991@vinzclortho> <51E80A55.8080600@maximintegrated.com> <20130718184142.GB18421@liamdesk.na.acncorp.com> Message-ID: <20130719144343.GA22654@liamdesk.na.acncorp.com> On 07/19/13 at 01:55am, Bryan J Smith wrote: > William Hopkins wrote: > > Both are not remotely as effective as something that uses the pre-existing, > message passing in the kernel and device layers, let alone looks at sockets > to ... gasp ... verifies if a service is actually running. It's also going > to finally standardize monitoring tools, instead of a lot of different > solutions out there that "poll" things (quite inefficient). I pretty much discount anyone who uses "gasp" as a rhetorical device. You're also pretty na?ve if you think whatever you're talking about will be the silver bullet for standarization. > More on the system security side, SSSD finally updates some very, very > legacy and aged, disseparate modules, and vastly improve them. E.g., in > its LDAP modules, SSSD actually uses more updated OpenLDAP client libraries > than some of the older ones (some are way out of compliance too). This is a good point. Shame that things like nss-pam-ldapd will gain so much acceptance because they're fixing problems, forcing others to live with the poor engineering decisions they've made. I don't really enjoy the choice I'm presented with between outdated systems or new, poorly designed ones. > > Even many in the Debian world has a lot of praise for SSSD. I know many > Ubuntu users who don't want to go back. ;) Interesting community to highlight, given Ubuntu-ers are the laziest linux users anywhere. I don't begrudge them their pretty and automatic 'don't think about it' interfaces, but I will resist any efforts to bring them to the server world. > > philosophically they don't line up with the UNIX/Linux mindset. > > > And probably the second most over-stated falsehood. This was also stated > when System-V like init came about during UNIX standardization efforts in > the '80s and early '90s. And then it was stated again when people were Red > Hat "pushing SysV-init on everyone" in the later '90s. "people complained before and were wrong.. they must be wrong now" I'm not afraid of change. I am arguing that these systems are poorly designed and make system administration more difficult. I do not need to run SSSD, NSLCD, NSCD, D-BUS, upower, udisks, etc. etc. etc. just to have a vanilla system. Some systems are worse than others (gconf is especially a horror from the depths), but nonetheless the new method of running software to add layers of abstraction that then become hard requirements because everyone assumes they'll be present is totally off base and disconnected from the open-world mentality of Linux. > Unfamiliarity bothers a lot of people. But most of the "common arguments" > are actually falsehoods that have no basis in UNIX history, only UNIX > assumption. ;) I'm not surprised any longer that people in IT tend to be very bad at arguing; we all have big egos. But you should be aware that this sentence takes your conclusions as assumed fact, and paints anyone who disagrees as near-luddites afraid of change and unfamiliarity. It's pretty rude. -- William -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From we.hopkins at gmail.com Fri Jul 19 14:59:09 2013 From: we.hopkins at gmail.com (William Hopkins) Date: Fri, 19 Jul 2013 10:59:09 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <6F56410FBED1FC41BCA804E16F594B0B32E057DB@chvpkw8xmbx05.chvpk.chevrontexaco.net> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> <20130718024826.GE5991@vinzclortho> <51E80A55.8080600@maximintegrated.com> <20130718184142.GB18421@liamdesk.na.acncorp.com> <6F56410FBED1FC41BCA804E16F594B0B32E057DB@chvpkw8xmbx05.chvpk.chevrontexaco.net> Message-ID: <20130719145909.GA25228@liamdesk.na.acncorp.com> On 07/19/13 at 04:16am, Collins, Kevin [Contractor Acquisition Program] wrote: > On 18/07/13 11:44, William Hopkins wrote: > > I see it is clearly now necessary, but that doesn't make it not cruft. There is > > a decided direction in Linux engineering going towards more system daemons and > > more layers of abstraction (D-BUS, GConf, Dconf, gsettings, consolekit, > > network-manager, policykit, udisks, upower, etc. etc. etc.) I understand for > > many of them they gain popularity because they make desktop maintenance easier, > > but I resist their encroachment in the server world; philosophically they don't > > line up with the UNIX/Linux mindset. Luckily, in the Linux world we are still > > allowed to choose. Anyway, that's my little rant on that subject, thanks for > > your help. > > Just as an FYI, the new model with nslcd makes for a much more resilient > model when your LDAP server(s) have issues. In the prior model, if one LDAP > server has an issue there is the potential for MANY processes to be directly > impacted by timeouts. With the new model, only the nslcd process has to face > the timeout... > > If you have ever had to deal with those problems you will definitely > appreciate nslcd :) Please don't top post to mailing lists. I know modern clients make that difficult, but still. I am aware of the issues when LDAP goes down; these are best addressed by 1) a proper configuration with LDAP as a secondary auth source with the appropriate timeouts and pam options and 2) a robust LDAP architecture, load balanced or clustered with delegations per-site. These are all described in detail in most LDAP software configuration manuals. LDAP servers, like any other service you are responsible for configuring and providing, require good engineering upfront. NSLCD was designed client-server for a variety of reasons and I assume with good intentions. It still isn't a good idea. And at the end of the day, I am less interested in convincing the current linux community to follow good practices than I am in finding out how to configure my environment in accordance with my own principles. So I was asking for technical assistance on how to avoid NSLCD, not reasons why you think NSLCD is a good idea. -- William -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: Digital signature URL: From b.j.smith at ieee.org Fri Jul 19 15:26:31 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Fri, 19 Jul 2013 11:26:31 -0400 Subject: [rhelv6-list] LDAP without the cruft In-Reply-To: <20130719144343.GA22654@liamdesk.na.acncorp.com> References: <20130717185938.GA28374@liamdesk.na.acncorp.com> <51E7443C.5030501@uq.edu.au> <20130718014413.GC5991@vinzclortho> <51E752CB.8060107@uq.edu.au> <20130718024826.GE5991@vinzclortho> <51E80A55.8080600@maximintegrated.com> <20130718184142.GB18421@liamdesk.na.acncorp.com> <20130719144343.GA22654@liamdesk.na.acncorp.com> Message-ID: On Fri, Jul 19, 2013 at 10:43 AM, William Hopkins wrote: > I pretty much discount anyone who uses "gasp" as a rhetorical device. It's not rhetorical, it's literal. ;) I.e., I've heard a few when I showed people it at work (did a LUG presentation a few months back to a not-so-Red-Hat-loving group). That's when and why I use the word "gasp" in a phrase. It's when people have that "epiphany" they didn't recognize before, until they saw it first-hand, and then it clicked. That usually changes their view rather quickly, and better than anything I could say. First-hand experience with someone familiar always change everything. People can argue meta -- from not liking a saracasm to just disliking an individual maintainer -- but that does nothing. In fact, one of my favorite, recent retorts to such was made by one of the Arch maintainers. [1] But until people actually get into the technical meat, and reflect on actual history and not assumption, then we can move forward. Technologists want to debate on technical merits, not meta-ones or assumptions. It's difficult to deal with assumptions and unfamiliarity. And the common complaints are they are for X and not Y as well as not being UNIX/Linux-like. But until people adopt them and understand the improvements, they will never see this. But at least the UNIX/Linux world changes on decades, instead of years (Microsoft) and even sometimes just months (Google). ;) You're also pretty na?ve if you think whatever you're talking about will be > the silver > bullet for standarization. > I never argued "standardization." I only argued what customers have been asking for, first-hand, on-site ... for servers, not desktops. Arch, SuSE and many others are adopting the new *d solutions as well. There are technical reasons why, and not just conformity. This is a good point. Shame that things like nss-pam-ldapd will gain so much > acceptance because they're fixing problems, forcing others to live with > the > poor engineering decisions they've made. Compliance and certification is a huge driver ... everything from centralizing user/resource objects/attributes to signatures on DNS zones. Many legacy solutions are based on some of the exact same codebases, but they are legacy. And they have not adopted new interfaces that have been in the system for years, so they are out-of-date. A lot of times people complain about changing something, when it really hasn't. Some device control, message passing and other things might be newer, but sockets, resources and others solutions are not, they *are* the most legacy of UNIX/Linux. We've just never implemented solutions over the years to handle them proper ... until now. I don't really enjoy the choice I'm presented with between outdated systems > or new, poorly designed ones. > Again ... is "poorly designed" an argument made from usage? Or unfamiliarity? I can understand the former, and completely respect it. But if one has not learned how to deploy the new solution, evaluated it fully, and seen what happens when the older solutions don't address the needs of users, then it makes a little more sense why the new solution came about. Interesting community to highlight, given Ubuntu-ers are the laziest linux > users anywhere. I don't begrudge them their pretty and automatic 'don't > think > about it' interfaces, but I will resist any efforts to bring them to the > server > world. > I won't argue with you about the typical "Ubuntu fanboy" that overstates all sorts of "innovations" that were in Fedora first and (c) Red Hat. There's always going to be a backlash against such individuals because their pulling over the "marketing trash" from the traditional, commercial software world ... and I left for a reason. However, commercial Canonical and Ubuntu LTS users and administrators are some of the most capable sysadmins (and several know Red Hat too). Several, including one of my favorite colleagues works for Canonical, are extremely knowledgeable, and recognize Fedora/Red Hat developments for their merit. So I was merely pointing out that the new stacks and modular solutions -- which use some of the same codebase as old stuff, just with more capability and newer libraries -- is being adopted out of merit. Merit is what is the foundation of Fedora and Red Hat. It always has been. It always will be. And if anything, Red Hat has had a history of changing things where everyone "rides the coattails" and forgets 3-5 years down the road and "conveniently forget" they were complaining in the first place. E.g., GLibC (threading), ANSI C++ (long-term ABI), NPTL (Watson anyone?), etc... "people complained before and were wrong.. they must be wrong now" > People have been complaining about a lot of Red Hat things, typically several big ones per year. > I'm not afraid of change. I am arguing that these systems are poorly > designed > and make system administration more difficult. I do not need to run SSSD, > NSLCD, NSCD, D-BUS, upower, udisks, etc. etc. etc. just to have a vanilla > system. Again, unfamiliarity. E.g., SSSD and NSCD do _not_ work together, and NSCD should _not_ be used with SSSD. ;) SSSD's caching is designed to be a more deterministic superset of NSCD (and even Winbindd caching for that matter). It works extremely well and has solved several problems at many sites I've been at. SSSD itself is really just a modular system with a superset of updated libraries and capabilities, along with a single point of caching/control. I've also deployed SSSD and when I had problems, it's only because the site configuration was not compliant with their own security policies. E.g., before, older solutions would blindly not do certificate checking and various authentication, things required and poorly presumed to be working. With SSSD, you have to set flags not to, and it's very good at ensuring compliance, while still being able to set an exception. Once I document this at this one client, the IT department was ecstatic, and loved SSSD from then on. They learned the few option I taught them, and never went back. > Some systems are worse than others (gconf is especially a horror from > the depths), Again, many new solutions are not for desktop, but server. The desktop just ends up adopting some of the server components, with others that are desktop-only (e.g., gconf). but nonetheless the new method of running software to add layers of abstraction that then become hard requirements because everyone assumes > they'll be present is totally off base and disconnected from the open-world > mentality of Linux. > I'm not going to convince you. You're just going to have to learn and evaluate the solutions and decide. I know SSSD seems daunting, but it's not. And authconfig really does a great job. I'm not surprised any longer that people in IT tend to be very bad at > arguing; > we all have big egos. But you should be aware that this sentence takes your > conclusions as assumed fact, and paints anyone who disagrees as > near-luddites > afraid of change and unfamiliarity. It's pretty rude. > Well ... I apologize. But I see a lot of meta-arguments combined with unfamiliarity. As I said, I think the Arch maintainer pegged it very well. We no longer focus on the technology, and real, customer and user needs why changes come about. We focus on the meta-arguments, alleged UNIX history, and even demonization of individuals (not saying you did, but it's common in these cases). Best of luck, and if you ever need assistance with SSSD, IPA, the new *d services, etc..., please feel free to ask. Don't know if anyone will convince you on the more "meta" arguments, but best of luck regardless of what you deploy. -- bjs [1] https://mailman.archlinux.org/pipermail/arch-dev-public/2012-August/023392.html "we have a patch to make systemd optional at runtime, we request users to test it, and instead of testing it we end up with a 300+ posts thread about how bad Lennart is, with nearly no-one trying to investigate what is wrong about the patch and in which situations it doesn't work." Pretty much sums it up better than I ever could. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnmcn1 at gmail.com Sat Jul 27 07:28:52 2013 From: johnmcn1 at gmail.com (John McNulty) Date: Sat, 27 Jul 2013 08:28:52 +0100 Subject: [rhelv6-list] RHEL versions, kernel versions, and supportability In-Reply-To: References: Message-ID: On 11 July 2013 14:18, Bryan J Smith wrote: > On Thu, Jul 11, 2013 at 1:27 AM, Kelvin Chu wrote: > >> Is using a old kernel for a newer release supported? >> > It is _strongly_ recommended that you use the kernel build appropriate for > the user space. > While it's recommended, the question was whether installing new user space rpms without updating the kernel is supported, and the answer is yes. Red Hat recently published this article to clear up confusion on this topic. https://access.redhat.com/site/solutions/401413 Specifically ... "Red Hat does not require a system to be entirely composed of packages from a single minor release, but many regard the kernel version and the contents of /etc/redhat-release as two data points that assist in labeling a minor release without deeper introspection into additional userspace package updates. Others have stated that minor releases are just hundreds of errata published on the same day and labeled as a release for convenience. - For example, a system may have the kernel installed from Red Hat Enterprise Linux 6.1, but user space packages installed from Red Hat Enterprise Linux 6.2. This would still be considered fully supported." --John -------------- next part -------------- An HTML attachment was scrubbed... URL: From evilensky at gmail.com Sun Jul 28 14:49:23 2013 From: evilensky at gmail.com (Eugene Vilensky) Date: Sun, 28 Jul 2013 09:49:23 -0500 Subject: [rhelv6-list] _rpm.error: rpmdb open failed In-Reply-To: <51D6D484.3070302@jonesmail.me> References: <51D6D484.3070302@jonesmail.me> Message-ID: On Fri, 05 Jul 2013 09:13:24 -0500, Russell Jones wrote: > > Hi all, > > > I have an issue on 6.4 where doing a "yum install" into a rootdir > utilizing RHEL 5 packages on a RHEL 6.4 box results in the following > error: > > > mi = ts.dbMatch('name', name) > > _rpm.error: rpmdb open failed > > yum invocation failed > > > > > Doing the exact same command on a RHEL 6.3 box works fine. This only > happens after I upgrade the server to 6.4. I've tried tracking down > the changes in yum between 6.3 (3.2.29-30) and 6.4 (3.2.29-40) and > do not see any changes that seem like they would result in this > behavior. > > I am not sure what the above error means, or where to begin on > resolving this problem. Thoughts? > > What happens if you try to install with rpm -i ? From b.j.smith at ieee.org Mon Jul 29 02:53:29 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Sun, 28 Jul 2013 22:53:29 -0400 Subject: [rhelv6-list] RHEL versions, kernel versions, and supportability In-Reply-To: References: Message-ID: On Sat, Jul 27, 2013 at 3:28 AM, John McNulty wrote: > On 11 July 2013 14:18, Bryan J Smith wrote: > >> On Thu, Jul 11, 2013 at 1:27 AM, Kelvin Chu wrote: >> >>> Is using a old kernel for a newer release supported? >>> >> It is _strongly_ recommended that you use the kernel build appropriate >> for the user space. >> > > While it's recommended, the question was whether installing new user space > rpms without updating the kernel is supported, and the answer is yes. Red > Hat recently published this article to clear up confusion on this topic. > https://access.redhat.com/site/solutions/401413 > Apparently, you ignored my final statements on the matter. ;) 'If not, then issues may arise and/or you may accidentally "re-cover ground" with Red Hat GSS that has already been addressed in the new Update, and would have solved your issue. I've seen this several times myself, hence why this is my strong, professional recommendation. YMMV.' There's a reason why I took the time to explain all of the details, as well as point out the existence of the Extended Update Support (EUS) entitlement. In the overwhelming majority of cases, it's an IHV/ISV with proprietary software that goes outside the kABI that updates their software too slow. EUS and its Z-streams were designed to mitigate those issues. Again, running newer userspace with older kernels may not only have issues, but cause one to open tickets and file Bugzillas for issues already addressed. And, again, this is from _first-hand_ experience. In several cases, EUS received similar kernel updates, something that would not happen by running and older, unsupported kernel without EUS and its errata kernels (before we even consider security). -- bjs -------------- next part -------------- An HTML attachment was scrubbed... URL: From tlyons9 at csc.com Mon Jul 29 16:26:31 2013 From: tlyons9 at csc.com (Terry B Lyons) Date: Mon, 29 Jul 2013 12:26:31 -0400 Subject: [rhelv6-list] _rpm.error: rpmdb open failed In-Reply-To: References: , <51D6D484.3070302@jonesmail.me> Message-ID: An HTML attachment was scrubbed... URL: