From patrik.martinsson at smhi.se Mon Sep 2 13:28:58 2013 From: patrik.martinsson at smhi.se (Martinsson Patrik) Date: Mon, 2 Sep 2013 13:28:58 +0000 Subject: [rhelv6-list] Safely storing passwords to private keys, Message-ID: Hello, My name is Patrik Martinsson and I work as a system administrator at the Swedish Meteorological Hydrological Institute. I'm looking for some advice regarding "safely" storing certificates with private keys on Linux clients running Rhel 6.4. We have around 150 Linux client, all centrally managed by puppet. Recently we made it possible for a client to acquire a certificate from a central scep-server. That certificate including the private key will then be used to authenticate the client against our 802.1x network. I'm just curious about if there are any recommendations regarding how to "safely" store the private key (or actually the password to the private key) on the client. In Windows I know there's some sort of "certificate store" where you could store your certificate/keys (and the password i guess) and mark them as non-exportable (and yes, I also know that there are ways around it, so you can actually retrieve the private keys anyway if you have the know-how). The way we are testing it right now, (on 2-3 clients) is to have the certificate and the key as a .p12 bundle and readable by everyone (since anyone who logs into the computer should be able to use the network), and then point NetworkManager to it. The .p12-bundle is password-protected, so if anyone tries to copy the .p12 bundle they also need the password (which is stored in clear-text by NetworkManager in the /etc/sysconfig/network-scripts/keys-Auto_ssid-file, since we checked the "Available to all users checkbox in NetworkManager". If we don't check that box, the password to the .p12-bundle would be available to the user). Anyway, I'm just looking at ways to "safely" store the bundle (same goes here, actually its the password to the private key I want to store in a safe manner) in some "smart way" that doesn't make it obvious to a regular user how to steel a certificate incl. the private key and the password. Which today would be, - Boot livecd, - Copy certificate and 'cat /etc/sysconfig/network-scripts/keys-Auto_ssid-file' We were thinking about maybe using encfs (since its simple and in userspace) on a folder, where we then would store the password to the key (and then point the /etc/sysconfig/network-scripts/keys-Auto_ssid-file to that location). We would then unlock the folder with the password at boot. But that doesn't *really* add any extra security, it would only add some complexity regarding managing our clients. The method to get the actual password to the private key would then be something like, - Boot livecd - Copy certificate - Notice that '/etc/sysconfig/network-scripts/keys-Auto_ssid-file' is a link to some encrypted file, - Find the "start-script" that actually unlocks the folder, run it manually and then copy/cat the password-file. It adds the step "Find the start-script that unlocks the folder", but anyone with some basic Linux-knowledge would figure that out. Any ideas are more then welcome, Best Regards, Patrik Martinsson ITi SMHI Telefon 011 - 495 84 17 Fax 011 - 495 83 50 Mobil 011 - 495 84 17 Epost Patrik.Martinsson at smhi.se 601 76 Norrk?ping Bes?ksadress Folkborgsv?gen 1 www.smhi.se -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim.leinweber at slh.wisc.edu Wed Sep 4 15:53:50 2013 From: jim.leinweber at slh.wisc.edu (Leinweber, James) Date: Wed, 4 Sep 2013 10:53:50 -0500 Subject: [rhelv6-list] is anyone else having multi-arch issues with neon? Message-ID: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> The RHEA-2013:1188-1 neon bug fix suddenly wants to pull in 32-bit versions on my 64-bit systems, which is causing "yum update" to fail with multilib protection problems, particularly: Protected multilib versions: neon-0.29.3-3.el6_4.x86_64 != neon-0.29.3-2.el6.i686 Eventually I'm going to get tired of running: yum update --exclude neon Is everyone else suffering from this too, and do we need to open a case with Redhat about it? -- Jim Leinweber State Laboratory of Hygiene, University of Wisconsin - Madison phone +1 608 221 6281 PGP fp: D573 AF7D F484 EE2A F0B6 B7DB A870 7518 F87D A0D1 From ajb at elrepo.org Wed Sep 4 16:02:01 2013 From: ajb at elrepo.org (Alan Bartlett) Date: Wed, 4 Sep 2013 17:02:01 +0100 Subject: [rhelv6-list] is anyone else having multi-arch issues with neon? In-Reply-To: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> References: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> Message-ID: On 4 September 2013 16:53, Leinweber, James wrote: > The RHEA-2013:1188-1 neon bug fix suddenly wants to pull in > 32-bit versions on my 64-bit systems, which is causing > "yum update" to fail with multilib protection problems, > particularly: > > Protected multilib versions: neon-0.29.3-3.el6_4.x86_64 != > neon-0.29.3-2.el6.i686 > > Eventually I'm going to get tired of running: > yum update --exclude neon > > Is everyone else suffering from this too, and do we need to > open a case with Redhat about it? > > -- Jim Leinweber With a pure 64-bit system, I do not experience that problem. [quote] [Duo2 ~]$ grep exclude /etc/yum.conf exclude = *.i?86 [Duo2 ~]$ rpm -q neon neon-0.29.3-3.el6_4.x86_64 [Duo2 ~]$ sudo grep neon /var/log/yum.log Sep 04 02:01:43 Updated: neon-0.29.3-3.el6_4.x86_64 [Duo2 ~]$ [/quote] Alan. From mschwendt at gmail.com Thu Sep 5 11:25:38 2013 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 5 Sep 2013 13:25:38 +0200 Subject: [rhelv6-list] is anyone else having multi-arch issues with neon? In-Reply-To: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> References: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> Message-ID: <20130905132538.5e9d25af@faldor.intranet> On Wed, 4 Sep 2013 10:53:50 -0500, Leinweber, James wrote: > The RHEA-2013:1188-1 neon bug fix suddenly wants to pull in > 32-bit versions on my 64-bit systems, which is causing > "yum update" to fail with multilib protection problems, > particularly: > > Protected multilib versions: neon-0.29.3-3.el6_4.x86_64 != > neon-0.29.3-2.el6.i686 What's the full output? 3.el6_4 is a rather recent update. > Is everyone else suffering from this too, and do we need to > open a case with Redhat about it? That would be justified, since such a multilib conflict means that there's a non-arch-specific dep on neon somewhere else and that the update is incompatible. Attempting to resolve the broken dep, the dependency resolver finds that the previous i686 build satisfies the dependency. Hence it tries to pull in the i686 build. From jim.leinweber at slh.wisc.edu Thu Sep 5 15:11:40 2013 From: jim.leinweber at slh.wisc.edu (Leinweber, James) Date: Thu, 5 Sep 2013 10:11:40 -0500 Subject: [rhelv6-list] is anyone else having multi-arch issues with neon? In-Reply-To: <20130905132538.5e9d25af@faldor.intranet> References: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> <20130905132538.5e9d25af@faldor.intranet> Message-ID: <1298E81544388440ADBE9B0072AABD8112385780@slhmail2003.ad.slh.wisc.edu> To be more specific, all of my redhat 6.4 systems are 64-bit; some have more 32-bit compatibility stuff installed than others. The ones with no i686 packages at all install the 64-bit neon update just fine. On systems where: $ rpm -qa | grep i686 yields: compat-libstdc++-296-2.96-144.el6.i686 glibc-2.12-1.107.el6_4.4.i686 libX11-1.5.0-4.el6.i686 libXau-1.0.6-4.el6.i686 libXext-1.3.1-2.el6.i686 libXp-1.0.0-15.1.el6.i686 libXp-devel-1.0.0-15.1.el6.i686 libgcc-4.4.7-3.el6.i686 libxcb-1.8.1-1.el6.i686 nss-softokn-freebl-3.14.3-3.el6_4.i686 Running "sudo yum update -y" for the neon package fails thusly: ----------------- Loaded plugins: downloadonly, refresh-packagekit, rhnplugin This system is receiving updates from RHN Classic or RHN Satellite. rhel-x86_64-server-6 | 1.8 kB 00:00 Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package microcode_ctl.x86_64 1:1.17-14.el6 will be updated ---> Package microcode_ctl.x86_64 1:1.17-15.el6_4 will be an update ---> Package neon.x86_64 0:0.29.3-2.el6 will be updated --> Processing Dependency: neon = 0.29.3-2.el6 for package: neon-devel-0.29.3-2.el6.x86_64 ---> Package neon.x86_64 0:0.29.3-3.el6_4 will be an update --> Running transaction check ---> Package neon.i686 0:0.29.3-2.el6 will be installed --> Processing Dependency: libz.so.1 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libproxy.so.0 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libpakchois.so.0 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libkrb5.so.3 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libk5crypto.so.3 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libgssapi_krb5.so.2(gssapi_krb5_2_MIT) for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libgssapi_krb5.so.2 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libgnutls.so.26(GNUTLS_1_4) for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libgnutls.so.26 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libexpat.so.1 for package: neon-0.29.3-2.el6.i686 --> Processing Dependency: libcom_err.so.2 for package: neon-0.29.3-2.el6.i686 ---> Package neon.x86_64 0:0.29.3-2.el6 will be updated --> Running transaction check ---> Package expat.i686 0:2.0.1-11.el6_2 will be installed ---> Package gnutls.i686 0:2.8.5-10.el6_4.2 will be installed --> Processing Dependency: libtasn1.so.3(LIBTASN1_0_3) for package: gnutls-2.8.5-10.el6_4.2.i686 --> Processing Dependency: libtasn1.so.3 for package: gnutls-2.8.5-10.el6_4.2.i686 --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4) for package: gnutls-2.8.5-10.el6_4.2.i686 --> Processing Dependency: libstdc++.so.6(CXXABI_1.3) for package: gnutls-2.8.5-10.el6_4.2.i686 --> Processing Dependency: libstdc++.so.6 for package: gnutls-2.8.5-10.el6_4.2.i686 --> Processing Dependency: libgcrypt.so.11(GCRYPT_1.2) for package: gnutls-2.8.5-10.el6_4.2.i686 --> Processing Dependency: libgcrypt.so.11 for package: gnutls-2.8.5-10.el6_4.2.i686 ---> Package krb5-libs.i686 0:1.10.3-10.el6_4.4 will be installed --> Processing Dependency: libselinux.so.1 for package: krb5-libs-1.10.3-10.el6_4.4.i686 --> Processing Dependency: libkeyutils.so.1(KEYUTILS_0.3) for package: krb5-libs-1.10.3-10.el6_4.4.i686 --> Processing Dependency: libkeyutils.so.1 for package: krb5-libs-1.10.3-10.el6_4.4.i686 ---> Package libcom_err.i686 0:1.41.12-14.el6_4.2 will be installed ---> Package libproxy.i686 0:0.3.0-4.el6_3 will be installed --> Processing Dependency: libdbus-1.so.3 for package: libproxy-0.3.0-4.el6_3.i686 ---> Package pakchois.i686 0:0.4-3.2.el6 will be installed ---> Package zlib.i686 0:1.2.3-29.el6 will be installed --> Running transaction check ---> Package dbus-libs.i686 1:1.2.24-7.el6_3 will be installed ---> Package keyutils-libs.i686 0:1.4-4.el6 will be installed ---> Package libgcrypt.i686 0:1.4.5-9.el6_2.2 will be installed --> Processing Dependency: libgpg-error.so.0 for package: libgcrypt-1.4.5-9.el6_2.2.i686 ---> Package libselinux.i686 0:2.0.94-5.3.el6_4.1 will be installed ---> Package libstdc++.i686 0:4.4.7-3.el6 will be installed ---> Package libtasn1.i686 0:2.3-3.el6_2.1 will be installed --> Running transaction check ---> Package libgpg-error.i686 0:1.7-4.el6 will be installed --> Finished Dependency Resolution Error: Multilib version problems found. This often means that the root cause is something else and multilib version checking is just pointing out that there is a problem. Eg.: 1. You have an upgrade for neon which is missing some dependency that another package requires. Yum is trying to solve this by installing an older version of neon of the different architecture. If you exclude the bad architecture yum will tell you what the root cause is (which package requires what). You can try redoing the upgrade with --exclude neon.otherarch ... this should give you an error message showing the root cause of the problem. 2. You have multiple architectures of neon installed, but yum can only see an upgrade for one of those arcitectures. If you don't want/need both architectures anymore then you can remove the one with the missing update and everything will work. 3. You have duplicate versions of neon installed already. You can use "yum check" to get yum show these errors. ...you can also use --setopt=protected_multilib=false to remove this checking, however this is almost never the correct thing to do as something else is very likely to go wrong (often causing much more problems). Protected multilib versions: neon-0.29.3-2.el6.i686 != neon-0.29.3-3.el6_4.x86_64 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest ---------------- I haven't opened a redhat ticket yet, but I probably will Real Soon Now. -- Jim Leinweber State Laboratory of Hygiene, University of Wisconsin - Madison phone +1 608 221 6281 PGP fp: D573 AF7D F484 EE2A F0B6 B7DB A870 7518 F87D A0D1 From vincent at cojot.name Thu Sep 5 15:27:20 2013 From: vincent at cojot.name (vincent at cojot.name) Date: Thu, 5 Sep 2013 11:27:20 -0400 (EDT) Subject: [rhelv6-list] is anyone else having multi-arch issues with neon? In-Reply-To: <1298E81544388440ADBE9B0072AABD8112385780@slhmail2003.ad.slh.wisc.edu> References: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> <20130905132538.5e9d25af@faldor.intranet> <1298E81544388440ADBE9B0072AABD8112385780@slhmail2003.ad.slh.wisc.edu> Message-ID: Hi James, Either get rid of the 32bit packages (I need them too so that's not an option) or try adding 'multilib_policy=all' to /etc/yum.conf and try to update again.. I, too, have some 6.4 systems where 32bit libs are always installed along their 64bit siblings and they updated without issues: $ cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.4 (Santiago) $ rpm -qa neon\*|sort neon-0.29.3-3.el6_4.i686 neon-0.29.3-3.el6_4.x86_64 neon-devel-0.29.3-3.el6_4.i686 neon-devel-0.29.3-3.el6_4.x86_64 My 2c, Vincent On Thu, 5 Sep 2013, Leinweber, James wrote: > To be more specific, all of my redhat 6.4 systems are 64-bit; some have > more 32-bit compatibility stuff installed than others. The ones with > no i686 packages at all install the 64-bit neon update just fine. On > systems where: > > $ rpm -qa | grep i686 > > yields: > > compat-libstdc++-296-2.96-144.el6.i686 > glibc-2.12-1.107.el6_4.4.i686 > libX11-1.5.0-4.el6.i686 > libXau-1.0.6-4.el6.i686 > libXext-1.3.1-2.el6.i686 > libXp-1.0.0-15.1.el6.i686 > libXp-devel-1.0.0-15.1.el6.i686 > libgcc-4.4.7-3.el6.i686 > libxcb-1.8.1-1.el6.i686 > nss-softokn-freebl-3.14.3-3.el6_4.i686 > > Running "sudo yum update -y" for the neon package fails thusly: > ----------------- > Loaded plugins: downloadonly, refresh-packagekit, rhnplugin > This system is receiving updates from RHN Classic or RHN Satellite. > rhel-x86_64-server-6 > | 1.8 kB 00:00 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package microcode_ctl.x86_64 1:1.17-14.el6 will be updated > ---> Package microcode_ctl.x86_64 1:1.17-15.el6_4 will be an update > ---> Package neon.x86_64 0:0.29.3-2.el6 will be updated > --> Processing Dependency: neon = 0.29.3-2.el6 for package: > neon-devel-0.29.3-2.el6.x86_64 > ---> Package neon.x86_64 0:0.29.3-3.el6_4 will be an update > --> Running transaction check > ---> Package neon.i686 0:0.29.3-2.el6 will be installed > --> Processing Dependency: libz.so.1 for package: neon-0.29.3-2.el6.i686 > --> Processing Dependency: libproxy.so.0 for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libpakchois.so.0 for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libkrb5.so.3 for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libk5crypto.so.3 for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libgssapi_krb5.so.2(gssapi_krb5_2_MIT) for > package: neon-0.29.3-2.el6.i686 > --> Processing Dependency: libgssapi_krb5.so.2 for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libgnutls.so.26(GNUTLS_1_4) for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libgnutls.so.26 for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libexpat.so.1 for package: > neon-0.29.3-2.el6.i686 > --> Processing Dependency: libcom_err.so.2 for package: > neon-0.29.3-2.el6.i686 > ---> Package neon.x86_64 0:0.29.3-2.el6 will be updated > --> Running transaction check > ---> Package expat.i686 0:2.0.1-11.el6_2 will be installed > ---> Package gnutls.i686 0:2.8.5-10.el6_4.2 will be installed > --> Processing Dependency: libtasn1.so.3(LIBTASN1_0_3) for package: > gnutls-2.8.5-10.el6_4.2.i686 > --> Processing Dependency: libtasn1.so.3 for package: > gnutls-2.8.5-10.el6_4.2.i686 > --> Processing Dependency: libstdc++.so.6(GLIBCXX_3.4) for package: > gnutls-2.8.5-10.el6_4.2.i686 > --> Processing Dependency: libstdc++.so.6(CXXABI_1.3) for package: > gnutls-2.8.5-10.el6_4.2.i686 > --> Processing Dependency: libstdc++.so.6 for package: > gnutls-2.8.5-10.el6_4.2.i686 > --> Processing Dependency: libgcrypt.so.11(GCRYPT_1.2) for package: > gnutls-2.8.5-10.el6_4.2.i686 > --> Processing Dependency: libgcrypt.so.11 for package: > gnutls-2.8.5-10.el6_4.2.i686 > ---> Package krb5-libs.i686 0:1.10.3-10.el6_4.4 will be installed > --> Processing Dependency: libselinux.so.1 for package: > krb5-libs-1.10.3-10.el6_4.4.i686 > --> Processing Dependency: libkeyutils.so.1(KEYUTILS_0.3) for package: > krb5-libs-1.10.3-10.el6_4.4.i686 > --> Processing Dependency: libkeyutils.so.1 for package: > krb5-libs-1.10.3-10.el6_4.4.i686 > ---> Package libcom_err.i686 0:1.41.12-14.el6_4.2 will be installed > ---> Package libproxy.i686 0:0.3.0-4.el6_3 will be installed > --> Processing Dependency: libdbus-1.so.3 for package: > libproxy-0.3.0-4.el6_3.i686 > ---> Package pakchois.i686 0:0.4-3.2.el6 will be installed > ---> Package zlib.i686 0:1.2.3-29.el6 will be installed > --> Running transaction check > ---> Package dbus-libs.i686 1:1.2.24-7.el6_3 will be installed > ---> Package keyutils-libs.i686 0:1.4-4.el6 will be installed > ---> Package libgcrypt.i686 0:1.4.5-9.el6_2.2 will be installed > --> Processing Dependency: libgpg-error.so.0 for package: > libgcrypt-1.4.5-9.el6_2.2.i686 > ---> Package libselinux.i686 0:2.0.94-5.3.el6_4.1 will be installed > ---> Package libstdc++.i686 0:4.4.7-3.el6 will be installed > ---> Package libtasn1.i686 0:2.3-3.el6_2.1 will be installed > --> Running transaction check > ---> Package libgpg-error.i686 0:1.7-4.el6 will be installed > --> Finished Dependency Resolution > Error: Multilib version problems found. This often means that the root > cause is something else and multilib version checking is just > pointing out that there is a problem. Eg.: > > 1. You have an upgrade for neon which is missing some > dependency that another package requires. Yum is trying to > solve this by installing an older version of neon of the > different architecture. If you exclude the bad architecture > yum will tell you what the root cause is (which package > requires what). You can try redoing the upgrade with > --exclude neon.otherarch ... this should give you an error > message showing the root cause of the problem. > > 2. You have multiple architectures of neon installed, but > yum can only see an upgrade for one of those arcitectures. > If you don't want/need both architectures anymore then you > can remove the one with the missing update and everything > will work. > > 3. You have duplicate versions of neon installed already. > You can use "yum check" to get yum show these errors. > > ...you can also use --setopt=protected_multilib=false to remove > this checking, however this is almost never the correct thing to > do as something else is very likely to go wrong (often causing > much more problems). > > Protected multilib versions: neon-0.29.3-2.el6.i686 != > neon-0.29.3-3.el6_4.x86_64 > You could try using --skip-broken to work around the problem > > You could try running: rpm -Va --nofiles --nodigest > ---------------- > > I haven't opened a redhat ticket yet, but I probably will Real Soon Now. > > -- Jim Leinweber > State Laboratory of Hygiene, University of Wisconsin - Madison > phone +1 608 221 6281 > PGP fp: D573 AF7D F484 EE2A F0B6 B7DB A870 7518 F87D A0D1 > From nalin at redhat.com Thu Sep 5 15:43:15 2013 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 5 Sep 2013 11:43:15 -0400 Subject: [rhelv6-list] is anyone else having multi-arch issues with neon? In-Reply-To: <1298E81544388440ADBE9B0072AABD8112385780@slhmail2003.ad.slh.wisc.edu> References: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> <20130905132538.5e9d25af@faldor.intranet> <1298E81544388440ADBE9B0072AABD8112385780@slhmail2003.ad.slh.wisc.edu> Message-ID: <20130905154315.GB15310@redhat.com> On Thu, Sep 05, 2013 at 10:11:40AM -0500, Leinweber, James wrote: > Running "sudo yum update -y" for the neon package fails thusly: > ----------------- > Loaded plugins: downloadonly, refresh-packagekit, rhnplugin > This system is receiving updates from RHN Classic or RHN Satellite. > rhel-x86_64-server-6 > | 1.8 kB 00:00 > Setting up Update Process > Resolving Dependencies > --> Running transaction check > ---> Package microcode_ctl.x86_64 1:1.17-14.el6 will be updated > ---> Package microcode_ctl.x86_64 1:1.17-15.el6_4 will be an update > ---> Package neon.x86_64 0:0.29.3-2.el6 will be updated > --> Processing Dependency: neon = 0.29.3-2.el6 for package: > neon-devel-0.29.3-2.el6.x86_64 > ---> Package neon.x86_64 0:0.29.3-3.el6_4 will be an update > --> Running transaction check > ---> Package neon.i686 0:0.29.3-2.el6 will be installed [snip] > Error: Multilib version problems found. This often means that the root > cause is something else and multilib version checking is just > pointing out that there is a problem. Eg.: > > 1. You have an upgrade for neon which is missing some > dependency that another package requires. Yum is trying to > solve this by installing an older version of neon of the > different architecture. If you exclude the bad architecture > yum will tell you what the root cause is (which package > requires what). You can try redoing the upgrade with > --exclude neon.otherarch ... this should give you an error > message showing the root cause of the problem. Does this system have neon-devel installed? The neon-devel package, like most -devel packages, requires a matching version/release of the neon package, and that could be the missing dependency for case #1. Based on the logged output, the system doesn't appear to be subscribed to the "RHEL Server Optional" channel, which is where neon-devel, and corresponding updates for it, would be found. HTH, Nalin From mschwendt at gmail.com Thu Sep 5 17:21:33 2013 From: mschwendt at gmail.com (Michael Schwendt) Date: Thu, 5 Sep 2013 19:21:33 +0200 Subject: [rhelv6-list] is anyone else having multi-arch issues with neon? In-Reply-To: <20130905154315.GB15310@redhat.com> References: <1298E81544388440ADBE9B0072AABD8112385663@slhmail2003.ad.slh.wisc.edu> <20130905132538.5e9d25af@faldor.intranet> <1298E81544388440ADBE9B0072AABD8112385780@slhmail2003.ad.slh.wisc.edu> <20130905154315.GB15310@redhat.com> Message-ID: <20130905192133.0f21a66b@faldor.intranet> On Thu, 5 Sep 2013 11:43:15 -0400, Nalin Dahyabhai wrote: > On Thu, Sep 05, 2013 at 10:11:40AM -0500, Leinweber, James wrote: > > Running "sudo yum update -y" for the neon package fails thusly: > > ----------------- > > Loaded plugins: downloadonly, refresh-packagekit, rhnplugin > > This system is receiving updates from RHN Classic or RHN Satellite. > > rhel-x86_64-server-6 > > | 1.8 kB 00:00 > > Setting up Update Process > > Resolving Dependencies > > --> Running transaction check > > ---> Package microcode_ctl.x86_64 1:1.17-14.el6 will be updated > > ---> Package microcode_ctl.x86_64 1:1.17-15.el6_4 will be an update > > ---> Package neon.x86_64 0:0.29.3-2.el6 will be updated > > --> Processing Dependency: neon = 0.29.3-2.el6 for package: > > neon-devel-0.29.3-2.el6.x86_64 > > ---> Package neon.x86_64 0:0.29.3-3.el6_4 will be an update > > --> Running transaction check > > ---> Package neon.i686 0:0.29.3-2.el6 will be installed > [snip] > > Error: Multilib version problems found. This often means that the root > > cause is something else and multilib version checking is just > > pointing out that there is a problem. Eg.: > > > > 1. You have an upgrade for neon which is missing some > > dependency that another package requires. Yum is trying to > > solve this by installing an older version of neon of the > > different architecture. If you exclude the bad architecture > > yum will tell you what the root cause is (which package > > requires what). You can try redoing the upgrade with > > --exclude neon.otherarch ... this should give you an error > > message showing the root cause of the problem. > > Does this system have neon-devel installed? That's why I asked for the full output. ;-) The answer is in there: --> Processing Dependency: neon = 0.29.3-2.el6 for package: neon-devel-0.29.3-2.el6.x86_64 Yes, that's the typical old-school non-arch-specific Requires: %name = %version-%release base package dependency, which we make arch-specific at Fedora for some time to avoid these dependency issues. So, your theory has hit the nail on its head. Erasing neon-devel or making available its update will fix the dependency issue. From fpicabia at gmail.com Thu Sep 12 12:43:42 2013 From: fpicabia at gmail.com (francis picabia) Date: Thu, 12 Sep 2013 09:43:42 -0300 Subject: [rhelv6-list] Convert from software raid to Perc H700 controller Message-ID: We have a Dell system which was initially set up on the cheap using the on board SATA controller (S100). It runs software RAID with a mirror of two sata disks. We found it was sufficient for operations, but a full backup service takes about 16 hours to backup 200 GB so this isn't so good. A Perc H700 controller was ordered, and it seems there is no way to use it as a straight controller. It can only use the hardware raid configuration. I'd be happy to learn there is a way to make it work as a straight through controller, so please correct me if this is wrong. Assuming the H700 will not support straight physical disk access and software raid, how would we migrate it to the hardware raid? I know it is easy to convert one disk in the md raid to ext3 simply by setting it as sda1 etc in /etc/fstab. I don't know if it is possible to assemble a degraded mirror in the H700 using just one disk. Assuming the H700 could create a degraded array, then from a live/rescue CD, while running from two controllers (onboard for one, H700 for other) we could mount these things and cp -a the partitions. Is there a better way? -------------- next part -------------- An HTML attachment was scrubbed... URL: From eng-partner-management at redhat.com Thu Sep 12 15:21:43 2013 From: eng-partner-management at redhat.com (Engineering Partner Management) Date: Thu, 12 Sep 2013 11:21:43 -0400 Subject: [rhelv6-list] New Red Hat Software Collections combines the stability of Red Hat Enterprise Linux with the latest stable runtime software Message-ID: <5231DC07.5050208@redhat.com> Red Hat is pleased to announce the general availability of Red Hat Software Collections 1.0. Available via select Red Hat Enterprise Linux subscriptions, Red Hat Software Collections delivers the newest, most stable versions of open source runtime components to subscribers on a lifecycle that is separate from Red Hat Enterprise Linux. By providing a more frequent release cadence of these developer oriented technologies, Red Hat responds to the need for access to rapid language and database innovation while continuing to deliver the stability of the Red Hat Enterprise Linux platform. Red Hat Enterprise Linux currently ships stable tools and runtime technologies with its 10-year lifecycle and will continue to do so. Responding to evolving developer needs, Red Hat Software Collections provides access to newer, updated, and reliable versions of popular dynamic languages and open source databases with a three-year lifecycle. This enables organizations to accelerate software development and deployment on a modern platform across physical, virtual, and cloud environments without the potential risks of unsupported community projects. Red Hat Software Collections 1.0 includes access to the latest stable versions of: Programming languages for modern web application development including: Ruby 1.9.3 with Rails 3.2.8, Python 2.7, Python 3.3, PHP 5.4, Perl 5.16.3, and a Technology Preview of node.js 0.10 Runtime databases: MySQL 5.5, MariaDB 5.5, and PostgreSQL 9.2 Red Hat Software Collections is available for use with Red Hat Enterprise Linux 6 to customers and partners with the following active Red Hat Enterprise Linux subscriptions: Red Hat Enterprise Linux Server, Premium and Standard Red Hat Enterprise Linux Workstation, Premium and Standard Red Hat Enterprise Linux Academic Server Red Hat Enterprise Linux Academic Workstation Red Hat Enterprise Linux Academic Site Red Hat Enterprise Linux Developer Suite Red Hat Enterprise Linux Developer Support, all support levels Red Hat Enterprise Linux Developer Workstation, all support levels Red Hat Enterprise Linux Not-for-resale (NFR) subscriptions for qualifying Partners Red Hat Enterprise Enterprise Linux OpenStack Platform (all support levels) Red Hat Cloud Infrastructure (all support levels) View a complete list of qualifying Red Hat subscriptions as well as instructions for how to access Red Hat Software Collections at https://access.redhat.com/site/solutions/472793. ADDITIONAL RESOURCES Please visit the below resources for more information about Red Hat Software Collections and Red Hat Enterprise Linux Developer Program. Learn more about Red Hat Software Collections: http://developerblog.redhat.com/tag/software-collections/ Gain access to Red Hat Software Collections 1.0 under an existing Red Hat Enterprise Linux subscription: http://www.redhat.com/GetRedHatSoftwareCollections.html View a complete list of qualifying Red Hat subscriptions: https://access.redhat.com/site/solutions/472793. Access documentation for Red Hat Software Collections (requires login): Latest Red Hat Software Collections release notes: https://access.redhat.com/site/documentation/Red_Hat_Software_Collections/ Red Hat Developer Toolset documentation: https://access.redhat.com/site/documentation/Red_Hat_Developer_Toolset/ Red Hat Enterprise Linux Developer Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/index.html Red Hat Enterprise Linux documentation: https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Linux/ Learn more about Red Hat Enterprise Linux Developer Program on: Twitter - https://twitter.com/#!/RHELdevelop Facebook - https://www.facebook.com/RHELdevelop YouTube - http://bit.ly/RHELDevOnYouTube LinkedIn - http://www.linkedin.com/in/rheldevelop Sincerely, The Red Hat Enterprise Linux Team From eng-partner-management at redhat.com Thu Sep 12 15:32:10 2013 From: eng-partner-management at redhat.com (Engineering Partner Management) Date: Thu, 12 Sep 2013 11:32:10 -0400 Subject: [rhelv6-list] Red Hat Releases Red Hat Developer Toolset 2.0 with GCC 4.8 Update and Eclipse 4.3.0 Message-ID: <5231DE7A.9050603@redhat.com> Red Hat is pleased to announce the general availability of Red Hat Developer Toolset 2.0. Available to all Red Hat customers with an active Red Hat Enterprise Linux Developer subscription, Red Hat Developer Toolset provides access to the latest stable versions of open source development tools on a separate, accelerated life cycle. Red Hat Developer Toolset enables C, C++, and Fortran developers to compile once and then deploy across multiple versions of Red Hat Enterprise Linux. There is no need for application re-writes as compatibility is preserved, even when deploying to newer versions of Red Hat Enterprise Linux. Additionally, the capabilities offered with Red Hat Developer Toolset help developers more quickly diagnose and debug applications, and even analyze application performance to isolate memory and management issues. Delivering a parallel set of the latest stable tools to those provided with Red Hat Enterprise Linux, Red Hat Developer Toolset 2.0 introduces new tools to the content set available with Red Hat Developer Toolset 1.0. These additions to version 2.0 allow developers to use some of the latest innovative tools without dedicating cycles to installing and troubleshooting unsupported community versions. In addition to the update to GNU Compiler Collection (GCC) 4.8, Red Hat Developer Toolset 2.0 adds Eclipse 4.3.0, Dyninst 8.0, Strace 4.7, and MEMSTOMP. Red Hat Developer Toolset 2.0 also delivers updates to elfutils 0.155, SystemTap 2.1, Valgrind 3.8.1, OProfile 0.9.8 and DWZ 0.10. Red Hat Developer Toolset is available via Red Hat Network for users who develop applications for Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6. Please see the Red Hat Developer Toolset release notes for support of specific Red Hat Enterprise Linux releases. Red Hat Developer Toolset is available through the following subscriptions: Red Hat Enterprise Linux Developer Suite Red Hat Enterprise Linux Developer Support Red Hat Enterprise Linux Developer Workstation Red Hat Enterprise Linux Not-for-resale (NFR) subscriptions for qualifying Partners Red Hat Enterprise Linux North American Academic Site Subscriptions Learn more about Red Hat Developer Toolset at: http://developerblog.redhat.com/tag/developer-toolset/. ADDITIONAL RESOURCES Please visit the below resources for more information about Red Hat Developer Toolset. Learn more about Red Hat Developer Toolset and the Red Hat Enterprise Linux Developer Program: https://access.redhat.com/products/Red_Hat_Enterprise_Linux/Developer/ Access documentation for Red Hat Developer Toolset (requires login): Latest Red Hat Developer Toolset release notes: https://access.redhat.com/site/documentation/en-US/Red_Hat_Developer_Toolset/2/html/2.0_Release_Notes/index.html Red Hat Developer Toolset documentation: https://access.redhat.com/site/documentation/Red_Hat_Developer_Toolset/ Red Hat Enterprise Linux Developer Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/index.html Red Hat Enterprise Linux documentation: https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Linux/ Sincerely, The Red Hat Enterprise Linux Team From vincent at cojot.name Mon Sep 16 20:38:09 2013 From: vincent at cojot.name (vincent at cojot.name) Date: Mon, 16 Sep 2013 16:38:09 -0400 (EDT) Subject: [rhelv6-list] Megaraid on RHEL6: Replacing the disks in a RAID-5, one after the other..? Message-ID: Hi everyone, I have a Dell T410 with hot-swap bays that hold the following config: # megaclisas-status -- Controller information -- -- ID | Model c0 | LSI MegaRAID SAS 9271-8i -- Arrays informations -- -- ID | Type | Size | Status | InProgress c0u0 | RAID-1 | 1817G | Optimal | None c0u1 | RAID-5 | 8184G | Optimal | None -- Disks informations -- ID | Model | Status | Speed | Temperature c0u0p0 | WD-WMC300422505WDC WD20EFRX-68AX9N0 80.00A80 | Online, Spun Up | 6.0Gb/s | 31C | ID: '[252:4]' c0u0p1 | WD-WMC300421817WDC WD20EFRX-68AX9N0 80.00A80 | Online, Spun Up | 6.0Gb/s | 32C | ID: '[252:5]' c0u1p0 | WD-WMC1T0534822WDC WD30EFRX-68AX9N0 80.00A80 | Online, Spun Up | 6.0Gb/s | 30C | ID: '[252:0]' c0u1p1 | WD-WMC1T0613679WDC WD30EFRX-68AX9N0 80.00A80 | Online, Spun Up | 6.0Gb/s | 30C | ID: '[252:1]' c0u1p2 | WD-WMC1T0600303WDC WD30EFRX-68AX9N0 80.00A80 | Online, Spun Up | 6.0Gb/s | 30C | ID: '[252:7]' c0u1p3 | WD-WMC1T0534827WDC WD30EFRX-68AX9N0 80.00A80 | Online, Spun Up | 6.0Gb/s | 30C | ID: '[252:6]' The 4x3Tb RAID-5 is running out of space and I'd like to replace all of those 3Tb disks with 4Tb disks (Yes, I know it's not economical). I considered rebuilding the array from scratch and restoring the data but the restore window would be too lengthy. I don't have any hot spares, btw, nor empty slots.. I'm currently wondering if I could just swap the disks one after the other (waiting for the resync to finish in-between swaps) and then extend the Logical Drive. Is this doable with such a config? Has someone done this before? What would the procedure look like? I was thinking about something like this (Array #0, LD #1). a) for each of the old drives, do this: 1) Set the drive offline # MegaCli -PDOffline -PhysDrv [E:S] -a0 2) Mark the drive as missing # MegaCli -PDMarkMissing -PhysDrv [E:S] -a0 3) Prepare drive for removal # MegaCli -PDPrpRmv -PhysDrv [E:S] -a0 4) Change/replace the drive 5) re-add the new drive to my RAID virtual drive and start the rebuilding # MegaCli -PdReplaceMissing -physdrv[E0:S0] -arrayA, -rowB -a0 # MegaCli -PDRbld -Start -PhysDrv [E:S] -a0 b) When all the drives have been replaced, expand the LD: 1) Check if expansion is possible: # MegaCli -getLdExpansionInfo -L1 -a0 2) Expand the array. # MegaCli -LdExpansion -p100 -L1 -a0 What do you people think of that? Would that work? Anyone been there before? I found some hints that some people did (http://trac.camsentry.com/wordpress/2013-03/expanding-resizing-an-array-with-larger-drives) but I thought I'd ask here.. :) c) Do the usual parted, pvresize/vxresize stuff... System is running latest RHEL6.x, btw... Thanks for reading, Vincent From michael.schumacher at pamas.de Tue Sep 17 06:12:29 2013 From: michael.schumacher at pamas.de (Michael Schumacher) Date: Tue, 17 Sep 2013 08:12:29 +0200 Subject: [rhelv6-list] Megaraid on RHEL6: Replacing the disks in a RAID-5, one after the other..? In-Reply-To: References: Message-ID: <1008118382.20130917081229@pamas.de> Hi Vincent, Monday, September 16, 2013, 10:38:09 PM, you wrote: > I have a Dell T410 with hot-swap bays that hold the following config: [...] > I'm currently wondering if I could just swap the disks one after the other > (waiting for the resync to finish in-between swaps) and then extend the Logical > Drive. That way you would have to go through three rebuild processes with a large RAID5 array. I think that is too risky. I did that recently in a different way. These were the steps: -- connect first new drive temporarily to the computer (via USB or SATA) -- copy about 3TB data from RAID to the first drive -- connect second new drive and continue filling it with data from the array. -- now you have two copies of your data. -- tear apart the old RAID5 and copy all data from the new drives to the individual old drives. -- only one copy of data existing at this time!! -- take new drives and build RAID5 array -- copy data from old drives to new drives. Advantage of my method. If a drive fails, about a third of my data is gone, but not all of it. You could use the remaining space on the drives for additional copies of your data. You should consider using RAID6 :-) best regards --- Michael Schumacher PAMAS Partikelmess- und Analysesysteme GmbH Dieselstr.10, D-71277 Rutesheim Tel +49-7152-99630 Fax +49-7152-996333 Gesch?ftsf?hrer: Gerhard Schreck Handelsregister B Stuttgart HRB 252024 From brilong at cisco.com Tue Sep 17 12:02:45 2013 From: brilong at cisco.com (Brian Long (brilong)) Date: Tue, 17 Sep 2013 12:02:45 +0000 Subject: [rhelv6-list] Megaraid on RHEL6: Replacing the disks in a RAID-5, one after the other..? In-Reply-To: References: Message-ID: On Sep 16, 2013, at 4:38 PM, vincent at cojot.name wrote: > > Hi everyone, > > I have a Dell T410 with hot-swap bays that hold the following config: > > > > The 4x3Tb RAID-5 is running out of space and I'd like to replace all of those 3Tb disks with 4Tb disks (Yes, I know it's not economical). I considered rebuilding the array from scratch and restoring the data but the restore window would be too lengthy. I don't have any hot spares, btw, nor empty slots.. > > I'm currently wondering if I could just swap the disks one after the other (waiting for the resync to finish in-between swaps) and then extend the Logical Drive. > > Is this doable with such a config? Has someone done this before? What would the procedure look like? I was thinking about something like this (Array #0, LD #1). I have done this multiple times on LSI-based controllers (9261). As Michael alluded to, RAID-5 is in it's most vulnerable state when a drive is missing. It is not uncommon for a second disk to die or drop from the RAID-5 array right when you're trying the process you outlined. I've not had it happen when I performed this migration on LSI controllers, but I _have_ had this happen when using Linux kernel software RAID and on an older 3Ware hardware RAID controller. If you dare proceed, make sure you have a current backup since it will be your last resort and then you're stuck with the long restore window. I like Michael's suggestion of setting up an alternate array or copy of your data. The other more expensive option would be to acquire a second server with the RAID setup you require, migrate all your apps and data (rsync is your friend). Then recycle the original server for another task. /Brian/ From gianluca.cecchi at gmail.com Fri Sep 27 15:10:34 2013 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 27 Sep 2013 17:10:34 +0200 Subject: [rhelv6-list] Best options to mount ext4 over iSCSI? Message-ID: Hello, I have a RH EL 5.9 server that is configured as iSCSI target software (scsi-target-utils provided by OS... a bit outdated vs what in RH EL 6) It exports an LVM (based on a RAID 5 hw on a Dell system) of about 5Tb to a RH EL 6.4 system that has formatted and mounts an ext4 fs. What are the best option to mount this kind of filesystem at iSCSI initiator side? So the question regards barriers, acl and other options. Basically the fs is used to save Oracle backups through rman on disk. At this moment /proc/mounts gives: /dev/mapper/VG_I_BCKDB01-LV_I_BCKDB01 /datasave/database ext4 rw,relatime,user_xattr,acl,barrier=1,data=ordered 0 0 Yesterday I experienced a reboot and these messages during latest days: Sep 22 16:20:17 myserver kernel: EXT4-fs (dm-6): error count: 5 Sep 22 16:20:17 myserver kernel: EXT4-fs (dm-6): initial error at 1378602406: ext4_journal_start_sb:296 Sep 22 16:20:17 myserver kernel: EXT4-fs (dm-6): last error at 1378640505: ext4_put_super:772 Sep 23 16:22:05 myserver kernel: EXT4-fs (dm-6): error count: 5 Sep 23 16:22:05 myserver kernel: EXT4-fs (dm-6): initial error at 1378602406: ext4_journal_start_sb:296 Sep 23 16:22:05 myserver kernel: EXT4-fs (dm-6): last error at 1378640505: ext4_put_super:772 Sep 24 16:23:52 myserver kernel: EXT4-fs (dm-6): error count: 5 Sep 24 16:23:52 myserver kernel: EXT4-fs (dm-6): initial error at 1378602406: ext4_journal_start_sb:296 Sep 24 16:23:52 myserver kernel: EXT4-fs (dm-6): last error at 1378640505: ext4_put_super:772 Sep 25 16:25:40 myserver kernel: EXT4-fs (dm-6): error count: 5 Sep 25 16:25:40 myserver kernel: EXT4-fs (dm-6): initial error at 1378602406: ext4_journal_start_sb:296 Sep 25 16:25:40 myserver kernel: EXT4-fs (dm-6): last error at 1378640505: ext4_put_super:772 Sep 26 16:24:44 myserver init: tty (/dev/tty1) main process (3716) killed by TERM signal Sep 26 16:24:44 myserver init: tty (/dev/tty2) main process (3718) killed by TERM signal Sep 26 16:24:44 myserver init: tty (/dev/tty3) main process (3720) killed by TERM signal Sep 26 16:24:44 myserver init: tty (/dev/tty4) main process (3722) killed by TERM signal Sep 26 16:24:44 myserver init: tty (/dev/tty5) main process (3724) killed by TERM signal Sep 26 16:24:44 myserver init: tty (/dev/tty6) main process (3726) killed by TERM signal And after spontaneous reboot EXT4-fs (dm-6): mounted filesystem with ordered data mode. Opts: (null) EXT4-fs (dm-6): error count: 5 EXT4-fs (dm-6): initial error at 1378602406: ext4_journal_start_sb:296 EXT4-fs (dm-6): last error at 1378640505: ext4_put_super:772 EXT4-fs (dm-6): error count: 5 EXT4-fs (dm-6): initial error at 1378602406: ext4_journal_start_sb:296 EXT4-fs (dm-6): last error at 1378640505: ext4_put_super:772 First thing I'm going to run an fsck against the filesystem, but also info on best options to adopt in this use case would be appreciated. Thanks in advance, Gianluca