Re: [CentOS] Firefox fails to authenticate .mil sites with New DoD CAC
On Thu, 2014-12-04 at 08:08 -0500, mark wrote: On 12/03/14 17:34, Cal Webster wrote: Can anyone help with getting the new DoD CACs (Smart Card) to work in CentOS 6.6? I don't use it for console logins, only for email and .mil web sites. I recently had to get a new DoD CAC (Smart Card) when one of the buildings I work in upgraded their security system. My old CAC was working fine prior to this for signing and encrypting email and for authenticating to various DoD (.mil) sites from the Internet using the coolkey libraries. Dunno 'bout the new CaC keys, but they upgraded our PIV cards to 128? 256? I forget, earlier this year, and I *think* I remember my manager pushing an enhancement on upstream, and since then we've had no trouble with coolkey accessing them. The two *should* be identical. Was source for this upstream enhancement released to the community? Not sure what you meant by The two - you mean coolkey and cackey? snip I've tried installing and loading the latest cackey libraries (see I know nothing about cackey libraries, but it's possible that, and pcscd are arguing. I don't see pcscd installed. pcsc-lite-1.5.2-14.el6.x86_64 (listed on original post) contains pcscd. Sure that's possible but I see nothing to support that in the system logs. I just got a cackey developer contact on forge.mil today from a Civil Svc engineer who does have access so I'll send him my data too. Thanks Mark. mark snip More relevant information below... Smart Card Reader: SCM Microsystems Inc. SCR3310 USB Smart Card Reader (21120628202509) 00 00-0 Old CAC:GEMAL TO TOPDL GX4 144 New CAC:GD FIPS 201 SCE 3.2 [root@inet3 ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@inet3 ~]# uname -a Linux inet3 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@inet3 ~]# Installed Packages coolkey.i686 1.1.0-32.el6@base coolkey.x86_64 1.1.0-32.el6@base firefox.i686 31.2.0-3.el6.centos @updates firefox.x86_64 31.2.0-3.el6.centos @updates thunderbird.x86_64 31.2.0-3.el6.centos @updates pcsc-lite.x86_64 1.5.2-14.el6@base pcsc-lite-devel.x86_64 1.5.2-14.el6@base pcsc-lite-libs.x86_64 1.5.2-14.el6@base nss.i686 3.16.1-14.el6 @base nss.x86_64 3.16.1-14.el6 @base nss-devel.x86_64 3.16.1-14.el6 @base nss-softokn.i686 3.14.3-18.el6_6 @updates nss-softokn.x86_64 3.14.3-18.el6_6 @updates nss-softokn-devel.x86_64 3.14.3-18.el6_6 @updates nss-softokn-freebl.i6863.14.3-18.el6_6 @updates nss-softokn-freebl.x86_64 3.14.3-18.el6_6 @updates nss-softokn-freebl-devel.x86_643.14.3-18.el6_6 @updates nss-sysinit.x86_64 3.16.1-14.el6 @base nss-tools.x86_64 3.16.1-14.el6 @base nss-util.i686 3.16.1-3.el6@base nss-util.x86_643.16.1-3.el6@base nss-util-devel.x86_64 3.16.1-3.el6@base [root@inet3 ~]# modutil -list -dbdir /etc/pki/nssdb Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. CoolKey PKCS #11 Module library name: libcoolkeypk11.so slots: 1 slot attached status: loaded slot: SCM Microsystems Inc. SCR3310 USB Smart Card Reader (21120628202 token: WEBSTER.CALVIN.DALE.9427154028 3. cackey library name: libcackey.so slots: 2 slots attached status: loaded slot: CACKey Slot token: WEBSTER.CALVIN.DALE.9427154028 slot: CACKey Slot token: DoD Certificates ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Firefox fails to authenticate .mil sites with New DoD CAC
On Wed, 2014-12-03 at 18:20 -0500, Jason Pyeron wrote: -Original Message- From: centos-boun...@centos.org [mailto:centos-boun...@centos.org] On Behalf Of Cal Webster Sent: Wednesday, December 03, 2014 17:35 To: CentOS List Subject: [CentOS] Firefox fails to authenticate .mil sites with New DoD CAC Can anyone help with getting the new DoD CACs (Smart Card) to work in CentOS 6.6? I don't use it for console logins, only for email and .mil web sites. I recently had to get a new DoD CAC (Smart Card) when one of the buildings I work in upgraded their security system. My old CAC was working fine prior to this for signing and encrypting email and for authenticating to various DoD (.mil) sites from the Internet using the coolkey libraries. After getting my new CAC I am no longer able to authenticate to any DoD sites. I can still sign and encrypt email in Thunderbird via the coolkey libraries but .mil sites either simply display blank pages or raise various errors in firefox. I am prompted for my PIN, which is successfully accepted but I'm not even prompted for which cert to use, like I used to be. Does your system trust CA32? I see Issuer: C=US, O=U.S. Government, OU=DoD, OU=PKI, CN=DOD EMAIL CA-32 Validity Not Before: Nov 24 00:00:00 2014 GMT Not After : Jan 30 23:59:59 2015 GMT Subject: C=US, O=U.S. Government, OU=DoD, OU=PKI, OU=CONTRACTOR, CN=WEBSTER.CALVIN.DALE.1011559383 That's a very good point, Jason. I could not locate that CA in the certs being stored for Firefox. It is, however, listed in the CA store in Thunderbird, which I've had no trouble using with coolkey libs. The trust settings there are all un-checked, though. I had also installed the latest dod_configuration-1.3.7.xpi extension which automatically downloads the latest DoD certs on installation. I assumed it was a complete set. After reading your message I went ahead and clicked the [Update DoD Certs...] button in the add-on preferences too - Still not listed. Apparently this cert is missed during this process. I went ahead and exported the cert from Thunderbird, then imported it into firefox. Now I'm up and running again. It's often the simple things we overlook, which is why it's nice to have a community to bounce things off of. Thanks for the help Jason. I've tried installing and loading the latest cackey libraries (see below) but when I insert my CAC and attempt to login to the module in the Mozilla device manager it completely freezes firefox. Recovery requires killing firefox. If I remove the latest and install the next previous cackey library it works the same as coolkey - doesn't freeze up firefox but never connects to .mil sites. I tried building the cackey RPMs from the source RPMs too but the result is the same. Latest 64-bit cackey: cackey-0.6.8-3522.x86_64.rpm Next previous cackey: cackey-0.6.5-2444.x86_64.rpm I'm pretty sure it has something to do with the newer PIV CAC internal layout. I went through a similar transition when the GEMAL 144 cards came out but the cackey libraries did at least work and coolkey eventually caught up. One thing is for sure... the cackey RPM from forge.mil is not a drop-in replacement for coolkey. The cackey RPM only installs the libraries themselves, nothing else. It doesn't even register them in the nss db I had to do that manually with modutil. I must be missing something... Without direct access to forge.mil it's difficult to troubleshoot cackey. For some silly reason they still require CAC authentication to get the CAC software and drivers and access the forums, etc. Ha. Have you contacted the DOD PKE team for support on that? DISA Tinker AFB OPS List PKE_Support dgisa.tinker.ops.list.pkesupp...@mail.mil No, but thank you for the contact info. Even though I've got my issue resolved, I'd be happy to help iron out the cackey package issues if someone wants. More relevant information below... I'd be grateful for any ideas or advice on this. I desperately need to retrieve vulnerability reports, patches, and other DoD resources. Thanks! Cal Webster I have a GD FIPS 201 SCE 3.2 test CAC from JITC I can attach to VM for debbuging. Thanks but that won't be necessary now unless someone else needs the help. Smart Card Reader: SCM Microsystems Inc. SCR3310 USB Smart Card Reader (21120628202509) 00 00-0 Old CAC:GEMAL TO TOPDL GX4 144 New CAC:GD FIPS 201 SCE 3.2 [root@inet3 ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@inet3 ~]# uname -a Linux inet3 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@inet3 ~]# Installed Packages coolkey.i686 1.1.0-32.el6@base coolkey.x86_64 1.1.0-32.el6@base firefox.i686
Re: [CentOS] Firefox fails to authenticate .mil sites with New DoD CAC
On Thu, 2014-12-04 at 11:22 -0500, Jason Ricles wrote: I thought DoD used RHEL and not Centos, or did Centos did approved DADEMS recently? DoD does use RHEL for the critical infrastructure hosts and in our case for training simulators. The issue here was with a separate non-DoD asset used to retrieve security updates and to conduct research to support engineering efforts on isolated, stand-alone networks. The isolated networks are not allowed to touch the Internet. CentOS 6 (and recently 7) has been approved for engineering labs and certain RD facilities too, BTW - You'll see it if you do a search in DADMS. We do use CentOS for local general purpose servers and workstations. On Wed, Dec 3, 2014 at 5:34 PM, Cal Webster cwebs...@ec.rr.com wrote: Can anyone help with getting the new DoD CACs (Smart Card) to work in CentOS 6.6? I don't use it for console logins, only for email and .mil web sites. I recently had to get a new DoD CAC (Smart Card) when one of the buildings I work in upgraded their security system. My old CAC was working fine prior to this for signing and encrypting email and for authenticating to various DoD (.mil) sites from the Internet using the coolkey libraries. After getting my new CAC I am no longer able to authenticate to any DoD sites. I can still sign and encrypt email in Thunderbird via the coolkey libraries but .mil sites either simply display blank pages or raise various errors in firefox. I am prompted for my PIN, which is successfully accepted but I'm not even prompted for which cert to use, like I used to be. I've tried installing and loading the latest cackey libraries (see below) but when I insert my CAC and attempt to login to the module in the Mozilla device manager it completely freezes firefox. Recovery requires killing firefox. If I remove the latest and install the next previous cackey library it works the same as coolkey - doesn't freeze up firefox but never connects to .mil sites. I tried building the cackey RPMs from the source RPMs too but the result is the same. Latest 64-bit cackey: cackey-0.6.8-3522.x86_64.rpm Next previous cackey: cackey-0.6.5-2444.x86_64.rpm I'm pretty sure it has something to do with the newer PIV CAC internal layout. I went through a similar transition when the GEMAL 144 cards came out but the cackey libraries did at least work and coolkey eventually caught up. One thing is for sure... the cackey RPM from forge.mil is not a drop-in replacement for coolkey. The cackey RPM only installs the libraries themselves, nothing else. It doesn't even register them in the nss db I had to do that manually with modutil. I must be missing something... The Without direct access to forge.mil it's difficult to troubleshoot cackey. For some silly reason they still require CAC authentication to get the CAC software and drivers and access the forums, etc. More relevant information below... I'd be grateful for any ideas or advice on this. I desperately need to retrieve vulnerability reports, patches, and other DoD resources. Thanks! Cal Webster Smart Card Reader: SCM Microsystems Inc. SCR3310 USB Smart Card Reader (21120628202509) 00 00-0 Old CAC:GEMAL TO TOPDL GX4 144 New CAC:GD FIPS 201 SCE 3.2 [root@inet3 ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@inet3 ~]# uname -a Linux inet3 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@inet3 ~]# Installed Packages coolkey.i686 1.1.0-32.el6@base coolkey.x86_64 1.1.0-32.el6@base firefox.i686 31.2.0-3.el6.centos @updates firefox.x86_64 31.2.0-3.el6.centos @updates thunderbird.x86_64 31.2.0-3.el6.centos @updates pcsc-lite.x86_64 1.5.2-14.el6@base pcsc-lite-devel.x86_64 1.5.2-14.el6@base pcsc-lite-libs.x86_64 1.5.2-14.el6@base nss.i686 3.16.1-14.el6 @base nss.x86_64 3.16.1-14.el6 @base nss-devel.x86_64 3.16.1-14.el6 @base nss-softokn.i686 3.14.3-18.el6_6 @updates nss-softokn.x86_64 3.14.3-18.el6_6 @updates nss-softokn-devel.x86_64 3.14.3-18.el6_6 @updates nss-softokn-freebl.i6863.14.3-18.el6_6 @updates nss-softokn-freebl.x86_64 3.14.3-18.el6_6 @updates nss-softokn-freebl-devel.x86_643.14.3-18.el6_6 @updates nss-sysinit.x86_64 3.16.1-14.el6 @base nss-tools.x86_64 3.16.1-14.el6 @base nss-util.i686
Re: [CentOS] DoD approval of Centos Was RE: Firefox fails to authenticate .mil sites with New DoDCAC
On Thu, 2014-12-04 at 11:41 -0500, Jason Ricles wrote: Gotcha, I also work with DoD for Navy systems and was surprised by that. So you mean if we don't want to pay RHEL licensing fees, we can use Centos? Since we are paying about $100 per RHEL license. I would recommend RHEL for critical systems or those that must be certified for a particular purpose, such as CA servers. We've been using CentOS for years now on our internal networks for software development, local site mail service (SMTP/POP/IMAP), file services (FTP/NFS/SMB/CIFS), DNS, local web servers, etc. It works very well for this, especially for software development where multiple people can get a GUI login through Stunnel-VNC-GDM and/or shell through ssh. We're also using CentOS for software maintenance of RHEL hosts on our aircraft simulators. Many of our software developers prefer a CentOS workstation because of its versatility. On those we install MS Windoze as a KVM guest for those applications that require it. My internal workstation is setup this way for use network/systems admin and analysis, software development, as well as normal office tasks. On Thu, Dec 4, 2014 at 11:36 AM, Jason Pyeron jpye...@pdinc.us wrote: -Original Message- From: Jason Ricles Sent: Thursday, December 04, 2014 11:23 To: CentOS mailing list Subject: Re: [CentOS] Firefox fails to authenticate .mil sites with New DoDCAC I thought DoD used RHEL and not Centos, or did Centos did approved DADEMS recently? DADMS is a Navy system, but yes Centos is approved for use by DISA. You would STIG it just like RHEL. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Firefox fails to authenticate .mil sites with New DoD CAC
On Thu, 2014-12-04 at 11:30 -0500, m.r...@5-cent.us wrote: Cal Webster wrote: On Thu, 2014-12-04 at 08:08 -0500, mark wrote: On 12/03/14 17:34, Cal Webster wrote: Can anyone help with getting the new DoD CACs (Smart Card) to work in CentOS 6.6? I don't use it for console logins, only for email and .mil web sites. I recently had to get a new DoD CAC (Smart Card) when one of the buildings I work in upgraded their security system. My old CAC was working fine prior to this for signing and encrypting email and for authenticating to various DoD (.mil) sites from the Internet using the coolkey libraries. Dunno 'bout the new CaC keys, but they upgraded our PIV cards to 128? 256? I forget, earlier this year, and I *think* I remember my manager pushing an enhancement on upstream, and since then we've had no trouble with coolkey accessing them. The two *should* be identical. Was source for this upstream enhancement released to the community? Not Yup. We have a few RHEL licenses, so he could push for the enhancement. It was released, and we were using it with CentOS 6.5. It must have been in the coolkey-1.1.0-32 update. Build Date: Wed 15 Oct 2014 11:11:10 AM EDT Install Date: Wed 29 Oct 2014 05:04:04 AM EDT sure what you meant by The two - you mean coolkey and cackey? Nope. We don't use cackey. snip I've tried installing and loading the latest cackey libraries (see I know nothing about cackey libraries, but it's possible that, and pcscd are arguing. I don't see pcscd installed. pcsc-lite-1.5.2-14.el6.x86_64 (listed on original post) contains pcscd. Sure that's possible but I see nothing to support that in the system logs Watch out that opensc that *doesn't* come with pcscd isn't loaded. Oh, also, new card - do you have a new CA chain? Is that installed? snip mark, who has a new card a few weeks ago, and had to deal with the CA change from Verizon to Entrust Yes, I learned to avoid opensc years ago when we first setup the CACs. A missing CA cert turned out to be the problem. I checked after Jason Pyeron was kind enough to mention MAIL CA-32 listed on my CAC cert lookup. Sure enough, it was missing in the Firefox CA store but present in the Thunderbird store. This explains why I could sign and encrypt email but not access .mil web sites. When I used the dod_configuration mozilla add-on to update the certs I assumed it would get them all. Apparently not. In fact, I think it deleted this cert because I recorded everything on my previous CAC before getting the new one. It was also using CA-32. I ended up just exporting the cert from Thunderbird and importing it into Firefox. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] DoD approval of Centos Was RE: Firefox fails to authenticate .mil sites with New DoDCAC
On Thu, 2014-12-04 at 13:09 -0500, Jason Ricles wrote: That is true, which we are using ours for critical things. Guess RHEL will be the way to go till Centos is maybe approved for critical systems as well. That's really up to the program manager in which the machine would be used. He would make a determination whether it's supportable and maintainable, based on in-house expertise and/or outside contract support. RHEL subscriptions give you instant support and patches if necessary. Otherwise, unless another RHEL subscriber has the same issue, you'd have to wait for the community to fix something then get it integrated into RHEL before filtering down to CentOS. If this is acceptable then CentOS is an option. On Thu, Dec 4, 2014 at 12:29 PM, Cal Webster cwebs...@ec.rr.com wrote: On Thu, 2014-12-04 at 11:41 -0500, Jason Ricles wrote: Gotcha, I also work with DoD for Navy systems and was surprised by that. So you mean if we don't want to pay RHEL licensing fees, we can use Centos? Since we are paying about $100 per RHEL license. I would recommend RHEL for critical systems or those that must be certified for a particular purpose, such as CA servers. We've been using CentOS for years now on our internal networks for software development, local site mail service (SMTP/POP/IMAP), file services (FTP/NFS/SMB/CIFS), DNS, local web servers, etc. It works very well for this, especially for software development where multiple people can get a GUI login through Stunnel-VNC-GDM and/or shell through ssh. We're also using CentOS for software maintenance of RHEL hosts on our aircraft simulators. Many of our software developers prefer a CentOS workstation because of its versatility. On those we install MS Windoze as a KVM guest for those applications that require it. My internal workstation is setup this way for use network/systems admin and analysis, software development, as well as normal office tasks. On Thu, Dec 4, 2014 at 11:36 AM, Jason Pyeron jpye...@pdinc.us wrote: -Original Message- From: Jason Ricles Sent: Thursday, December 04, 2014 11:23 To: CentOS mailing list Subject: Re: [CentOS] Firefox fails to authenticate .mil sites with New DoDCAC I thought DoD used RHEL and not Centos, or did Centos did approved DADEMS recently? DADMS is a Navy system, but yes Centos is approved for use by DISA. You would STIG it just like RHEL. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Firefox fails to authenticate .mil sites with New DoD CAC
Can anyone help with getting the new DoD CACs (Smart Card) to work in CentOS 6.6? I don't use it for console logins, only for email and .mil web sites. I recently had to get a new DoD CAC (Smart Card) when one of the buildings I work in upgraded their security system. My old CAC was working fine prior to this for signing and encrypting email and for authenticating to various DoD (.mil) sites from the Internet using the coolkey libraries. After getting my new CAC I am no longer able to authenticate to any DoD sites. I can still sign and encrypt email in Thunderbird via the coolkey libraries but .mil sites either simply display blank pages or raise various errors in firefox. I am prompted for my PIN, which is successfully accepted but I'm not even prompted for which cert to use, like I used to be. I've tried installing and loading the latest cackey libraries (see below) but when I insert my CAC and attempt to login to the module in the Mozilla device manager it completely freezes firefox. Recovery requires killing firefox. If I remove the latest and install the next previous cackey library it works the same as coolkey - doesn't freeze up firefox but never connects to .mil sites. I tried building the cackey RPMs from the source RPMs too but the result is the same. Latest 64-bit cackey: cackey-0.6.8-3522.x86_64.rpm Next previous cackey: cackey-0.6.5-2444.x86_64.rpm I'm pretty sure it has something to do with the newer PIV CAC internal layout. I went through a similar transition when the GEMAL 144 cards came out but the cackey libraries did at least work and coolkey eventually caught up. One thing is for sure... the cackey RPM from forge.mil is not a drop-in replacement for coolkey. The cackey RPM only installs the libraries themselves, nothing else. It doesn't even register them in the nss db I had to do that manually with modutil. I must be missing something... Without direct access to forge.mil it's difficult to troubleshoot cackey. For some silly reason they still require CAC authentication to get the CAC software and drivers and access the forums, etc. More relevant information below... I'd be grateful for any ideas or advice on this. I desperately need to retrieve vulnerability reports, patches, and other DoD resources. Thanks! Cal Webster Smart Card Reader: SCM Microsystems Inc. SCR3310 USB Smart Card Reader (21120628202509) 00 00-0 Old CAC:GEMAL TO TOPDL GX4 144 New CAC:GD FIPS 201 SCE 3.2 [root@inet3 ~]# cat /etc/redhat-release CentOS release 6.6 (Final) [root@inet3 ~]# uname -a Linux inet3 2.6.32-504.1.3.el6.x86_64 #1 SMP Tue Nov 11 17:57:25 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux [root@inet3 ~]# Installed Packages coolkey.i686 1.1.0-32.el6@base coolkey.x86_64 1.1.0-32.el6@base firefox.i686 31.2.0-3.el6.centos @updates firefox.x86_64 31.2.0-3.el6.centos @updates thunderbird.x86_64 31.2.0-3.el6.centos @updates pcsc-lite.x86_64 1.5.2-14.el6@base pcsc-lite-devel.x86_64 1.5.2-14.el6@base pcsc-lite-libs.x86_64 1.5.2-14.el6@base nss.i686 3.16.1-14.el6 @base nss.x86_64 3.16.1-14.el6 @base nss-devel.x86_64 3.16.1-14.el6 @base nss-softokn.i686 3.14.3-18.el6_6 @updates nss-softokn.x86_64 3.14.3-18.el6_6 @updates nss-softokn-devel.x86_64 3.14.3-18.el6_6 @updates nss-softokn-freebl.i6863.14.3-18.el6_6 @updates nss-softokn-freebl.x86_64 3.14.3-18.el6_6 @updates nss-softokn-freebl-devel.x86_643.14.3-18.el6_6 @updates nss-sysinit.x86_64 3.16.1-14.el6 @base nss-tools.x86_64 3.16.1-14.el6 @base nss-util.i686 3.16.1-3.el6@base nss-util.x86_643.16.1-3.el6@base nss-util-devel.x86_64 3.16.1-3.el6@base [root@inet3 ~]# modutil -list -dbdir /etc/pki/nssdb Listing of PKCS #11 Modules --- 1. NSS Internal PKCS #11 Module slots: 2 slots attached status: loaded slot: NSS Internal Cryptographic Services token: NSS Generic Crypto Services slot: NSS User Private Key and Certificate Services token: NSS Certificate DB 2. CoolKey PKCS #11 Module library name: libcoolkeypk11.so slots: 1 slot attached status: loaded slot: SCM Microsystems Inc. SCR3310 USB Smart Card Reader (21120628202 token: WEBSTER.CALVIN.DALE.9427154028 3. cackey library name
[CentOS] Workaround for (EL6.4) rdesktop-1.6.0-10 Woe
rdesktop has been spewing error messages since the update to CentOS 6.4.
Aside from the continuous stream of errors in the terminal window from
which it was launched, there are a number of usability issues in the
remote session. The pointer does not change shape when moving over
various window components such as column separators, window borders,
etc. The background doesn't refresh within scroll bars, making it
difficult to tell where the scroll handle is. We've also found that MS
Visio will crash and hang the remote system if run within rdesktop.
Other strange phenomenon are also manifest in various applications. In
short, rdesktop 1.6.0-10 is buggy and unstable. See this upstream bug
report for more:
Bug 914279 - regression in 1.6.0-10.el6: Mousepointer and selections not
drawn properly
https://bugzilla.redhat.com/show_bug.cgi?id=914279
We've been putting up with it, hoping that an update would be published
upstream. Even though this issue is affecting customers upstream, as
evidenced in the bugzilla report, a bug-fix update doesn't appear to be
imminent. I decided to rebuild the Fedora 19 SRPM on CentOS to resolve
the issue. It appears from the bugzilla remarks that others have done
this trivially. With a few simple precautions, we've done just that. I'm
sharing our work-around in the hope that it will benefit others in
similar circumstances.
This process assumes you have a build machine properly setup with an
rpmbuild environment. If you don't, see this article:
Set Up an RPM Build Environment under CentOS
http://wiki.centos.org/HowTos/SetupRpmBuildEnvironment
Note: Watch for line-wrap below.
Best Regards,
--Cal Webster
=[Rdesktop Workaround]=
## Retrieve and install the CentOS source RPM:
rpm -iv
http://vault.centos.org/6.4/os/Source/SPackages/rdesktop-1.6.0-10.el6.src.rpm
## Set aside the sources:
[iseo@jato ~]$ cd rpmbuild/SOURCES/
[iseo@jato SOURCES]$ mkdir rdesktop-1.6.0-10
[iseo@jato SOURCES]$ mv *.patch rdesktop-1.6.0.tar.gz rdesktop-1.6.0-10/
## Rename the CentOS spec file:
[iseo@jato SOURCES]$ cd ../SPECS/
[iseo@jato SPECS]$ mv rdesktop.spec rdesktop.spec.centos
## Retrieve and install the Fedora source RPM from your favorite
mirror:
(watch for line-wrap in URL)
rpm -iv
http://mirror.linux.duke.edu/pub/fedora/linux/releases/19/Everything/source/SRPMS/r/rdesktop-1.7.1-2.fc19.src.rpm
## Rename the Fedora spec file then use the CentOS spec file:
[iseo@jato SPECS]$ mv rdesktop.spec rdesktop.spec.fc19
[iseo@jato SPECS]$ cp rdesktop.spec.centos rdesktop.spec
## Edit the CentOS spec file:
Change version and release to reflect FC19 package
Add version suffix to designate local RPM
Remove original CentOS patch references and replace with those from FC19
Add comments in change log
[iseo@jato SPECS]$ vi rdesktop.spec
---
Version:1.7.1
Release:2%{?dist}.1.iseo
...
Patch0: %{name}-libao.patch
...
%prep
%setup -q
%patch0 -p1 -b .ao
...
%changelog
* Fri Nov 1 2013 Cal Webster cwebs...@bizec.rr.com 1.7.1-2
- Latest version not available upstream
- This version from FC19
- Fixes regression errors (NOT IMPLEMENTED RDP5 opcodes, get cursor,
etc)
- Fixes mouse cursor not changing and background showing through
- Fixes freeze on remote system
- See https://bugzilla.redhat.com/show_bug.cgi?id=914279
---
## You might need to install pcsc-lite-devel if you get a build
dependency error. It's not installed by default.
[root@jato ~]# yum install pcsc-lite-devel
...
Installed:
pcsc-lite-devel.x86_64
0:1.5.2-13.el6_4
Complete!
[root@jato ~]#
## You will also need to modify /usr/include/ao/ao.h to overcome this
build error:
--
[iseo@jato rpmbuild]$ rpmbuild -ba --sign --clean SPECS/rdesktop.spec
...
gcc -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wall
-I/usr/include -pthread -I/usr/include/PCSC -DPACKAGE_NAME=
\rdesktop\ -DPACKAGE_TARNAME=\rdesktop\ -DPACKAGE_VERSION=\1.7.1\
-DPACKAGE_STRING=\rdesktop\ 1.7.1\ -DPACKAGE_BUGREPORT=\\
-DPACKAGE_URL=\\ -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1
-DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1
-DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DL_ENDIAN=1 -DHAVE_SYS_SELECT_H=1
-DHAVE_LOCALE_H=1 -DHAVE_LANGINFO_H=1 -DHAVE_SYSEXITS_H=1 -Dssldir=
\/usr\ -DHAVE_XRANDR=1 -DWITH_SCARD=1 -DEGD_SOCKET=\/var/run/egd-pool
\ -DWITH_RDPSND=1 -DRDPSND_LIBAO=1 -DHAVE_DIRENT_H=1 -DHAVE_DIRFD=1
-DHAVE_DECL_DIRFD=1 -DHAVE_ICONV_H=1 -DHAVE_ICONV=1 -DICONV_CONST=
-DHAVE_SYS_VFS_H=1 -DHAVE_SYS_STATVFS_H=1 -DHAVE_SYS_STATFS_H=1
-DHAVE_SYS_PARAM_H=1 -DHAVE_SYS_MOUNT_H=1 -DSTAT_STATVFS=1
-DHAVE_STRUCT_STATVFS_F_NAMEMAX=1 -DHAVE_STRUCT_STATFS_F_NAMELEN=1
-DHAVE_MNTENT_H=1 -DHAVE_SETMNTENT=1 -DIPv6=1 -DKEYMAP_PATH=
\/usr/share/rdesktop/keymaps
Re: [CentOS] Workaround for (EL6.4) rdesktop-1.6.0-10 Woe
On Thu, 2013-11-07 at 19:17 +, James Pearson wrote: Cal Webster wrote: In short, rdesktop 1.6.0-10 is buggy and unstable. See this upstream bug report for more: There are more recent versions of rdesktop available via 3rd party repos e.g. http://pkgs.repoforge.org/rdesktop/ No idea if they fix your problem - but probably worth a try? James Pearson The Fedora package we used is the best choice since (1) it has already proven to fix the issues as cited in the bug report, and (2) Fedora is the source for upstream vendor packages anyway. I like to stay away from 3rd party repos as much as possible to avoid overlap. CentOS and EPEL have most everything our sites need. If there is something we really need that's not in one of those, we'll rebuild the source and put it in our custom LocalCentos repo. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Workaround for (EL6.4) rdesktop-1.6.0-10 Woe
On Thu, 2013-11-07 at 13:50 -0500, Fred Smith wrote: On Thu, Nov 07, 2013 at 10:51:48AM -0500, Cal Webster wrote: rdesktop has been spewing error messages since the update to CentOS 6.4. Aside from the continuous stream of errors in the terminal window from which it was launched, there are a number of usability issues in the remote session. The pointer does not change shape when moving over various window components such as column separators, window borders, etc. The background doesn't refresh within scroll bars, making it difficult to tell where the scroll handle is. We've also found that MS Visio will crash and hang the remote system if run within rdesktop. Other strange phenomenon are also manifest in various applications. In short, rdesktop 1.6.0-10 is buggy and unstable. See this upstream bug report for more: Bug 914279 - regression in 1.6.0-10.el6: Mousepointer and selections not drawn properly https://bugzilla.redhat.com/show_bug.cgi?id=914279 there is a newer version upstream (meaning the author's web site), but I don't know if it solves these problems. 1.8.0 is available from http://www.rdesktop.org/#download I know, we all hate to override the package manager with un-packaged programs, but sometimes you just gotta. It quickly becomes impossible to manage anything more than a handful of systems without a reliable package management system. Unmanaged apps suck away valuable time. I'm sure the latest-and-greatest will make its way into Fedora where a maintainer will re-package it into an RPM. For now, I'm happy to rebuild the Fedora SRPM until and upstream (Red Hat) SRPM is published. As I indicated, it's trivial to rebuild. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Cannot get Centrino N 6200 wireless NIC to work Cento 6.4
On Thu, 2013-05-16 at 16:16 -0400, Selwyn Schultz Sr wrote: I am very new to installing Linux on laptops. I got it working on another Toshiba I owned without to much trouble, and then decided I wanted to experiment with KVM so I bought this laptop with an I5 chip. Anyway I tried modprobe iwlagn and the driver is not found. I then did a search for it using find and again came up empty handed. Googling for Centos iwlagn seems to indicate that the module is a standard part of the Centos 6 build. But I seem to be missing this on my installation. I will do a fresh installation and see if that does not install the module. Before you do that, try searching the yum repo. I came up with a number of hits: [root@INET1 ~]# yum search iwlagn Loaded plugins: fastestmirror, refresh-packagekit, security Loading mirror speeds from cached hostfile epel/metalink| 13 kB 00:00 * base: centos.mirror.constant.com * epel: archive.linux.duke.edu * extras: centos.aol.com * updates: dist1.800hosting.com adobe-linux-i386 | 951 B 00:00 adobe-linux-x86_64 | 951 B 00:00 base | 3.7 kB 00:00 extras | 3.5 kB 00:00 google-chrome| 951 B 00:00 updates | 3.5 kB 00:00 === Matched: iwlagn iwl100-firmware.noarch : Firmware for Intel(R) Wireless WiFi Link 100 Series : Adapters iwl1000-firmware.noarch : Firmware for Intel® PRO/Wireless 1000 B/G/N network : adaptors iwl5150-firmware.noarch : Firmware for Intel® Wireless 5150 A/G/N network : adaptors iwl6000-firmware.noarch : Firmware for Intel(R) Wireless WiFi Link 6000 Series : AGN Adapter iwl6000g2a-firmware.noarch : Firmware for Intel(R) Wireless WiFi Link 6005 : Series Adapters iwl6000g2b-firmware.noarch : Firmware for Intel(R) Wireless WiFi Link 6030 : Series Adapters iwl6050-firmware.noarch : Firmware for Intel(R) Wireless WiFi Link 6050 Series : Adapters [root@INET1 ~]# Also, be sure that your radio is enabled in BIOS and after boot, once you have the proper packages installed. If the wifi indicator is not lit it may be disabled. Most laptops have a function key sequence to enable/disable wifi/bluetooth. You may need to toggle this to get your wifi radio to turn on. On Thu, May 16, 2013 at 1:01 PM, m.r...@5-cent.us wrote: Selwyn Schultz Sr wrote: I installed Centos 6.4 on my laptop and neither of the network interfaces will work. When I boot up to windows both the wired and the wireless network interfaces work. I have attached dmesg output for the wireless card. Reading through the messages it appears that OS cannot talk to the NIC. First, have you tried googling Centos 6 centrino N 6200, as I just did? And the very first hit was posted 11 Jan 2011, and one comment was: The Intel Wireless WiFi Link 6200AGN and 6300AGN Adapters are supported by the iwlagn driver in 5.5 and 5.6. You will need the appropriate firmware installed, in this case iwl6000-firmware available from elrepo.org: ** mark ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] How to configure display on CentOS 6?
On Wed, 2013-01-23 at 09:33 -0500, Scot P. Floess wrote: I think you can also use X --config That should build an /etc/X11/xorg.conf file for you... That's a good start (the command is actually Xorg -configure) but it may leave open questions to the OP and others who may consult this thread in the future. We've had occasion to use 4 different methods of X-Windows configuration in EL6, without the old system-config-display tool. The choices are: 1. Accept the Xorg auto-detected, built-in configuration. If it works, why mess with it? 2. Generate and customize your own xorg.conf file. 3. Use Xorg hot-plug config (/etc/X11/xorg.conf.d/) to replace only part of the built-in configuration. 4. Use a proprietary video driver and X configurator. This may be necessary with high-end video cards and/or multiple displays. I've outlined choices #2 and #3 below, as they are probably going to be of primary interest to the OP. I hope this information is of some use. ./Cal (I work on a restricted, isolated network without direct Internet access so I may not be able to respond to replies quickly.) = [Generate and customize a xorg.conf file] = # Save the Xorg log file to capture any errors (as root): cd /var/log/ cp Xorg.0.log Xorg.0.log.beforeConfigure # Drop to run level 3 or boot into run level 3 cd init 3 # Tell Xorg to generate the config file: Xorg -configure # Make a copy to work on: cp -p /root/xorg.conf.new /root/xorg.conf # Look at the created config - get rid of extra screens and unnecessary data - Use for reference any xorg.conf in similar machines if you have them available - There should be one section for Monitor, Device (video card), and Screen to match the ServerLayout section. - See sample below == [/Generate and customize a xorg.conf file] == = [Xorg hot-plug config file] = # Use the same steps as above to get something to start with or to ensure proper formatting. - We just extracted the data we needed from the Xorg.0.log to create a hot-plug file, then dropped it into /etc/X11/xorg.conf.d/. - We were only interested in getting the vnc module to load and vncpassword to work so ours probably has more in it than we need but it works. Xorg will pull anything not listed in the hot-plug files from its built-in configuration. All the same rules apply to a hot-plug file as do for xorg.conf See the sample hot-plug file below. == [/Xorg hot-plug config file] == == [Sample xorg.conf] == ## This is an edited, auto-generated xorg.conf from a Dell PowerEdge 2800 running CentOS 6.3 - We were interested in running the native VNC X server (tigervnc-server-module) so we added those entries in the appropriate places. - If you look at the top of your Xorg.0.log you'll see what the Xorg server has auto-detected. It's usually very good at detecting your video hardware. Armed with that information, you should be able to select and load the correct driver. - Some of our machines have high-end nVidia graphics cards so we opted to use the proprietary video drivers from nVidia to maximize the use of dual screens and high resolution. We've found that the open source drivers can sometimes be problematic, like on some of our Dell Precision T3400 machines. - The ATI Radeon driver was automatically listed and configured on this machine. According to our documentation, this machine had a Radeon 7000 chipset so it matched. [root@pegasus log]# lspci | grep -i radeon 10:0d.0 VGA compatible controller: Advanced Micro Devices [AMD] nee ATI RV100 QY [Radeon 7000/VE] # From the Xorg.0.log - [97.240] (--) RADEON(0): Chipset: ATI Radeon VE/7000 QY (AGP/PCI) (ChipID = 0x5159) - vi /root/xorg.conf -- Section ServerLayout Identifier X.org Configured Screen 0 Screen0 0 0 InputDeviceMouse0 CorePointer InputDeviceKeyboard0 CoreKeyboard EndSection Section Files ModulePath /usr/lib/xorg/modules FontPath catalogue:/etc/X11/fontpath.d FontPath built-ins EndSection Section Module Load dbe Load record Load dri Load vnc Load extmod Load glx Load dri2 EndSection Section InputDevice Identifier Keyboard0 Driver kbd EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/input/mice Option ZAxisMapping 4 5 6 7 EndSection Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameMonitor Model EndSection Section Device Identifier Card0
Re: [CentOS] KVM as a desktop
On Tue, 2012-08-28 at 10:23 -0400, James B. Byrne wrote: I am nearing the end of a project that moved our disparate services and hosts onto kvm virtualized servers. What I am now contemplating is setting up my desktop as a virtual host and using one of the guests as my primary workstation. However, I am not sure how this would work in practice. I am accustomed to working with virtual instances via ssh (a terminal window) and with my desktop system in a Gnome window manager. Is there a reference somewhere that outlines the mechanics of logging into a virtual guest's graphical desktop directly from the physical console of the kvm host system? CentOS 6 Manuals are not yet available but the upstream docs are here: https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Linux/ You probably want to start here: (watch for line-wrap) https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Virtualization_Host_Configuration_and_Guest_Installation_Guide/index.html To open a graphical console on your virtual desktop from the KVM host: (you'll probably do this when you create your VM anyway) = [Applications]-[System Tools]-[Virtual Machine Manager] Authenticate dialog opens Password for root: [your_root_password] Button: [Authenticate] VM Manager window opens First connection is highlighted (default is localhost (QEMU)) Virtual machines under connection are displayed Double-click desired VM Native console of VM opens From here you can login, get info, pause, stop, start, go full-screen, etc. = KVM uses VNC to connect to the guest machines' consoles and by default will automatically assign the next available VNC port, beginning with 5900. I would highly recommend manually configuring your first guest's display (Display VNC) with VNC port 5901 and let subsequent VM's get assigned automatically. Otherwise, there will be a conflict with tigervnc-server-module if you later wish to connect remotely to the physical server (KVM host). If auto-configured the first VM will get port 5900 which the Xorg VNC module expects to be reserved for the (physical) host's console port. The port on which the Xorg module listens cannot be changed easily. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tigervnc-server-module crashes after EL 6.3 update
On Fri, 2012-08-17 at 19:46 -0500, Johnny Hughes wrote: On 08/17/2012 01:40 PM, Cal Webster wrote: On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote: On 08/16/2012 11:43 AM, Cal Webster wrote: On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote: On 08/15/2012 09:47 AM, Cal Webster wrote: On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: On 08/14/2012 05:23 PM, Cal Webster wrote: We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild? No mock, just a simple rpmbuild -ba SPEC/tigervnc.spec OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different. I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems. Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems. One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary ATI FirePro 2270 drivers, though. Once the rebuilt module is installed the systems run fine. I've also updated the upstream bug report. can you see if either or both of these work for you: http://people.centos.org/hughesjr/tigervnc/ One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed. Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host. I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one. Would you also test that these work: http://people.centos.org/hughesjr/tigervnc/ (same link, newer files :D) NOTE: It is CentOS policy that we do not correct upstream bugs in our distributions directly ... therefore these will not be released into the main distro until upstream releases an update. I know that is a PITA for people, however, it is our policy and we can't break it. Got them and tested on 3 different machines, 2 x86_64 (one single and one dual-head) and one i386. All work well. This time I updated all tigervnc packages, not just tigervnc-server-module. I added all the packages to our internal localcentos repo so all our systems will pickup the update, thanks to your incremental version number change. I use the localcentos repo
Re: [CentOS] tigervnc-server-module crashes after EL 6.3 update
On Fri, 2012-08-17 at 19:46 -0500, Johnny Hughes wrote: On 08/17/2012 01:40 PM, Cal Webster wrote: On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote: On 08/16/2012 11:43 AM, Cal Webster wrote: On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote: On 08/15/2012 09:47 AM, Cal Webster wrote: On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: On 08/14/2012 05:23 PM, Cal Webster wrote: We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild? No mock, just a simple rpmbuild -ba SPEC/tigervnc.spec OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different. I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems. Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems. One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary ATI FirePro 2270 drivers, though. Once the rebuilt module is installed the systems run fine. I've also updated the upstream bug report. can you see if either or both of these work for you: http://people.centos.org/hughesjr/tigervnc/ One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed. Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host. I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one. Would you also test that these work: http://people.centos.org/hughesjr/tigervnc/ (same link, newer files :D) NOTE: It is CentOS policy that we do not correct upstream bugs in our distributions directly ... therefore these will not be released into the main distro until upstream releases an update. I know that is a PITA for people, however, it is our policy and we can't break it. Sorry Johnny. I've been deep in some internal issues past few days - Migration planning for Win7, building out new CentOS 6 servers, and such. I'll be happy to test these. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tigervnc-server-module crashes after EL 6.3 update
On Fri, 2012-08-17 at 19:46 -0500, Johnny Hughes wrote: On 08/17/2012 01:40 PM, Cal Webster wrote: On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote: On 08/16/2012 11:43 AM, Cal Webster wrote: On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote: On 08/15/2012 09:47 AM, Cal Webster wrote: On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: On 08/14/2012 05:23 PM, Cal Webster wrote: We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild? No mock, just a simple rpmbuild -ba SPEC/tigervnc.spec OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different. I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems. Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems. One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary ATI FirePro 2270 drivers, though. Once the rebuilt module is installed the systems run fine. I've also updated the upstream bug report. can you see if either or both of these work for you: http://people.centos.org/hughesjr/tigervnc/ One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed. Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host. I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one. Would you also test that these work: http://people.centos.org/hughesjr/tigervnc/ (same link, newer files :D) NOTE: It is CentOS policy that we do not correct upstream bugs in our distributions directly ... therefore these will not be released into the main distro until upstream releases an update. I know that is a PITA for people, however, it is our policy and we can't break it. I haven't heard anyone on this list verify that the problem does, in fact, exist on RHEL 6. It would be nice to confirm this is an upstream bug versus a packaging issue with CentOS. If there are members here with mixed upstream and CentOS environments, such confirmation would be welcome. We just allowed the last of our entitlements to expire so I can't do it here. ./Cal
Re: [CentOS] tigervnc-server-module crashes after EL 6.3 update
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote: On 08/16/2012 11:43 AM, Cal Webster wrote: On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote: On 08/15/2012 09:47 AM, Cal Webster wrote: On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: On 08/14/2012 05:23 PM, Cal Webster wrote: We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild? No mock, just a simple rpmbuild -ba SPEC/tigervnc.spec OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different. I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems. Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems. One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary ATI FirePro 2270 drivers, though. Once the rebuilt module is installed the systems run fine. I've also updated the upstream bug report. can you see if either or both of these work for you: http://people.centos.org/hughesjr/tigervnc/ One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed. Both builds work without problems on single and dual-head systems here. As with all the other tests, I only replaced the tigervnc-server-module package on each host. I've also confirmed that i686 platforms suffer from the same bug. These too, however, are easily remedied by replacing the base tigervnc-server-module RPM with a locally re-build one. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tigervnc-server-module crashes after EL 6.3 update
On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote: On 08/15/2012 09:47 AM, Cal Webster wrote: On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: On 08/14/2012 05:23 PM, Cal Webster wrote: We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild? No mock, just a simple rpmbuild -ba SPEC/tigervnc.spec OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different. I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems. Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems. One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary ATI FirePro 2270 drivers, though. Once the rebuilt module is installed the systems run fine. I've also updated the upstream bug report. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tigervnc-server-module crashes after EL 6.3 update
On Thu, 2012-08-16 at 17:01 -0500, Johnny Hughes wrote: On 08/16/2012 11:43 AM, Cal Webster wrote: On Wed, 2012-08-15 at 13:56 -0500, Johnny Hughes wrote: On 08/15/2012 09:47 AM, Cal Webster wrote: On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: On 08/14/2012 05:23 PM, Cal Webster wrote: We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild? No mock, just a simple rpmbuild -ba SPEC/tigervnc.spec OK, if you find that this solves your problems for sure, I will build the SRPM outside of mock and see if it is different. I've confirmed the same faulty behavior for the update to 6.3 on our dual-head systems. Also confirmed is that replacing the 6.3 base tigervnc-server-module rpm with the rebuilt one does fix the problem on the dual-head systems. One disturbing difference between single and dual headed systems is that on the dual-head systems Xorg generates a core dump and completely freezes up when the mouse movement is detected. Single-head systems just fail to connect. This complication could be somehow caused by our proprietary ATI FirePro 2270 drivers, though. Once the rebuilt module is installed the systems run fine. I've also updated the upstream bug report. can you see if either or both of these work for you: http://people.centos.org/hughesjr/tigervnc/ One set was built inside of mock, the other outside of mock in a virtual machine with only the build requirements of the SRPM installed. I'll try first thing in the morning Johnny. Wife's waitin' on me. :-) ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] tigervnc-server-module crashes after EL 6.3 update
On Tue, 2012-08-14 at 20:55 -0500, Johnny Hughes wrote: On 08/14/2012 05:23 PM, Cal Webster wrote: We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. Did you rebuild the SRPM using mock or directly on a physical machine with rpmbuild? No mock, just a simple rpmbuild -ba SPEC/tigervnc.spec ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] tigervnc-server-module crashes after EL 6.3 update
We began experiencing failed vnc connections to the console display on servers that have been updated to EL 6.3. No such failures have occurred on similar connections to EL 6.2 servers. On the client machine a normal vncviewer display appears with the expected graphical login until the mouse pointer is moved within the boundaries of the vncviewer window. At this point the window closes and an error message appears in both a pop-up window and in the terminal window in which the session was initiated stating read: Connection reset by peer (104). On the server end, a core dump is generated and a abrt bug report is created. /var/log/messages -- Aug 14 11:00:30 jato2 abrt[11411]: File '/usr/bin/Xorg' seems to be deleted Aug 14 11:00:30 jato2 abrt[11411]: Saved core dump of pid 7892 (/usr/bin/Xorg) to /var/spool/abrt/ccpp-2012-08-14-11:00:30-7892 (42041344 bytes) Aug 14 11:00:30 jato2 abrtd: Directory 'ccpp-2012-08-14-11:00:30-7892' creation detected -- This bug has been reported in the CentOS bug tracker here: 0005824: tigervnc-server-module keep crashing http://bugs.centos.org/view.php?id=5824 However, this appears to be a bug upstream. The source RPM provided with CentOS is identical to that of upstream with no modifications. Also, there is an upstream bug reported that appears to have the same symptoms. I have added a comment to the upstream bug report (listed below) if anyone wishes to see the details. tigervnc-server-module crashes with dual screen setup https://bugzilla.redhat.com/show_bug.cgi?id=820443 We have verified that rebuilding the unmodified source RPM for tigervnc produces a tigervnc-server-module RPM that does not suffer from this bug. Removing the original tigervnc-server-module package and replacing it with the rebuilt one fixes the problem. I've duplicated the problem on 2 EL 6.3 x86_64 single-head display machines and have verified the fix. Tomorrow, I'll duplicate the problem on a dual-head x86_64 machine that currently still works after updating to EL 6.2 then confirm the the fix. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Update to EL 6.3 breaks TCP NFS automounts
See Red Hat Bugzilla bug #846852 for details. https://bugzilla.redhat.com/show_bug.cgi?id=846852 FYI: We discovered that after updating to EL 6.3 on our x86_64 server, autofs 5.0.5-54 broke our nightly backups that rely on automounting an NFS share hosted on another EL 6 machine on our local network. The machine hosting NFS server was configured to allow only TCP connections to the port specified by MOUNTD_PORT in /etc/sysconfig/nfs Any attempts to access this share caused segmentation faults in the automount daemon. EL 6.2 hosts that had not yet been updated had no problems accessing the same NFS shares. While testing we found that opening the UDP MOUNTD_PORT on the NFS server firewall allowed successful access to the NFS shares from the EL 6.3 NFS client without segfault. Closing the port caused the EL 6.3 NFS client to return to the faulty behavior. On another fully updated EL 6.3 i386 host, we were able to duplicate the same symptoms. On one of the EL 6.2 hosts not yet updated we confirmed no issues with the previous autofs package, then upgraded only autofs. After the upgrade we confirmed symptoms identical to the fully updated 6.3 machines. While filing the bug report I found 2 other, possibly related, bugs written against autofs 5.0.5-54 that did not describe our symptoms but may be relevant to other users on this list. Bug 840025 - autofs 5.0.5-54 fails to mount share on IPv6 netapp https://bugzilla.redhat.com/show_bug.cgi?id=840025 Bug 834641 - autofs requires portmapper on server for NFSv4 mounts https://bugzilla.redhat.com/show_bug.cgi?id=834641 [Workaround] For now, we are leaving the UDP NFS port open on the firewall of the NFS server. Our networks are completely isolated from the outside world so this doesn't pose a significant risk. However, this may not be acceptable for everyone's environment. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Update to EL 6.3 breaks TCP NFS automounts
On Wed, 2012-08-08 at 18:37 -0400, Cal Webster wrote: See Red Hat Bugzilla bug #846852 for details. https://bugzilla.redhat.com/show_bug.cgi?id=846852 FYI: We discovered that after updating to EL 6.3 on our x86_64 server, autofs 5.0.5-54 broke our nightly backups that rely on automounting an NFS share hosted on another EL 6 machine on our local network. The machine hosting NFS server was configured to allow only TCP connections to the port specified by MOUNTD_PORT in /etc/sysconfig/nfs Any attempts to access this share caused segmentation faults in the automount daemon. EL 6.2 hosts that had not yet been updated had no problems accessing the same NFS shares. While testing we found that opening the UDP MOUNTD_PORT on the NFS server firewall allowed successful access to the NFS shares from the EL 6.3 NFS client without segfault. Closing the port caused the EL 6.3 NFS client to return to the faulty behavior. On another fully updated EL 6.3 i386 host, we were able to duplicate the same symptoms. On one of the EL 6.2 hosts not yet updated we confirmed no issues with the previous autofs package, then upgraded only autofs. After the upgrade we confirmed symptoms identical to the fully updated 6.3 machines. While filing the bug report I found 2 other, possibly related, bugs written against autofs 5.0.5-54 that did not describe our symptoms but may be relevant to other users on this list. Bug 840025 - autofs 5.0.5-54 fails to mount share on IPv6 netapp https://bugzilla.redhat.com/show_bug.cgi?id=840025 Bug 834641 - autofs requires portmapper on server for NFSv4 mounts https://bugzilla.redhat.com/show_bug.cgi?id=834641 [Workaround] For now, we are leaving the UDP NFS port open on the firewall of the NFS server. Our networks are completely isolated from the outside world so this doesn't pose a significant risk. However, this may not be acceptable for everyone's environment. I forgot to mention that I did find what appeared to be an identical bug reported apparently as a private upstream support case #155523. I found it in a Google search but the link (https://access.redhat.com/knowledge/solutions/155523) raised a permission error, even though I was logged into the site. The text-only cached page from July 24 read like this: -- Autofs process segfault on startup after upgrading to RHEL6.3 release. last modified by Shijoe Panjikkaran on 07/10/12 - 03:26 Issue Autofs is getting segfaults after upgrading the autofs package to the 6.3 release Automount segfaults with the following message in logs, automount[5195]: segfault at 28 ip 7f0dfe22b862 sp 7f0e01a7b960 error 4 in lookup_hosts.so[7f0dfe222000+1c000] Environment Red Hat Enterprise Linux(RHEL) 6.3 autofs-5.0.5-54.el6.x86_64 -- This leads me to believe that upstream is aware of this issue and someone there is working on a fix. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] xorg.conf disappear
On Thu, 2012-03-29 at 09:57 +0100, Lars Hecking wrote: brick writes: Hi My system is CentOS 6. I need to edit xorg.conf. But it can't be find in /etc/X11. Where is it? How can I get the default setting? /var/log/Xorg.0.log will tell you which configuration Xorg is currently using, which devices are autodetected etc. If you need to change only particular parts of the config, you can drop a .conf file with the corresponding Section into /etc/X11/xorg.conf.d. E.g. if you needed a UK keyboard instead of the default US, you could use something along the lines of # cd /etc/X11/corg.conf.d # cat keyboard.conf Section InputDevice Identifier Keyboard0 Driver kbd Option XkbModel pc105 Option XkbLayout gb EndSection # If you know what you need, adding a separate conf file in /etc/X11/xorg.conf.d/ is the cleanest way to go. If you need some type of custom setup, however, you can generate an xorg.conf using Xorg -configure. The X server must not be running when you do this. ## Go to run level 3 init 3 ## Generate xorg.conf Xorg -configure ## The configuration file will be stored in root user's home (/root) From there you can modify it as needed then move it to /etc/X11/ and init 5 to test. You can test your changes by jumping in and out of run level 5. From Xorg(1) man page: -configure When this option is specified, the Xorg server loads all video driver modules, probes for available hardware, and writes out an initial xorg.conf(5) file based on what was detected. This option currently has some problems on some platforms, but in most cases it is a good way to bootstrap the configuration process. This option is only available when the server is run as root (i.e, with real-uid 0). ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Missing nss dependency nss-softokn
On Thu, 2011-12-15 at 02:14 -0800, John Doe wrote: From: Cal Webster cwebs...@ec.rr.com Error: Package: nss-3.12.10-2.el6_1.x86_64 (updates) Requires: nss-softokn(x86-64) = 3.12.9 Installed: nss-softokn-3.12.7-1.1.el6.x86_64 (@anaconda-CentOS-201106060106.x86_64/6.0) nss-softokn(x86-64) = 3.12.7-1.1.el6 I realize I need to swap in the 6.1 ISO on our internal mirror but the missing package doesn't appear to be on the mirrors either. It is in /os: .../6/os/x86_64/Packages/nss-softokn-3.12.9-3.el6.i686.rpm .../6/os/x86_64/Packages/nss-softokn-3.12.9-3.el6.x86_64.rpm Thanks. You're right. I was looking for a version match (nss-softokn-3.12.10-2). Got the 6.1 ISO now so this should be resolved. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] Missing nss dependency nss-softokn
I'm getting yum update errors when attempting to update nss: -- Finished Dependency Resolution Error: Package: nss-3.12.10-2.el6_1.x86_64 (updates) Requires: nss-softokn(x86-64) = 3.12.9 Installed: nss-softokn-3.12.7-1.1.el6.x86_64 (@anaconda-CentOS-201106060106.x86_64/6.0) nss-softokn(x86-64) = 3.12.7-1.1.el6 I realize I need to swap in the 6.1 ISO on our internal mirror but the missing package doesn't appear to be on the mirrors either. I can't see nss-softokn-3.12.10-2.el6_1.x86_64.rpm anywhere on the mirrors. I checked the updates and cr repos on the Duke mirror for 6.0 and 6.1 but no joy. Did this one fall through the cracks or are the mirrors still syncing up? I'm happy to wait if it's just a timing issue but I wanted to be sure the list knew, just in case. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6.0 chkconfig strange behavior
On Fri, 2011-07-22 at 13:00 -0600, Devin Reade wrote: --On Friday, July 22, 2011 11:10:29 AM -0700 Jerry Moore tec...@mcn.org wrote: It appears that chkconfig is re sequencing or re ordering the start priority of various services when turning on a service using chkconfig. [...] The only solution I've found is to remove the entire BEGIN INIT INFO to END INIT INFO section. Once that is removed it no longer changes the network startup priority when enabling the snmpd service. SuSE (and perhaps some other distributions) have for a few years been using that BEGIN/END INIT INFO block instead of the 'chkconfig' line to determine ordering, and will do exactly as you described. Without having looked into the CentOS 6 case, I would guess that the mechanism used in RHEL has changed to match. This could very well be related to the LSB project, although that's just a guess, too. System V init has been replaced by upstart Upstream Deployment Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html Fedora Wiki: http://fedoraproject.org/wiki/Features/Upstart Run levels are depreciated: http://en.wikipedia.org/wiki/Runlevel http://en.wikipedia.org/wiki/Upstart This change has been in the works for a few years: http://lists.centos.org/pipermail/centos/2009-September/082817.html Some articles from Google search [RHEL centos upstart] http://www.linux.com/archive/articles/57213 http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init-for-Upstart-What-Linux-admins-need-to-know ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6.0 chkconfig strange behavior
On Fri, 2011-07-22 at 12:47 -0700, Jerry Moore wrote: On Jul 22, 2011, at 12:17 PM, Cal Webster wrote: System V init has been replaced by upstart Upstream Deployment Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Technical_Notes/deployment.html Fedora Wiki: http://fedoraproject.org/wiki/Features/Upstart Run levels are depreciated: http://en.wikipedia.org/wiki/Runlevel http://en.wikipedia.org/wiki/Upstart This change has been in the works for a few years: http://lists.centos.org/pipermail/centos/2009-September/082817.html Some articles from Google search [RHEL centos upstart] http://www.linux.com/archive/articles/57213 http://searchenterpriselinux.techtarget.com/tip/RHEL-6-ditches-System-V-init-for-Upstart-What-Linux-admins-need-to-know Hey Cal, I knew I was missing something! Thanks for the assist guys! Hold onto your hat Jerry... Upstart has already been replace by systemd in Fedora 15 and most other major distros are planning to use it too. RHEL 7 will most likely switch to systemd if it stays in Fedora. If it does everything planned you may even see it in a 6.x point release. This after only about a year in distribution. An overview on Wikipedia: http://en.wikipedia.org/wiki/Systemd A year-old article summarizing blog posts by authors of upstart and systemd http://www.h-online.com/open/news/item/Systemd-presented-as-SysV-Init-and-Upstart-alternative-991875.html A year-old (30 Apr 2010) Lennart Poettering (systemd author) blog post announcing systemd with detail about systemd: http://0pointer.de/blog/projects/systemd.html A recent (28 Apr 2011) blog post by Lennart Poettering attempting to answer the question Why systemd?. Includes a side-by-side comparison of features between sysvinit, upstart, and systemd. http://0pointer.de/blog/projects/why.html A year-old (30 Apr 2010) blog post by Scott Remnant (upstart author) with candid remarks about systemd. http://netsplit.com/2010/04/30/on-systemd/ ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOs 5.6 and Time Sync
On Thu, 2011-04-14 at 13:28 +0200, Simon Matter wrote: On 4/14/2011 6:47 AM, Johnny Hughes wrote: Is it really true that the time is working perfectly with one of the other kernels (the older ones)? Johnny, Yes, As long as I run the older 5.5 kernel my time is perfect. All clients can get from this machine with no issues. As soon as I run new kernel, or Plus kernel for that matter. The time goes downhill. Uphill actually To answer the previous question I do have the HW clock set to utc, Everything is stock from initial install of the package. Did you check dmesg which timer is being used (I think it can also be seen somewhere in /proc but I don't remember). If it's hpet, you could try to disable it. That was for i686: 'hpet=disable' and for x86_64: 'nohpet', don't know how it is with current kernels. Simon Forgive me if I've missed a later post but it looked like this thread was stagnant... You may have something here Simon. I was thinking about your suggestion that it could be a timer issue. I'm wondering if the default clocksource or some related timer kernel parameter has been changed between 2.6.18-194.17.4.el5 (5.5) and 2.6.18-238.5.1.el5 (5.6). Timer related issues could very well account for this large, inconsistent NTP drift as well as Florin Andrei's bizarre tar, scp, and NTP issues in the [CentOS] bizarre system slowness thread. System interrupts are based on the clocksource chosen by (or configured in) the kernel. Any service or facility that uses these interrupts could be experiencing problems. Can anyone on the list confirm whether or not timer related kernel parameters have changed in 5.6? I don't have source handy and I'm going out the door in minutes. Reading up on kernel timer options, I came across these articles. # Discusses mis-detected timer frequency 9.2.4.2.7. Kernel 2.6 Mis-Detecting CPU TSC Frequency http://support.ntp.org/bin/view/Support/KnownOsIssues#Section_9.2.4.2.7. # Describes ntpd instability from some time sources # Includes data and graphs from detailed study http://www.ep.ph.bham.ac.uk/general/support/adjtimex.html I checked clock sources on a few systems under my control to see what came up. None are experiencing this problem. The CentOS and FC12 machines are isolated from the Internet while the FC14 laptop connects. My sample CentOS 5.5 5.6 systems are different hardware platforms. The 5.6 box doesn't have the hpet timer available so it may just not be susceptible to this problem. I'll be updating the 5.5 sample to 5.6 tomorrow which does have hpet available so I should know something more then. # Used these to get available and current clocksource: cat /sys/devices/system/clocksource/clocksource0/available_clocksource cat /sys/devices/system/clocksource/clocksource0/current_clocksource # CentOS 5.5: Available: acpi_pm jiffies hpet tsc pit Current: tsc # CentOS 5.6: Available: acpi_pm jiffies tsc pit Current: tsc # Fedora 12: Available: tsc hpet acpi_pm Current: tsc # Fedora 14: Using hpet Available: hpet acpi_pm Current: hpet ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Two cleanly installed CentOS 5.6 servers but with different Xen kernel versions
On Fri, 2011-04-15 at 16:37 +0200, Hans Vos wrote: Hello Cal, Thank you for your reply. It's possible that your #2 server has not rebooted or had problems with the latest kernel or just has the default set to something other than 0 in grub.conf. I did a reboot and checked the grub.conf. Should have mentioned that. What's the output of: egrep 'default|title' /etc/grub.conf # egrep 'default|title' /etc/grub.conf default=0 title CentOS (2.6.18-238.5.1.el5xen) title CentOS (2.6.18-238.el5xen) yum list kernel | grep kernel yum list kernel | grep kernel kernel.x86_64 2.6.18-238.5.1.el5 updates Ryan is right. The mirrors need to sync up. That's most likely the cause. Still, it's curious why you have two kernels listed in grub.conf and only one listed from yum. You should also see the 2.6.18-238.el5xen kernel listed. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Two cleanly installed CentOS 5.6 servers but with different Xen kernel versions
On Fri, 2011-04-15 at 17:00 +0200, Hans Vos wrote: Hello, Ryan is right. The mirrors need to sync up. That's most likely the cause. Still, it's curious why you have two kernels listed in grub.conf and only one listed from yum. You should also see the 2.6.18-238.el5xen kernel listed. Well, I copied the /var/cache/yum/timedhosts.txt file from server 1 to server 2. Then run yum update and all kinds of errors came flying at me. So I just SCP'ed the whole /var/cache/yum directory of server 1 to server 2. Ran yum update and there were the updates I was missing including the new kernel-xen. I don't know if this was the *proper* way of fixing it but it did the job :P. You shouldn't need to copy the timedhosts.txt file the fastestmirrors yum plugin should recreate it. You might check /var/log/yum.log or /var/log/messages to make some sense of the errors. I don't see any harm in using the cache from the other machine, though. ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Two cleanly installed CentOS 5.6 servers but with different Xen kernel versions
On Fri, 2011-04-15 at 11:07 -0400, Ryan Wagoner wrote: On Fri, Apr 15, 2011 at 11:00 AM, Hans Vos h...@laissezfaire.nl wrote: Well, I copied the /var/cache/yum/timedhosts.txt file from server 1 to server 2. Then run yum update and all kinds of errors came flying at me. So I just SCP'ed the whole /var/cache/yum directory of server 1 to server 2. Ran yum update and there were the updates I was missing including the new kernel-xen. I don't know if this was the *proper* way of fixing it but it did the job :P. Not sure the outcome of copying the yum directory. I would have just run yum clean all then yum update. Ryan +1 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOs 5.6 and Time Sync
On Wed, 2011-04-13 at 13:08 -0400, Rob Kampen wrote: Mailing List wrote: On 4/13/2011 7:35 AM, Mailing List wrote: Hi, I have upgraded my Dell C151 to the latest 5.6. I have always used ntp to sync this machine and then the rest of the machines in the network would sync from it. Since the update I cannot keep the right time on the machine. This is with / without ntp. I have attempted various scenario's with no luck. I am now trying the old kernel now as I type this out. If anyone else has any links or ideas that I should check out It would be greatly appreciated. Just a quick note about my setup. I do not use any gui. As mentioned I have not had any issues with this machine and it's time until I upgrade. AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ 3gb of ram. TIA. Brian. Just to follow up, I had switched to the old kernel before the 5.6 upgrade, and at this time my clock is working flawlessly. kernel v. 2.6.18-194.32.1.el5 Works as it should... kernel v. 2.6.18-238.5.1.el5 I cannot get my clock accurate. there are two other 238 kernels - do they show the same behavior? If there is anything I can do to help solve this IE: information or test. please let me know.At this point I will just make the old kernel default boot until there is a kernel update where which I will try again. Brian. You don't say what version of ntp you are using or whether the system in question can access the Internet. Should be: ntp-4.2.2p1-9.el5.centos.2.1.i386 [Refs] http://www.ntp.org/ http://support.ntp.org/bin/view/Support/WebHome http://www.eecis.udel.edu/~mills/ntp/html/index.html http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/s1-dateconfig-ntp.html /usr/share/doc/ntp-version/ntpd.htm [Main config files] /etc/ntp.conf /var/lib/ntp/drift /etc/ntp/step-tickers [Time Sources] Three time sources you can use for your ntpd: 1. Public or corporate NTP servers If you have an Internet connection using a public ntp pool is the simplest. http://www.pool.ntp.org/en/use.html 2. An accurate external reference clock http://doc.ntp.org/4.2.0/refclock.html Use if you need microsecond or better accuracy and you've got time and money to setup. 3. Undisciplined local clock on a local computer http://doc.ntp.org/4.2.0/drivers/driver1.html This is what I use. You can use this if a few seconds off every few months is less important than all clients being in sync. If it drifts at least all clients will drift with it. You can compensate easily for minor drift too. As long as all clocks are synced to the same source you should be able to tolerate being off by even a few minutes from the real time. Some networked services such as Kerberos cannot tolerate differences in time stamps between client and server. You'll get lots of seemingly arbitrary faults and errors with AD Windows Domains and Linux-based directory authentication and such if all participants are not time-synced. Sounds like you're using your system clock. Here's how my isolated networks are configured: [Primary server] Machine with most stable system clock - uses system clock, compensating for calculated drift in /var/lib/ntp/drift. [Secondary servers] One main RHEL/CentOS server in each of 3 buildings uses primary ntp server as master and sister servers as peers. [Clients] CentOS, Windoze DC, Windows stand-alone, and Unix configured to sync with secondary ntp servers using the closest first. [Using undisciplined system clock] Best way to determine most stable clock is to: 1. turn ntpd off 2. Sync time with accurate server I use http://wwp.greenwichmeantime.com/time-zone/usa/eastern-time/ 3. Wait days or weeks to check system time against same source 4. Calculate and set drift 5. Start ntpd 6. Check against same time source periodically... every few weeks at first until it's as close as you can get it. 7. Adjust frequency offset and drift values for local (system) clock 8. Start ntpd and use this as server in secondary servers. Sync secondary servers or just clients off this primary. There are many ways to configure and implement ntp. You should study the references and determine which options are best for your specific needs. If you wish I can provide sample ntp.conf files, and details of my calibration process. I'm kind of busy right now but I'll throw something together as time permits and forward if you want. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOs 5.6 and Time Sync
On Wed, 2011-04-13 at 14:42 -0400, Mailing List wrote: On 4/13/2011 1:08 PM, Rob Kampen wrote: there are two other 238 kernels - do they show the same behavior? I will install kernel-2.6.18-238.5.1.el5.centos.plus and let the list know how it goes. I totally forgot that there was a Plus repo. I actually had it disabled. Brian. That's probably not what you want. See this first: http://wiki.centos.org/AdditionalResources/Repositories/CentOSPlus?highlight=%28centosplus%29 ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOs 5.6 and Time Sync
On Wed, 2011-04-13 at 15:10 -0400, Mailing List wrote: On 4/13/2011 2:50 PM, Cal Webster wrote: [snip] The ntp server does connect to the internet fine. the version of ntp is as follows. ntp-4.2.2p1-9.el5.centos.2.1 The time is not off by a matter of minutes or I would not crab so much. It gets to the point of being more then an hour off after setting it. And also Dovecot dies after setting the tuime so much. As I had posted before, I never had any issue with the sync till I updated to 5.6. And whe I rolled it back to the old kernel time and sync went along flawlessly. Brian. I'm running the same kernel and ntp versions and I'm having no problems at all on ntp servers or clients. If my previous suggestions didn't help maybe you could share contents of the following files and output of some commands so the list can see what you've got. /etc/ntp.conf /etc/ntp/ntpservers /etc/ntp/step-tickers /var/lib/ntp/drift grep ntpd /var/log/messages* (please remove repeated messages for clarity) Most recent entries in /var/log/ntpd.log SELinux could also be playing a role. Are you running SELinux enabled, permissive, or disabled? What mode was it running before it stopped working? Are there any possibly related avc messages in /var/log/messages or /var/audit/audit.log? ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOs 5.6 and Time Sync
On Wed, 2011-04-13 at 16:00 -0400, Daniel J Walsh wrote: [snip] The avc messages are in /var/log/audit/audit.log ausearch -m avc -ts recent Will also show you recent AVC messages. audit2allow -la will search for any avc message in /var/log/audit/audit.log or /var/log/messages since the last policy load. Thanks for correcting me and providing the additional tools for the OP to use. I sometimes mis-type when in a hurry. I'd use caution with audit2allow, though, as this tool only shows you what to do to get rid of the avc denial message(s). It makes no judgement whether the resulting policy will be appropriate or safe. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] bizarre system slowness
On Wed, 2011-04-13 at 13:06 -0700, Florin Andrei wrote: Running v5 64bit on a Dell 1950. A cluster of 3 DB machines, identical hardware. One of them suddenly became slower 2 weeks ago. tar -zxf with a large file on this machine takes 1.5 minutes, but takes only 10 seconds on any of its siblings. CPU usage seems high while untarring, with lots of user and sys cycles being used, but almost no wait cycles. It doesn't matter whether I untar on a local disk, or on a fiber channel SAN volume, it's slow anyway. scp a file over the network is slow too: 6 MB/s to this machine, 70 MB/s to its siblings. However, this is just as fast on all systems, including the sick one: # time dd if=/dev/zero of=/dev/null bs=1M count=10 10+0 records in 10+0 records out 10485760 bytes (105 GB) copied, 2.59213 seconds, 40.5 GB/s real 0m2.600s user 0m0.025s sys 0m2.550s /proc/cpuinfo looks fine. Nothing suspect in dmesg. Reboot doesn't fix it. Power off / power on doesn't fix it. Single mode is slow too, and I tried a couple different kernels. Dell's online diagnostics program could find nothing wrong with it. /var/log/messages was full of ntpd[7313]: frequency error -1707 PPM exceeds tolerance 500 PPM messages. There was a lot of messages about the system limit for the maximum number of semaphore sets has been exceeded; there was indeed a lot of leftover semaphores created by NRPE (owned by the nagios user); I deleted them but nothing has changed, so they were a symptom, not the cause. Are the system times different between the siblings? Are all 3 siblings running ntpd and using the same time source (server(s))? Do the symptoms change with ntpd stopped/running? Are the frequency offsets the same on each sibling? Since your log messages appear to be ntp related, you might try resetting your frequency offset and drift values. Having a -1707 PPM offset could cause many issues like you describe. service ntpd stop ntptime -f 0 echo 0 /var/lib/ntp/drift service ntpd start I'm still kind of hoping it's a software issue, but chances are slim. OTOH, I can't imagine any hardware problem that would exhibit these symptoms. Any idea what to test? ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOs 5.6 and Time Sync
On Wed, 2011-04-13 at 16:22 -0400, Mailing List wrote: On 4/13/2011 3:35 PM, Cal Webster wrote: I'm running the same kernel and ntp versions and I'm having no problems at all on ntp servers or clients. If my previous suggestions didn't help maybe you could share contents of the following files and output of some commands so the list can see what you've got. /etc/ntp.conf /etc/ntp/ntpservers /etc/ntp/step-tickers /var/lib/ntp/drift grep ntpd /var/log/messages* (please remove repeated messages for clarity) Most recent entries in /var/log/ntpd.log SELinux could also be playing a role. Are you running SELinux enabled, permissive, or disabled? What mode was it running before it stopped working? Are there any possibly related avc messages in /var/log/messages or /var/audit/audit.log? ./Cal /etc/ntp; restrict default kod nomodify notrap nopeer noquery restrict -6 default kod nomodify notrap nopeer noquery restrict 127.0.0.1 restrict -6 ::1 server 0.centos.pool.ntp.org server 1.centos.pool.ntp.org server 2.centos.pool.ntp.org server 127.127.1.0 # local clock fudge 127.127.1.0 stratum 10 driftfile /var/lib/ntp/drift keys /etc/ntp/keys There is no /etc/ntp/ntpservers /etc/ntp/step-tickers is an empty file. /var/lib/ntp/drift; -65.219 I have no /var/log/ntpd.log /varlog/messages; This is the log using stock updated kernel. Apr 12 03:32:35 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 03:33:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 15:51:56 Server ntpd[2797]: time reset +43208.248852 s Apr 12 15:51:56 Server ntpd[2797]: kernel time sync enabled 0001 Apr 12 15:56:03 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 15:56:26 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:00:22 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:16:59 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:16:57 Server ntpd[2797]: time reset -1.830305 s Apr 12 16:20:27 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:22:35 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 2 Apr 12 16:28:01 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:32:29 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:36:36 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:40:05 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:41:57 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:42:09 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:47:28 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 16:48:28 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 16:51:44 Server ntpd[2797]: synchronized to 173.9.142.98, stratum 2 Apr 12 16:53:52 Server ntpd[2797]: synchronized to 173.193.227.67, stratum 4 Apr 12 16:58:06 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:00:18 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 17:04:31 Server ntpd[2797]: synchronized to 169.229.70.183, stratum 3 Apr 12 17:06:44 Server ntpd[2797]: synchronized to LOCAL(0), stratum 10 Apr 12 19:54:46 Server ntpd[2797]: ntpd exiting on signal 15 Apr 13 03:01:24 Server ntpd[2409]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1) Apr 13 03:01:24 Server ntpd[2410]: precision = 1.000 usec Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, 0.0.0.0#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface wildcard, ::#123 Disabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, ::1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, fe80::218:8bff:fe80:67db#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface lo, 127.0.0.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: Listening on interface eth0, 192.168.2.1#123 Enabled Apr 13 03:01:24 Server ntpd[2410]: kernel time sync status 0040 Apr 13 03:01:30 Server ntpd[2410]: frequency initialized 0.000 PPM from /var/lib/ntp/drift Apr 13 07:04:44 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:04:44 Server ntpd[2410]: kernel time sync enabled 0001 Apr 13 07:11:09 Server ntpd[2410]: synchronized to 208.75.88.4, stratum 2 Apr 13 07:17:34 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 07:42:59 Server ntpd[2410]: time reset -27.586767 s Apr 13 07:46:35 Server ntpd[2410]: synchronized to LOCAL(0), stratum 10 Apr 13 07:47:38 Server ntpd[2410]: synchronized to 199.249.224.123, stratum 2 Apr 13 07:51:53 Server ntpd[2410]: synchronized to 64.6.144.6, stratum 2 Apr 13 09:27:19 Server ntpd[2410]: ntpd exiting on signal 15 Apr 13 09:27:19 Server ntpd[6743]: ntpd 4.2.2p1@1.1570-o Sat Dec 19 00:56:13 UTC 2009 (1) Selinux is disabled, and just a note also
Re: [CentOS] CentOs 5.6 and Time Sync
On Wed, 2011-04-13 at 17:42 -0400, Mailing List wrote: On 4/13/2011 5:24 PM, Cal Webster wrote: ntpq -c pe -c as root ~# ntpq -c pe -c as remote refid st t when poll reach delay offset jitter == bindcat.fhsu.ed 132.163.4.1012 u 1015 1024 377 49.987 -15082. 6919.88 216.45.57.38108.71.253.182 u 998 1024 377 83.112 -15139. 6900.14 javanese.kjsl.c 69.36.224.15 2 u1 1024 377 109.083 -29233. 7285.83 *LOCAL(0).LOCL. 10 l 13 64 3770.0000.000 0.001 ind assID status conf reach auth condition last_event cnt === 1 26525 9044 yes yes nonereject reachable 4 2 26526 9044 yes yes nonereject reachable 4 3 26527 9044 yes yes nonereject reachable 4 4 26528 9644 yes yes none sys.peer reachable 4 root ~# Right now everything is running as it should. I did indeed switch to the CentOSplus kernel. And it is working as it should. I would need to go back to the stiock updated kernel from the 5.5 - 5.6 upgrade.. Brian. Your ntpq output tells me that all the ntp.org servers have been rejected in favor of your (undisciplined) local clock. You should disable it as a time source in ntp.conf as suggested previously. You gain nothing by keeping it configured under your circumstances. ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] [Thank you!] IMHO only RHEL is better than CentOS...
I've learned to help pay for what I've been so generously given in CentOS and other OSS projects. Hopefuly, others will do the same and we'll all benefit and live happily ever after... er, um... okay, well at least we'll all benefit. :-) Very Gratefully Yours, Cal Webster ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] [Thank you!] IMHO only RHEL is better than CentOS...
On Tue, 2011-04-12 at 14:08 -0700, aurfal...@gmail.com wrote: On Apr 12, 2011, at 1:43 PM, Cal Webster wrote: ...based on my experience, for use in all non-certified enterprise operations (large and small) on general-purpose computers. Wow, what a great post. Thanks Carl, very cool. Thanks for letting me know someone read it Aurf. If I've helped encourage even one I'm happy. Hope you aren't retiring any time soon, I see too many barnies in charge making thoughtless decisions. As a consultant I'm often on the outside looking in and what I see is a scary trend of rash and flippant choices. - aurf Retire? Not likely anytime soon with 3 kids, 5 grandkids (and many pseudo-grands) and more on the way. Besides, there's so much left to see and do and so little time... Thanks to CentOS and OSS I'll never really have to retire anyway. ;-) ./Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 5 Security Updates
Does anyone know the time-frame when security updates might be published for these applications in CentOS 5? wireshark postgresql krb5 java-1.6.0-openjdk java-1.6.0-sun The following security updates have been published upstream (after release of RHEL 5.6) to remedy the vulnerabilities described in their associated CVE reports. Remotely Exploitable: (R) RHSA-2011:0013: Moderate: wireshark security update 1/10/11 [CVE-2010-4538] (R) RHSA-2011:0197: Moderate: postgresql security update 2/3/11 [CVE-2010-4015] (R) RHSA-2011:0199: Important: krb5 security update 2/8/11 [CVE-2011-0281] (R) [CVE-2011-0282] (R) RHSA-2011:0281: Important: java-1.6.0-openjdk security update 2/17/11 CVE-2010-4448 (R) CVE-2010-4450 CVE-2010-4465 (R) CVE-2010-4469 (R) CVE-2010-4470 (R) CVE-2010-4472 (R) RHSA-2011:0282: Critical: java-1.6.0-sun security update 2/17/11 CVE-2010-4422 (R) CVE-2010-4447 (R) CVE-2010-4448 (R) CVE-2010-4450 CVE-2010-4451 (R) CVE-2010-4452 (R) CVE-2010-4454 (R) CVE-2010-4462 (R) CVE-2010-4463 (R) CVE-2010-4465 (R) CVE-2010-4466 (R) CVE-2010-4467 (R) CVE-2010-4468 (R) CVE-2010-4469 (R) CVE-2010-4470 (R) CVE-2010-4471 (R) CVE-2010-4472 (R) CVE-2010-4473 (R) CVE-2010-4475 (R) CVE-2010-4476 (R) I know the development team is furiously working to get 5.6 out the door so I understand that there will be delays. However, it was my understanding that Critical security updates and those that are remotely exploitable would be pushed out ahead of 5.6. If 5.6 is not forthcoming I think many of us would like to see at least the security updates to cover potential vulnerabilities. Many thanks to the development team for all their hard work! :-) Respectfully, Cal Webster ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 Security Updates
On Thu, 2011-02-24 at 14:28 -0500, R P Herrold wrote: On Thu, 24 Feb 2011, Cal Webster wrote: java-1.6.0-sun non FOSS, non-source provided, no? This is in an addon channel in RHEL, and so far as I know we have never shipped such You're right - shouldn't have listed that one. I manage both RHEL and CentOS machines so this came up on the radar. Of the others the wireshark update is a periodic update of some edge case dissectors [these developers are quite good about releasing time based 'fixes' for their tool -- a different model than upstream, but perfectly valid], and if nominally remotely exploitable, as a practical matter, not a material threat Agreed. We don't use most of the dissectors that get called out either and it's easy to disable them. However, our organizational directives require full IA compliance so I have to show due diligence in resolving every vulnerability. For those that cannot be resolved I must supply work-arounds to mitigate them and a plan of action to resolve it in the end. The kerberos update crossed vendor-sec, but seems again to be an edge case hole Not critical for us since none of our engineering networks touch the Internet. If I had a public facing server, though, I'd hate to have to wonder if I might be one of those edge cases. The pgsql update is nominally exploitable, but any sensible environment uses iptables and network segment isolation rather than adding a world listening daemon True. Any enterprise operation that doesn't take such basic security precautions is asking for trouble. Still, the IA Gestapo doesn't make such distinctions. I have commented earlier on my distress at the openjdk update NOT crossing vendor-sec. This said, again, who in their right mind exposes an unprotected Java listener application to the wild? I don't disagree with you. Those who evaluate CVE's for applicability to an enterprise don't often have the technical background to distinguish between a practical and theoretical threat. For them, and because of the way $#!+ rolls downhill, myself the vulnerability must be addressed. I saw that another in the project mentioned 'bypassing' the 5.6 respin and testing delays for truly exploitable matter. The potential 'bind' updates dos attack vector turned out not to affect anything CentOS has shipped in base and updates, and so was a 'false positive' as prior discusseio here has noted If one wants SLA and deterministic intervals between announcement and release, it is just not that hard to set up one off building and updates from released sources upstream, and so one can have it at the price of a little learning and experimentation. When things settle a bit in my org and CentOS I'd like to do just that, if for nothing else than the instructional value. Alternatively, CentOS releases promptly on the usual norm, and during 'point' update times, falls back to trying to avoid 'dependency skew' problems by considering the potential disruption for millions of machines each needing manual depsolving intervention, vs. getting the nest update build and QA's and out the door in a durable fashion. Until this 3-way, back-to-back release (4.9, 5.6, 6.0) updates were plenty prompt for me. I totally understand the issues behind the delays. If that is not 'quick enough', see the prior paragraph about self-building; or seek a vendor who will sell you the SLA you deem you require. This is a simple 'build vs buy' decision Thank you for your cordial, detailed reply. We do have a standby OSS support contract based on hourly rate but only intend to use it for true emergencies. [I might note that I have seen NO filed bug in the CentOS tracker asserting a need for any of the listed updates on an expedited basis] Is that how it's done? Until now I haven't paid much attention to the process. No need since updates were fairly swift after upstream release. I report bugs directly upstream via our RH Support entitlement. I'm not sure any such assertions from me would carry much weight anyway. Even if they did I'd imagine there wouldn't be much spare manpower to act on it at this point. -- Russ herrold ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 Security Updates
On Thu, 2011-02-24 at 11:30 -0800, Akemi Yagi wrote: On Thu, Feb 24, 2011 at 11:02 AM, Cal Webster cwebs...@ec.rr.com wrote: I know the development team is furiously working to get 5.6 out the door so I understand that there will be delays. However, it was my understanding that Critical security updates and those that are remotely exploitable would be pushed out ahead of 5.6. That is my understanding, too. However, I see that the only Critical one on your list is java-1.6.0-sun. This is not included in CentOS... Thank you for your input Akemi. As I said in my response to Russ, that one should not have been on my list. All, however, do have remote exploits. These I also discussed with Russ. Regards, Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 5 Security Updates
On Thu, 2011-02-24 at 22:00 +0100, Kai Schaetzl wrote: I wish people would read the list archives instead of posting the same kind of questione time and again. Kai Thank you for your thoughts Kai. I have invested quite a bit of time reading the CentOS and CentOS-Devel archives, including this one from KB: http://lists.centos.org/pipermail/centos/2011-February/105486.html Seems to me that my post was both relevant and appropriate. All the vulnerabilities I cited were either Critical or remotely exploitable. If my specific query was answered elsewhere, off topic, or out of line I apologize. See my earlier response to Russ's kind, detailed reply for more. I've also read the FAQ: http://wiki.centos.org/FAQ/General ...as well as Eric and Rick's Smart Questions FAQ (all common sense): http://www.catb.org/~esr/faqs/smart-questions.html This is not my first time around the block Kai. As much as I hate wasting my own time, I will go out of my way to avoid wasting that of others... especially those who are working hard on their own time on my behalf. I only ask questions when I can't find answers using local or on-line resources. I always try to make my questions concise but with sufficient detail for others to answer, selecting the appropriate forum based upon community guidelines. I'm not easily offended so I welcome constructive criticism, even harsh critique. You'll find me to be considerate, respectful, and generous because I try to treat others the same way I expect to be treated. Please don't be offended if I do not respond to additional replies. I see no benefit to the list or myself in extended arguments. Cal ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
