From mirko.vukovic at gmail.com Tue Oct 9 13:25:21 2012 From: mirko.vukovic at gmail.com (Mirko Vukovic) Date: Tue, 9 Oct 2012 09:25:21 -0400 Subject: [rhelv6-list] why do errata and package updates fail? Message-ID: Hello, I am managing only one system (for scientific work). It is subscribed to the workstation channel (including the workstation supplementary and optional). In my daily email updates, I see that (about 50%) of the errata and package updates fail. Is that a sign of some problem? For example, I went to the red hat site, and scheduled to update all the errata. But two thirds of them failed: Errata Update: RHBA-2012:1195-1 - openssl bug fix update 10/8/12 1:45:57 PM EDT 0 1 0 1 Errata Update: RHSA-2012:1261-1 - Moderate: dbus security update 10/8/12 1:45:57 PM EDT 0 1 0 1 Errata Update: RHBA-2012:1285-1 - cups bug fix update 10/8/12 1:45:57 PM EDT 0 1 0 1 Errata Update: RHSA-2012:1288-1 - Moderate: libxml2 security update 10/8/12 1:45:57 PM EDT 0 1 0 1 Errata Update: RHBA-2012:1294-1 - krb5 bug fix update 10/8/12 1:45:57 PM EDT 0 1 0 1 Errata Update: RHBA-2012:1337-1 - systemtap bug fix update I did not reboot my system in the past several weeks. Could that be the cause? Maybe these errata can be applied only after the previous one take effect? TIA Mirko From thomas at redhat.com Tue Oct 9 13:58:07 2012 From: thomas at redhat.com (thomas at redhat.com) Date: Tue, 9 Oct 2012 09:58:07 -0400 (EDT) Subject: [rhelv6-list] why do errata and package updates fail? Message-ID: An HTML attachment was scrubbed... URL: From mirko.vukovic at gmail.com Tue Oct 9 16:10:44 2012 From: mirko.vukovic at gmail.com (Mirko Vukovic) Date: Tue, 9 Oct 2012 12:10:44 -0400 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: References: Message-ID: yum update installed 26 packages. The system shows as up-to-date on RHN. It is still unresolved as to why some of the updates were not getting installed. I noticed during yum update that kmod-nvidia was taking forever (more than a minute, but then, my system is fully loaded right now). Could that have triggered a time-out? On a related note, I have 16 AMD cores, and I am running simulations that occupy all of them (with nice set to 10). Can that affect the update process? (mind you, I'm not a system operator, but a scientist, so these is wild speculation) Thanks, Mirko On Tue, Oct 9, 2012 at 9:58 AM, thomas at redhat.com wrote: > Rebooting should not affect it. Was there any error? Look at the system's > event history on RHN to see. > > Might also clean up any old RHN info cached on the machine. yum clean > metadata or even yum clean all. > > You can also run yum update on the console or an ssh session to view or > capture any errors. > > -------- Original Message -------- > From: Mirko Vukovic > Sent: Tue, Oct 9, 2012 08:28 AM > To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list > CC: > Subject: [rhelv6-list] why do errata and package updates fail? > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list From thomas at redhat.com Tue Oct 9 16:18:09 2012 From: thomas at redhat.com (thomas at redhat.com) Date: Tue, 09 Oct 2012 11:18:09 -0500 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: References: Message-ID: <50744E41.60100@redhat.com> On 10/09/2012 11:10 AM, Mirko Vukovic wrote: > yum update installed 26 packages. The system shows as up-to-date on RHN. Without seeing the logs from the previous commands, it's almost impossible to tell what happened. > It is still unresolved as to why some of the updates were not getting > installed. I noticed during yum update that kmod-nvidia was taking > forever (more than a minute, but then, my system is fully loaded right > now). Could that have triggered a time-out? What repositories do you have enabled? What is the output of the following command? yum -v repolist > On a related note, I have 16 AMD cores, and I am running simulations > that occupy all of them (with nice set to 10). Can that affect the > update process? It should not. > (mind you, I'm not a system operator, but a scientist, so these is > wild speculation) I almost guarantee that the answers are in the system event log. Go to RHN, click on the system, choose "Events" in the menu just below the hostname, then choose "History" to see what happened. > Thanks, > > Mirko > > On Tue, Oct 9, 2012 at 9:58 AM, thomas at redhat.com wrote: >> Rebooting should not affect it. Was there any error? Look at the system's >> event history on RHN to see. >> >> Might also clean up any old RHN info cached on the machine. yum clean >> metadata or even yum clean all. >> >> You can also run yum update on the console or an ssh session to view or >> capture any errors. >> >> -------- Original Message -------- >> From: Mirko Vukovic >> Sent: Tue, Oct 9, 2012 08:28 AM >> To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list >> CC: >> Subject: [rhelv6-list] why do errata and package updates fail? >> >> >> _______________________________________________ >> rhelv6-list mailing list >> rhelv6-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhelv6-list > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US 512-241-0774 office / 512-585-5631 cell http://people.redhat.com/tcameron/ IRC: choirboy / AIM: rhelguy / Yahoo: rhce_guy Red Hat named to Forbes 2012 World's Most Innovative Companies list: http://www.redhat.com/innovation From amyagi at gmail.com Tue Oct 9 16:27:07 2012 From: amyagi at gmail.com (Akemi Yagi) Date: Tue, 9 Oct 2012 09:27:07 -0700 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: References: Message-ID: On Tue, Oct 9, 2012 at 9:10 AM, Mirko Vukovic wrote: > It is still unresolved as to why some of the updates were not getting > installed. I noticed during yum update that kmod-nvidia was taking > forever (more than a minute, but then, my system is fully loaded right > now). Could that have triggered a time-out? Installing kmod-nvidia can take a long time because it looks through the installed kernels for kABI compatibility. Unfortunately the "this takes a long time" note would not appear until it's done. At any rate, this should not present a problem. Akemi From mirko.vukovic at gmail.com Tue Oct 9 17:33:19 2012 From: mirko.vukovic at gmail.com (Mirko Vukovic) Date: Tue, 9 Oct 2012 13:33:19 -0400 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: <50744E41.60100@redhat.com> References: <50744E41.60100@redhat.com> Message-ID: On Tue, Oct 9, 2012 at 12:18 PM, thomas at redhat.com wrote: > On 10/09/2012 11:10 AM, Mirko Vukovic wrote: >> >> yum update installed 26 packages. The system shows as up-to-date on RHN. > > > Without seeing the logs from the previous commands, it's almost impossible > to tell what happened. > ... > What repositories do you have enabled? What is the output of the following > command? > > yum -v repolist Here is output of `yum -v repolist' Loading "rhnplugin" plugin Loading "product-id" plugin Loading "refresh-packagekit" plugin Loading "security" plugin Loading "subscription-manager" plugin Updating certificate-based repositories. Unable to read consumer identity Config time: 0.109 Looking for repo options for [main] Looking for repo options for [rhel-x86_64-workstation-6] Repo 'rhel-x86_64-workstation-6' setting option 'enabled' = '1' Repo 'rhel-x86_64-workstation-6' setting option 'gpgcheck' = '1' Looking for repo options for [rhel-x86_64-workstation-supplementary-6] Repo 'rhel-x86_64-workstation-supplementary-6' setting option 'enabled' = '1' Repo 'rhel-x86_64-workstation-supplementary-6' setting option 'gpgcheck' = '1' Looking for repo options for [rhel-x86_64-workstation-optional-6] Repo 'rhel-x86_64-workstation-optional-6' setting option 'enabled' = '1' Repo 'rhel-x86_64-workstation-optional-6' setting option 'gpgcheck' = '1' Yum Version: 3.2.29 Setting up Package Sacks pkgsack time: 0.055 Repo-id : elrepo Repo-name : ELRepo.org Community Enterprise Linux Repository - el6 Repo-updated : Mon Oct 8 01:31:18 2012 Repo-pkgs : 219 Repo-size : 931 M Repo-baseurl : http://elrepo.org/linux/elrepo/el6/x86_64/ Repo-mirrors : http://elrepo.org/mirrors-elrepo.el6 Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:29 2012) Repo-id : epel Repo-name : Extra Packages for Enterprise Linux 6 - x86_64 Repo-revision: 1349708267 Repo-tags : binary-x86_64 Repo-updated : Mon Oct 8 10:59:47 2012 Repo-pkgs : 7,887 Repo-size : 6.9 G Repo-metalink: https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 Updated : Mon Oct 8 10:59:47 2012 Repo-baseurl : http://fedora-epel.mirror.lstn.net/6/x86_64/ (38 more) Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:31 2012) Repo-id : rhel-x86_64-workstation-6 Repo-name : Red Hat Enterprise Linux Workstation (v. 6 for x86_64) Repo-updated : Mon Oct 8 08:56:32 2012 Repo-pkgs : 9,349 Repo-size : 15 G Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-6 Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:32 2012) Repo-id : rhel-x86_64-workstation-optional-6 Repo-name : RHEL Workstation Optional (v. 6 for x86_64) Repo-updated : Mon Oct 8 08:56:32 2012 Repo-pkgs : 4,565 Repo-size : 3.3 G Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-optional-6 Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:33 2012) Repo-id : rhel-x86_64-workstation-supplementary-6 Repo-name : RHEL Workstation Supplementary (v. 6 for x86_64) Repo-updated : Tue Oct 9 03:53:35 2012 Repo-pkgs : 276 Repo-size : 3.6 G Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-supplementary-6 Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:34 2012) > > I almost guarantee that the answers are in the system event log. Go to RHN, > click on the system, choose "Events" in the menu just below the hostname, > then choose "History" to see what happened. > Thanks for showing me how to get to history. This is what I found: - Some were failures because of existing lock on var/run/yum.pid - Other were package dependency failures: u'Protected multilib versions: ...x86_64 != ...i686 (code 18) I checked (ps -A) and there is currently no yum running. Mirko From thomas at redhat.com Tue Oct 9 18:31:39 2012 From: thomas at redhat.com (thomas at redhat.com) Date: Tue, 09 Oct 2012 13:31:39 -0500 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: References: <50744E41.60100@redhat.com> Message-ID: <50746D8B.1030703@redhat.com> On 10/09/2012 12:33 PM, Mirko Vukovic wrote: > On Tue, Oct 9, 2012 at 12:18 PM, thomas at redhat.com wrote: >> On 10/09/2012 11:10 AM, Mirko Vukovic wrote: >>> >>> yum update installed 26 packages. The system shows as up-to-date on RHN. >> >> >> Without seeing the logs from the previous commands, it's almost impossible >> to tell what happened. >> > ... >> What repositories do you have enabled? What is the output of the following >> command? >> >> yum -v repolist > > Here is output of `yum -v repolist' > > Loading "rhnplugin" plugin > Loading "product-id" plugin > Loading "refresh-packagekit" plugin > Loading "security" plugin > Loading "subscription-manager" plugin > Updating certificate-based repositories. > Unable to read consumer identity > Config time: 0.109 > Looking for repo options for [main] > Looking for repo options for [rhel-x86_64-workstation-6] > Repo 'rhel-x86_64-workstation-6' setting option 'enabled' = '1' > Repo 'rhel-x86_64-workstation-6' setting option 'gpgcheck' = '1' > Looking for repo options for [rhel-x86_64-workstation-supplementary-6] > Repo 'rhel-x86_64-workstation-supplementary-6' setting option 'enabled' = '1' > Repo 'rhel-x86_64-workstation-supplementary-6' setting option 'gpgcheck' = '1' > Looking for repo options for [rhel-x86_64-workstation-optional-6] > Repo 'rhel-x86_64-workstation-optional-6' setting option 'enabled' = '1' > Repo 'rhel-x86_64-workstation-optional-6' setting option 'gpgcheck' = '1' > Yum Version: 3.2.29 > Setting up Package Sacks > pkgsack time: 0.055 > Repo-id : elrepo > Repo-name : ELRepo.org Community Enterprise Linux Repository - el6 > Repo-updated : Mon Oct 8 01:31:18 2012 > Repo-pkgs : 219 > Repo-size : 931 M > Repo-baseurl : http://elrepo.org/linux/elrepo/el6/x86_64/ > Repo-mirrors : http://elrepo.org/mirrors-elrepo.el6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:29 2012) > > Repo-id : epel > Repo-name : Extra Packages for Enterprise Linux 6 - x86_64 > Repo-revision: 1349708267 > Repo-tags : binary-x86_64 > Repo-updated : Mon Oct 8 10:59:47 2012 > Repo-pkgs : 7,887 > Repo-size : 6.9 G > Repo-metalink: https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 > Updated : Mon Oct 8 10:59:47 2012 > Repo-baseurl : http://fedora-epel.mirror.lstn.net/6/x86_64/ (38 more) > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:31 2012) > > Repo-id : rhel-x86_64-workstation-6 > Repo-name : Red Hat Enterprise Linux Workstation (v. 6 for x86_64) > Repo-updated : Mon Oct 8 08:56:32 2012 > Repo-pkgs : 9,349 > Repo-size : 15 G > Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:32 2012) > > Repo-id : rhel-x86_64-workstation-optional-6 > Repo-name : RHEL Workstation Optional (v. 6 for x86_64) > Repo-updated : Mon Oct 8 08:56:32 2012 > Repo-pkgs : 4,565 > Repo-size : 3.3 G > Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-optional-6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:33 2012) > > Repo-id : rhel-x86_64-workstation-supplementary-6 > Repo-name : RHEL Workstation Supplementary (v. 6 for x86_64) > Repo-updated : Tue Oct 9 03:53:35 2012 > Repo-pkgs : 276 > Repo-size : 3.6 G > Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-supplementary-6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:34 2012) Not a huge deal, but I've seen some really weird issues with third party repositories like ELRepo and even EPEL. Don't get me wrong, I use EPEL and other third party repositories like ATRPMs, but sometimes it's just... wonky. >> I almost guarantee that the answers are in the system event log. Go to RHN, >> click on the system, choose "Events" in the menu just below the hostname, >> then choose "History" to see what happened. >> > > Thanks for showing me how to get to history. This is what I found: > - Some were failures because of existing lock on var/run/yum.pid > - Other were package dependency failures: u'Protected multilib > versions: ...x86_64 != ...i686 (code 18) > > I checked (ps -A) and there is currently no yum running. I've seen both of those before... If you happen to run a yum command while PackageKit or yum-updatesd are running a job, your yum command gets blocked. It stinks, but generally you can just wait a while and run your yum command again. The Protected multilib error tells me you might have two versions (i686 and x86_64) of a package installed. This is not a big deal, but the nature of using RHN to do updates is that it processes each errata and the associated RPMs serially. So if you have one erratum which addresses the 32-bit version of a file and another which addresses the 64-bit version, you might see that. You might get an error when it tries to update the first package because of common dependencies with the second. Without more of the error message, it's hard to tell, but I don't see anything which is seriously alarming in what you've posted. Frustrating, for sure. But not unexpected. Might not be a bad idea to open a ticket with support... they are the best way to get issues like this in front of our developers (this list is NOT - some developers watch it, but there is no service level agreement around mailing lists). -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US 512-241-0774 office / 512-585-5631 cell http://people.redhat.com/tcameron/ IRC: choirboy / AIM: rhelguy / Yahoo: rhce_guy Red Hat named to Forbes 2012 World's Most Innovative Companies list: http://www.redhat.com/innovation From thomas at redhat.com Tue Oct 9 18:55:03 2012 From: thomas at redhat.com (thomas at redhat.com) Date: Tue, 09 Oct 2012 13:55:03 -0500 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: <50746D8B.1030703@redhat.com> References: <50744E41.60100@redhat.com> <50746D8B.1030703@redhat.com> Message-ID: <50747307.4040804@redhat.com> On 10/09/2012 01:31 PM, thomas at redhat.com wrote: > The Protected multilib error tells me you might have two versions (i686 > and x86_64) of a package installed. This is not a big deal, but the > nature of using RHN to do updates is that it processes each errata and > the associated RPMs serially. So if you have one erratum which addresses > the 32-bit version of a file and another which addresses the 64-bit > version, you might see that. You might get an error when it tries to > update the first package because of common dependencies with the second. > Without more of the error message, it's hard to tell, but I don't see > anything which is seriously alarming in what you've posted. Frustrating, > for sure. But not unexpected. My understanding of this ^^^ is probably wrong. I checked and there should not be different errata for different architectures. I am digging as to what actually causes that multilib conflict. It would be really helpful if you could post the whole history. You can dump it in raw format from the same location I pointed you to earlier. I'm terribly sorry for the noise. I'll post when I get a better understanding of what causes this. -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US 512-241-0774 office / 512-585-5631 cell http://people.redhat.com/tcameron/ IRC: choirboy / AIM: rhelguy / Yahoo: rhce_guy Red Hat named to Forbes 2012 World's Most Innovative Companies list: http://www.redhat.com/innovation From mirko.vukovic at gmail.com Tue Oct 9 19:13:39 2012 From: mirko.vukovic at gmail.com (Mirko Vukovic) Date: Tue, 9 Oct 2012 15:13:39 -0400 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: <50747307.4040804@redhat.com> References: <50744E41.60100@redhat.com> <50746D8B.1030703@redhat.com> <50747307.4040804@redhat.com> Message-ID: On Tue, Oct 9, 2012 at 2:55 PM, thomas at redhat.com wrote: > On 10/09/2012 01:31 PM, thomas at redhat.com wrote: >> >> The Protected multilib error tells me you might have two versions (i686 >> and x86_64) of a package installed. This is not a big deal, but the >> nature of using RHN to do updates is that it processes each errata and >> the associated RPMs serially. So if you have one erratum which addresses >> the 32-bit version of a file and another which addresses the 64-bit >> version, you might see that. You might get an error when it tries to >> update the first package because of common dependencies with the second. >> Without more of the error message, it's hard to tell, but I don't see >> anything which is seriously alarming in what you've posted. Frustrating, >> for sure. But not unexpected. > > > My understanding of this ^^^ is probably wrong. I checked and there should > not be different errata for different architectures. I am digging as to what > actually causes that multilib conflict. It would be really helpful if you > could post the whole history. You can dump it in raw format from the same > location I pointed you to earlier. > > I'm terribly sorry for the noise. I'll post when I get a better > understanding of what causes this. > > I'm sorry but I don't see how to download the raw data from the system/events/history page. (I checked on knowledge base, but other than yum and rpm logs, and /var/log, I did not find anything) Mirko From rprice at redhat.com Tue Oct 9 19:50:55 2012 From: rprice at redhat.com (Robin Price II) Date: Tue, 09 Oct 2012 15:50:55 -0400 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: References: <50744E41.60100@redhat.com> Message-ID: <5074801F.6050500@redhat.com> Mirko, This may be useful: RHEL6: yum returns error: "Protected multilib versions" transaction error https://access.redhat.com/knowledge/solutions/57783 HTHs, ~rp On 10/09/2012 01:33 PM, Mirko Vukovic wrote: > On Tue, Oct 9, 2012 at 12:18 PM, thomas at redhat.com wrote: >> On 10/09/2012 11:10 AM, Mirko Vukovic wrote: >>> >>> yum update installed 26 packages. The system shows as up-to-date on RHN. >> >> >> Without seeing the logs from the previous commands, it's almost impossible >> to tell what happened. >> > ... >> What repositories do you have enabled? What is the output of the following >> command? >> >> yum -v repolist > > Here is output of `yum -v repolist' > > Loading "rhnplugin" plugin > Loading "product-id" plugin > Loading "refresh-packagekit" plugin > Loading "security" plugin > Loading "subscription-manager" plugin > Updating certificate-based repositories. > Unable to read consumer identity > Config time: 0.109 > Looking for repo options for [main] > Looking for repo options for [rhel-x86_64-workstation-6] > Repo 'rhel-x86_64-workstation-6' setting option 'enabled' = '1' > Repo 'rhel-x86_64-workstation-6' setting option 'gpgcheck' = '1' > Looking for repo options for [rhel-x86_64-workstation-supplementary-6] > Repo 'rhel-x86_64-workstation-supplementary-6' setting option 'enabled' = '1' > Repo 'rhel-x86_64-workstation-supplementary-6' setting option 'gpgcheck' = '1' > Looking for repo options for [rhel-x86_64-workstation-optional-6] > Repo 'rhel-x86_64-workstation-optional-6' setting option 'enabled' = '1' > Repo 'rhel-x86_64-workstation-optional-6' setting option 'gpgcheck' = '1' > Yum Version: 3.2.29 > Setting up Package Sacks > pkgsack time: 0.055 > Repo-id : elrepo > Repo-name : ELRepo.org Community Enterprise Linux Repository - el6 > Repo-updated : Mon Oct 8 01:31:18 2012 > Repo-pkgs : 219 > Repo-size : 931 M > Repo-baseurl : http://elrepo.org/linux/elrepo/el6/x86_64/ > Repo-mirrors : http://elrepo.org/mirrors-elrepo.el6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:29 2012) > > Repo-id : epel > Repo-name : Extra Packages for Enterprise Linux 6 - x86_64 > Repo-revision: 1349708267 > Repo-tags : binary-x86_64 > Repo-updated : Mon Oct 8 10:59:47 2012 > Repo-pkgs : 7,887 > Repo-size : 6.9 G > Repo-metalink: https://mirrors.fedoraproject.org/metalink?repo=epel-6&arch=x86_64 > Updated : Mon Oct 8 10:59:47 2012 > Repo-baseurl : http://fedora-epel.mirror.lstn.net/6/x86_64/ (38 more) > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:31 2012) > > Repo-id : rhel-x86_64-workstation-6 > Repo-name : Red Hat Enterprise Linux Workstation (v. 6 for x86_64) > Repo-updated : Mon Oct 8 08:56:32 2012 > Repo-pkgs : 9,349 > Repo-size : 15 G > Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:32 2012) > > Repo-id : rhel-x86_64-workstation-optional-6 > Repo-name : RHEL Workstation Optional (v. 6 for x86_64) > Repo-updated : Mon Oct 8 08:56:32 2012 > Repo-pkgs : 4,565 > Repo-size : 3.3 G > Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-optional-6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:33 2012) > > Repo-id : rhel-x86_64-workstation-supplementary-6 > Repo-name : RHEL Workstation Supplementary (v. 6 for x86_64) > Repo-updated : Tue Oct 9 03:53:35 2012 > Repo-pkgs : 276 > Repo-size : 3.6 G > Repo-baseurl : https://xmlrpc.rhn.redhat.com/XMLRPC/GET-REQ/rhel-x86_64-workstation-supplementary-6 > Repo-expire : 21,600 second(s) (last: Tue Oct 9 11:55:34 2012) > > > >> >> I almost guarantee that the answers are in the system event log. Go to RHN, >> click on the system, choose "Events" in the menu just below the hostname, >> then choose "History" to see what happened. >> > > Thanks for showing me how to get to history. This is what I found: > - Some were failures because of existing lock on var/run/yum.pid > - Other were package dependency failures: u'Protected multilib > versions: ...x86_64 != ...i686 (code 18) > > I checked (ps -A) and there is currently no yum running. > > > Mirko > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -- +-----------------------------[ robin at redhat.com ]----+ | Robin Price II - RHCE,RHCDS,RHCVA | | Solutions Architect - Public Sector | | Red Hat, Inc. | | w: +1 (919) 754 4412 | | c: +1 (252) 474 3525 | | @robinpriceii | +---------[ http://people.redhat.com/rprice ]---------+ From amyagi at gmail.com Tue Oct 9 20:04:11 2012 From: amyagi at gmail.com (Akemi Yagi) Date: Tue, 9 Oct 2012 13:04:11 -0700 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: <50746D8B.1030703@redhat.com> References: <50744E41.60100@redhat.com> <50746D8B.1030703@redhat.com> Message-ID: On Tue, Oct 9, 2012 at 11:31 AM, thomas at redhat.com wrote: > Not a huge deal, but I've seen some really weird issues with third party > repositories like ELRepo and even EPEL. Don't get me wrong, I use EPEL and > other third party repositories like ATRPMs, but sometimes it's just... > wonky. I'm not getting you wrong. :-) But it would help if you are a bit more specific about the weird issues you have seen. I have been using ELRepo packages on my RHEL 6 machine with no apparent "wonky-ness" ... Akemi From thomas at redhat.com Tue Oct 9 20:31:57 2012 From: thomas at redhat.com (thomas at redhat.com) Date: Tue, 09 Oct 2012 15:31:57 -0500 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: References: <50744E41.60100@redhat.com> <50746D8B.1030703@redhat.com> <50747307.4040804@redhat.com> Message-ID: <507489BD.7050302@redhat.com> On 10/09/2012 02:13 PM, Mirko Vukovic wrote: > On Tue, Oct 9, 2012 at 2:55 PM, thomas at redhat.com wrote: >> On 10/09/2012 01:31 PM, thomas at redhat.com wrote: >>> >>> The Protected multilib error tells me you might have two versions (i686 >>> and x86_64) of a package installed. This is not a big deal, but the >>> nature of using RHN to do updates is that it processes each errata and >>> the associated RPMs serially. So if you have one erratum which addresses >>> the 32-bit version of a file and another which addresses the 64-bit >>> version, you might see that. You might get an error when it tries to >>> update the first package because of common dependencies with the second. >>> Without more of the error message, it's hard to tell, but I don't see >>> anything which is seriously alarming in what you've posted. Frustrating, >>> for sure. But not unexpected. >> >> >> My understanding of this ^^^ is probably wrong. I checked and there should >> not be different errata for different architectures. I am digging as to what >> actually causes that multilib conflict. It would be really helpful if you >> could post the whole history. You can dump it in raw format from the same >> location I pointed you to earlier. >> >> I'm terribly sorry for the noise. I'll post when I get a better >> understanding of what causes this. >> >> > > I'm sorry but I don't see how to download the raw data from the > system/events/history page. (I checked on knowledge base, but other > than yum and rpm logs, and /var/log, I did not find anything) Argh. I'm just full of fail today. RHN Satellite allows you to view the raw output. RHN Hosted apparently does not. -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US 512-241-0774 office / 512-585-5631 cell http://people.redhat.com/tcameron/ IRC: choirboy / AIM: rhelguy / Yahoo: rhce_guy Red Hat named to Forbes 2012 World's Most Innovative Companies list: http://www.redhat.com/innovation From thomas at redhat.com Tue Oct 9 20:35:34 2012 From: thomas at redhat.com (thomas at redhat.com) Date: Tue, 09 Oct 2012 15:35:34 -0500 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: References: <50744E41.60100@redhat.com> <50746D8B.1030703@redhat.com> Message-ID: <50748A96.40706@redhat.com> On 10/09/2012 03:04 PM, Akemi Yagi wrote: > On Tue, Oct 9, 2012 at 11:31 AM, thomas at redhat.com wrote: > >> Not a huge deal, but I've seen some really weird issues with third party >> repositories like ELRepo and even EPEL. Don't get me wrong, I use EPEL and >> other third party repositories like ATRPMs, but sometimes it's just... >> wonky. > > I'm not getting you wrong. :-) But it would help if you are a bit more > specific about the weird issues you have seen. I have been using > ELRepo packages on my RHEL 6 machine with no apparent "wonky-ness" ... As a for instance - at one point when I enabled EPEL, I got a newer version of some python libs that caused weird errors with osad. Another time, when trying to install VLC from ATRPMs I got a weird package upgrade loop which required that I use --skip-broken or --exclude. I can't point to any other specifics right off the top of my head. Nothing catastrophic, just... wonky. -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US 512-241-0774 office / 512-585-5631 cell http://people.redhat.com/tcameron/ IRC: choirboy / AIM: rhelguy / Yahoo: rhce_guy Red Hat named to Forbes 2012 World's Most Innovative Companies list: http://www.redhat.com/innovation From thomas at redhat.com Tue Oct 9 20:39:00 2012 From: thomas at redhat.com (thomas at redhat.com) Date: Tue, 09 Oct 2012 15:39:00 -0500 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: <50747307.4040804@redhat.com> References: <50744E41.60100@redhat.com> <50746D8B.1030703@redhat.com> <50747307.4040804@redhat.com> Message-ID: <50748B64.5070603@redhat.com> On 10/09/2012 01:55 PM, thomas at redhat.com wrote: > On 10/09/2012 01:31 PM, thomas at redhat.com wrote: >> The Protected multilib error tells me you might have two versions (i686 >> and x86_64) of a package installed. This is not a big deal, but the >> nature of using RHN to do updates is that it processes each errata and >> the associated RPMs serially. So if you have one erratum which addresses >> the 32-bit version of a file and another which addresses the 64-bit >> version, you might see that. You might get an error when it tries to >> update the first package because of common dependencies with the second. >> Without more of the error message, it's hard to tell, but I don't see >> anything which is seriously alarming in what you've posted. Frustrating, >> for sure. But not unexpected. > > My understanding of this ^^^ is probably wrong. I checked and there > should not be different errata for different architectures. I am digging > as to what actually causes that multilib conflict. It would be really > helpful if you could post the whole history. You can dump it in raw > format from the same location I pointed you to earlier. > > I'm terribly sorry for the noise. I'll post when I get a better > understanding of what causes this. > This BZ demonstrates the case you ran into: https://bugzilla.redhat.com/show_bug.cgi?id=758428 It appears that the issue is being worked on. -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US 512-241-0774 office / 512-585-5631 cell http://people.redhat.com/tcameron/ IRC: choirboy / AIM: rhelguy / Yahoo: rhce_guy Red Hat named to Forbes 2012 World's Most Innovative Companies list: http://www.redhat.com/innovation From mirko.vukovic at gmail.com Wed Oct 10 14:31:32 2012 From: mirko.vukovic at gmail.com (Mirko Vukovic) Date: Wed, 10 Oct 2012 10:31:32 -0400 Subject: [rhelv6-list] why do errata and package updates fail? In-Reply-To: <50748B64.5070603@redhat.com> References: <50744E41.60100@redhat.com> <50746D8B.1030703@redhat.com> <50747307.4040804@redhat.com> <50748B64.5070603@redhat.com> Message-ID: On Tue, Oct 9, 2012 at 4:39 PM, thomas at redhat.com wrote: > On 10/09/2012 01:55 PM, thomas at redhat.com wrote: >> >> On 10/09/2012 01:31 PM, thomas at redhat.com wrote: >>> >>> The Protected multilib error tells me you might have two versions (i686 >>> and x86_64) of a package installed. This is not a big deal, but the >>> nature of using RHN to do updates is that it processes each errata and >>> the associated RPMs serially. So if you have one erratum which addresses >>> the 32-bit version of a file and another which addresses the 64-bit >>> version, you might see that. You might get an error when it tries to >>> update the first package because of common dependencies with the second. >>> Without more of the error message, it's hard to tell, but I don't see >>> anything which is seriously alarming in what you've posted. Frustrating, >>> for sure. But not unexpected. >> >> >> My understanding of this ^^^ is probably wrong. I checked and there >> should not be different errata for different architectures. I am digging >> as to what actually causes that multilib conflict. It would be really >> helpful if you could post the whole history. You can dump it in raw >> format from the same location I pointed you to earlier. >> >> I'm terribly sorry for the noise. I'll post when I get a better >> understanding of what causes this. >> > > This BZ demonstrates the case you ran into: > > https://bugzilla.redhat.com/show_bug.cgi?id=758428 > > It appears that the issue is being worked on. > Thanks for the info. In the meantime, I'll put it on my schedule to do a manual yum update once a week. Thanks to all, Mirko From paul at mad-scientist.net Sat Oct 13 05:19:25 2012 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 13 Oct 2012 01:19:25 -0400 Subject: [rhelv6-list] Problems with XFS leaving 0-length files in RHEL 6.2 ... ? Message-ID: <1350105565.10588.53.camel@homebase> Hi all. We've been using standard RHEL 6.2 on our test systems (no updates, straight off of the Server DVD... however we load only a small-ish subset of the full OS). Lately we've been seeing issues where we have a number of 0-length files on our partitions. These systems have not (as far as I'm aware) crashed or had any kind of power hit or anything like that, and the files that are 0-length don't appear to be modified much, if at all. It seems bizarre that they should suddenly be empty. These filesystems are on 2.7T partitions (each), and are on rack-mounted servers with three harddrives RAIDed using an LSI MegaRAID SAS 2208 hardware RAID controller. The filesystems are created using the XFS filesystem... mainly we chose XFS because it's MUCH faster to create large partitions like this than ext, which we're doing a good bit. It was a supported filesystem in RHEL 6.2, so I thought it would be robust. I can't say for sure that this is an XFS problem; I'm trying to get more rigorous about detecting this problem closer to when it happens so I can check logs, etc. On the other hand I've heard rumors about issues like this in XFS, but I thought all the known ones were resolved in RHEL 6.2. So, I'm looking for information: * Does this seem likely to be an XFS problem? Should we move to ext4? * Would it help this problem to go to RHEL 6.3? Any known XFS issues, esp. kernel issues, resolved between 6.2 and 6.3? I took a spin through the 6.3 release notes but didn't see anything. From ewwhite at mac.com Sat Oct 13 05:53:20 2012 From: ewwhite at mac.com (Edmund White) Date: Sat, 13 Oct 2012 05:53:20 +0000 Subject: [rhelv6-list] Problems with XFS leaving 0-length files in RHEL 6.2 ... ? In-Reply-To: <1350105565.10588.53.camel@homebase> Message-ID: What are the names of these files? Can you see when these files are created? This may not be an XFS-specific issue. If you *do* move to EL6.3, there is a major change in XFS that can impact your storage requirements/performance. A feature named "XFS Dynamic Speculative EOF Preallocation" was committed to the 2.6.38 kernel in late 2010/early 2011 and made its way into the EL6.3 distribution this year. I won't go into full detail here, but I wrote a comprehensive breakdown of the feature and impact on ServerFault.com this summer. See: http://serverfault.com/q/406069/13325 -- Edmund White ewwhite at mac.com On 10/13/12 12:19 AM, "Paul Smith" wrote: >Hi all. We've been using standard RHEL 6.2 on our test systems (no >updates, straight off of the Server DVD... however we load only a >small-ish subset of the full OS). > >Lately we've been seeing issues where we have a number of 0-length files >on our partitions. These systems have not (as far as I'm aware) crashed >or had any kind of power hit or anything like that, and the files that >are 0-length don't appear to be modified much, if at all. It seems >bizarre that they should suddenly be empty. > >These filesystems are on 2.7T partitions (each), and are on rack-mounted >servers with three harddrives RAIDed using an LSI MegaRAID SAS 2208 >hardware RAID controller. > >The filesystems are created using the XFS filesystem... mainly we chose >XFS because it's MUCH faster to create large partitions like this than >ext, which we're doing a good bit. It was a supported filesystem in >RHEL 6.2, so I thought it would be robust. I can't say for sure that >this is an XFS problem; I'm trying to get more rigorous about detecting >this problem closer to when it happens so I can check logs, etc. On the >other hand I've heard rumors about issues like this in XFS, but I >thought all the known ones were resolved in RHEL 6.2. > >So, I'm looking for information: > * Does this seem likely to be an XFS problem? Should we move to > ext4? > * Would it help this problem to go to RHEL 6.3? Any known XFS > issues, esp. kernel issues, resolved between 6.2 and 6.3? I > took a spin through the 6.3 release notes but didn't see > anything. > > >_______________________________________________ >rhelv6-list mailing list >rhelv6-list at redhat.com >https://www.redhat.com/mailman/listinfo/rhelv6-list From paul at mad-scientist.net Sat Oct 13 14:27:23 2012 From: paul at mad-scientist.net (Paul Smith) Date: Sat, 13 Oct 2012 10:27:23 -0400 Subject: [rhelv6-list] Problems with XFS leaving 0-length files in RHEL 6.2 ... ? In-Reply-To: References: Message-ID: <1350138443.10588.60.camel@homebase> On Sat, 2012-10-13 at 05:53 +0000, Edmund White wrote: > What are the names of these files? Can you see when these files are > created? This may not be an XFS-specific issue. I definitely agree that it may not be XFS-specific, and I've implemented some steps to do more investigation (a simple shell script invoked via cron to get a list of all 0-length files; if there is any change to the contents of the list from the previous version it's saved, otherwise it's removed). One file that seems to be zeroed a lot is the ~/.bashrc of a specific system account for one of our applications. If it were only that file I would be pretty confident that it was not XFS--what are the odds? But on one other system I saw *.doc files, *.xml files, LICENSE, README, RELEASE-NOTES.html, and lots of other files that I can't imagine would ever be modified once installed on the system, all zero-length. Anyway I obviously don't know enough to say anything concrete yet, but the behavior is extremely bizarre. I was wondering if anyone here had a similar experience and could say "oh yes that's XYZ". > If you *do* move to EL6.3, there is a major change in XFS that can > impact your storage requirements/performance. Thanks for that; that was very interesting! From Sandro.Roth at zurich-airport.com Mon Oct 15 15:18:09 2012 From: Sandro.Roth at zurich-airport.com (Roth, Sandro) Date: Mon, 15 Oct 2012 15:18:09 +0000 Subject: [rhelv6-list] Antwort: Re: MD devices lost after boot In-Reply-To: References: <03E3E9B6-C7BF-4179-B325-C2C07EE50820@cisco.com> <81756250-6464-4275-909C-D63D1B6B67FE@cisco.com> Message-ID: Hi all I?ve worked through this with RedHat Support and they have come to the following solution. In order to automatically assemble MD devices after a reboot, you will need to: - Create partitions on mpath devices with type fd ? raid auto detect - Remove rd_NO_MD and rd_NO_DM from the grub kernel line - Edit the /etc/mdadm.conf DEVICE line to ?partitions? instead of ?DEVICE /dev/?? - Run dracut ?f From the manpage: The word partitions will cause mdadm to read /proc/partitions and include all devices and partitions found therein. mdadm does not use the names from /proc/partitions but only the major and minor device numbers. It scans /dev to find the name that matches the numbers. No init scripts or any other fiddling needed anymore ? There will also be a new KB article so keep an eye out for that one. Cheers Sandro From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Roth, Sandro Sent: Donnerstag, 27. September 2012 03:59 To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list Subject: Re: [rhelv6-list] Antwort: Re: MD devices lost after boot I tried that as well, but still not assembling after a reboot. And I think you?ll run into problems when you want to resize the LUN or partition in your case. The kernel won?t update it?s partition table, you?d have to reboot. At least that?s my experience. I might be wrong.. From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Brian Long Sent: Donnerstag, 27. September 2012 02:05 To: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list Subject: Re: [rhelv6-list] Antwort: Re: MD devices lost after boot On Sep 27, 2012, at 7:49 AM, Andreas Reschke wrote: rhelv6-list-bounces at redhat.com schrieb am 27.09.2012 13:37:29: > Brian Long > > Gesendet von: rhelv6-list-bounces at redhat.com > > 27.09.2012 13:39 > > Bitte antworten an > "Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list" > > > > An > > "Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list" > > > > Kopie > > Thema > > Re: [rhelv6-list] MD devices lost after boot > > On Sep 27, 2012, at 3:05 AM, Roth, Sandro wrote: > > Hi experts > > I wasn?t sure where to post this so I?m sending it to this list. > > We have a setup which uses lvm over md over multipath devices. (at > least that?s the plan) > According to this article it is supported in RHEL6 (it wasn?t in RHEL5) > https://access.redhat.com/knowledge/solutions/48634 > > I created my md device as follows > # mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/ > mapper/mpatha /dev/mapper/mpathb > > Do /dev/mapper/mpatha and mpathb have partition type of "fd - Linux > RAID auto"? If not, they won't be set up properly when booting the server. > > /Brian/_______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list Hi Brian, sorry you're not right. There is no need for partitions with lvm. You can use the whole disk without partitions. Something is broken with your email client since it's not maintaining threads properly (and it's prepending "Antwort:"). Last I knew, if you didn't use partitions with MD and/or LVM, certain things wouldn't work properly. I always create a single whole-disk partition and give it a "fd" type. I think this is still the best practice although it's not a requirement. /Brian/ -- Brian Long | | Corporate Security Programs Org . | | | . | | | . ' ' C I S C O This email message and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify us immediately and destroy the original transmittal. You are hereby notified that any review, copying or distribution of it is strictly prohibited. Thank you for your cooperation. Header information contained in E-mails to and from the company are monitored for operational reasons in accordance with swiss data protection act. This email message and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify us immediately and destroy the original transmittal. You are hereby notified that any review, copying or distribution of it is strictly prohibited. Thank you for your cooperation. Header information contained in E-mails to and from the company are monitored for operational reasons in accordance with swiss data protection act. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eng-partner-management at redhat.com Mon Oct 15 15:47:18 2012 From: eng-partner-management at redhat.com (Engineering Partner Management) Date: Mon, 15 Oct 2012 11:47:18 -0400 Subject: [rhelv6-list] Red Hat Developer Toolset 1.1 Beta Available for Testing Message-ID: <507C3006.1080101@redhat.com> Today Red Hat announces the Beta availability of version 1.1 of the Red Hat Developer Toolset. For developers, having ready access to the latest stable development tools is key to taking advantage of open source innovation. Red Hat Developer Toolset 1.1 bridges development agility with production stability by delivering the latest stable versions of diagnostic and debugging tools while broadening the reach of developers and the platforms to which they can deploy. Red Hat Developer Toolset makes developing applications faster and easier than ever before by allowing users to compile once and deploy to multiple versions of Red Hat Enterprise Linux. Using Red Hat Developer Toolset, software developers can develop applications that run on multiple versions of Red Hat Enterprise Linux, such that applications developed on Red Hat Enterprise Linux 5 can run on both Red Hat Enterprise Linux 5 and Red Hat Enterprise Linux 6. Red Hat Developer Toolset 1.1 delivers the latest stable versions of a comprehensive set of diagnostic and debugging tools, including the following significant enhancements: * SystemTap 1.8, a diagnostic tool for complex tasks that require live analysis, programmable on-line response, and whole-system symbolic access. * OProfile 0.9.7, providing Linux developers with a low-overhead, system-wide profiler for systems ranging from laptops to large servers. * Valgrind 3.8.0, an instrumentation framework for building dynamic analysis tools that contains a set of production-quality tools for profiling programs as well as detecting memory management and threading errors. * Performance Co-Pilot (PCP) 3.6 allows developers and systems administrators to log and analyze performance metrics of systems across the network. * elfutils 0.154, a collection of utilities for processing compiled objects. * DWZ 0.7 optimizes DWARF debugging information contained in ELF shared libraries and ELF executables by compressing them into smaller debuginfo files. * Updated GNU Project Debugger (GDB) 7.5, so developers using GCC 4.7 can also use the latest version of GDB to gain visibility into applications while they execute and identify what occurred during a crash. * Updated GNU Compiler Collection (GCC) 4.7.1, providing a number of fixes and improvements to the compiler and associated runtimes. With this installment, Red Hat Developer Toolset 1.1 also broadens the reach of developers and the platforms to which they can deploy by adding support for: * Fortran in GCC 4.7, providing support for scientific and research communities through the latest version of GCC with Fortran. * IBM POWER7, allowing those running Red Hat Enterprise Linux Server for POWER7 to use the Red Hat Developer Toolset for application development. Participating in the Red Hat Developer Toolset 1.1 Beta Red Hat Developer Toolset 1.1 Beta is available now on Red Hat Network (RHN) to all customers with an active Red Hat Enterprise Linux subscription. To access and download the Beta for Red Hat Developer Toolset 1.1, please visit: https://rhn.redhat.com/rhn/software/channels/Beta.do Beta participants can access the Red Hat Enterprise Linux Developer Program online user group in the Red Hat Customer Portal to collaborate with others working with the Beta and get developer-related information. Visit: https://access.redhat.com/groups/red-hat-enterprise-linux-developer-program-beta (requires login) The version of the GNU development tool chain represented by the Red Hat Developer Toolset is an alternative to the one bundled in Red Hat Enterprise Linux releases. Compatible with all supported versions of Red Hat Enterprise Linux, Red Hat Developer Toolset is available for users who develop applications for Red Hat Enterprise Linux 5 and 6. Of course, developers can continue to use the version of the toolchain provided with Red Hat Enterprise Linux. Please see the release notes for support of specific minor releases. You can obtain Red Hat Developer Toolset by subscribing to one of the following offerings: * Red Hat Enterprise Linux Developer Suite * Red Hat Enterprise Linux Developer Support Subscriptions * Red Hat Enterprise Linux Developer Workstation * NFR subscriptions for qualifying Partners To learn more about Red Hat developer offerings, visit: http://www.redhat.com/developers/rhel Additional Resources To access additional documentation for Red Hat Developer Toolset (requires login), visit: * Red Hat Developer Toolset documentation: https://access.redhat.com/knowledge/docs/Red_Hat_Developer_Toolset/ * Red Hat Developer Toolset 1.1 Beta Release notes: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Developer_Toolset/1-Beta/html/1.1_Release_Notes/index.html * Red Hat Developer Toolset User Guide: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Developer_Toolset/1-Beta/html/User_Guide/index.html * Red Hat Software Collections Guide: https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Developer_Toolset/1-Beta/html/Software_Collections_Guide/index.html * Other Red Hat Enterprise Linux documentation: https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Linux/ Sincerely, The Red Hat Enterprise Linux Team From cfairchild at brocku.ca Tue Oct 16 00:59:35 2012 From: cfairchild at brocku.ca (Cale Fairchild) Date: Mon, 15 Oct 2012 20:59:35 -0400 Subject: [rhelv6-list] Curious vsftpd isssue Message-ID: <507CB177.3050104@brocku.ca> Today I discovered a peculiar issue with the vsftpd init scripts. My vsftpd daemon stopped authenticating properly because when I restarted the service as root the vsftpd daemon inherited the current root environment which included redirected TMP variable set to /root/tmp. Of course when it was set that way the selinux context was incorrect and the permissions on the directory itself was very restrictive. I worked around the problem by resetting my TMP and TMPDIR variables to /tmp and restarting the service again but I am wondering if this should be filed as a bug? Cale Fairchild -------------- next part -------------- An HTML attachment was scrubbed... URL: From jsbillin at umich.edu Tue Oct 16 01:28:33 2012 From: jsbillin at umich.edu (Jonathan Billings) Date: Mon, 15 Oct 2012 21:28:33 -0400 Subject: [rhelv6-list] Curious vsftpd isssue In-Reply-To: <507CB177.3050104@brocku.ca> References: <507CB177.3050104@brocku.ca> Message-ID: <20121016012833.GJ22584@negate.org> On Mon, Oct 15, 2012 at 08:59:35PM -0400, Cale Fairchild wrote: > Today I discovered a peculiar issue with the vsftpd init scripts. My > vsftpd daemon stopped authenticating properly because when I > restarted the service as root the vsftpd daemon inherited the > current root environment which included redirected TMP variable set > to /root/tmp. Of course when it was set that way the selinux context > was incorrect and the permissions on the directory itself was very > restrictive. I worked around the problem by resetting my TMP and > TMPDIR variables to /tmp and restarting the service again but I am > wondering if this should be filed as a bug? This is one of the reasons you should always use '/sbin/service' instead of running the /etc/rc.d/init.d/ directly. The 'service' script scrubs your environment and sets the CWD to / before executing the init script. The only environment variables from your root shell that are preserved are $TERM and $LANG. -- Jonathan Billings From inode0 at gmail.com Tue Oct 16 01:31:39 2012 From: inode0 at gmail.com (inode0) Date: Mon, 15 Oct 2012 20:31:39 -0500 Subject: [rhelv6-list] Curious vsftpd isssue In-Reply-To: <507CB177.3050104@brocku.ca> References: <507CB177.3050104@brocku.ca> Message-ID: On Mon, Oct 15, 2012 at 7:59 PM, Cale Fairchild wrote: > Today I discovered a peculiar issue with the vsftpd init scripts. My vsftpd > daemon stopped authenticating properly because when I restarted the service > as root the vsftpd daemon inherited the current root environment which > included redirected TMP variable set to /root/tmp. Of course when it was set > that way the selinux context was incorrect and the permissions on the > directory itself was very restrictive. I worked around the problem by > resetting my TMP and TMPDIR variables to /tmp and restarting the service > again but I am wondering if this should be filed as a bug? Restart it with # service vsftpd restart and that shouldn't happen. Bad things can always happen restarting daemons with a non-clean environment. John From reach2gaurav at gmail.com Tue Oct 16 09:01:44 2012 From: reach2gaurav at gmail.com (gaurav sharma) Date: Tue, 16 Oct 2012 14:31:44 +0530 Subject: [rhelv6-list] Availability of fanotify in RHEL6. Message-ID: Hello All, I am working on file event trapping application using fanotify and recently got a requirement to have that application run on RHEL5 and RHEL6 also. As fanotify is available since 2.6.38 version of Linux kernel, I was wondering if there is any patch available to be used in RHEL5(2.6.18.x) and RHEL6(2.6.32.x) or any plans to provide the same in future update releases ? I would really appreciate your reply. Thanks in advance, Gaurav Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail-lists at karan.org Tue Oct 16 10:31:22 2012 From: mail-lists at karan.org (Karanbir Singh) Date: Tue, 16 Oct 2012 11:31:22 +0100 Subject: [rhelv6-list] Availability of fanotify in RHEL6. In-Reply-To: References: Message-ID: <507D377A.3080707@karan.org> On 10/16/2012 10:01 AM, gaurav sharma wrote: > I am working on file event trapping application using fanotify and inotify not good enough ? -- Karanbir Singh +44-207-0999389 | http://www.karan.org/ | twitter.com/kbsingh ICQ: 2522219 | Yahoo IM: z00dax | Gtalk: z00dax GnuPG Key : http://www.karan.org/publickey.asc From reach2gaurav at gmail.com Tue Oct 16 10:52:03 2012 From: reach2gaurav at gmail.com (gaurav sharma) Date: Tue, 16 Oct 2012 16:22:03 +0530 Subject: [rhelv6-list] Availability of fanotify in RHEL6. In-Reply-To: <507D377A.3080707@karan.org> References: <507D377A.3080707@karan.org> Message-ID: On Tue, Oct 16, 2012 at 4:01 PM, Karanbir Singh wrote: > On 10/16/2012 10:01 AM, gaurav sharma wrote: > > I am working on file event trapping application using fanotify and > > inotify not good enough ? > Wish it was for my task, which is also to block access if required :( > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list Thanks, Gaurav Sharma -------------- next part -------------- An HTML attachment was scrubbed... URL: From cfairchild at brocku.ca Tue Oct 16 10:58:51 2012 From: cfairchild at brocku.ca (Cale Fairchild) Date: Tue, 16 Oct 2012 06:58:51 -0400 Subject: [rhelv6-list] Curious vsftpd isssue In-Reply-To: <20121016012833.GJ22584@negate.org> References: <507CB177.3050104@brocku.ca> <20121016012833.GJ22584@negate.org> Message-ID: <507D3DEB.9080902@brocku.ca> Thank you very much for the quick answers, this is why I checked here before opening a bug report. Being an old IRIX guy I have always called the init.d scripts directly, I guess I will have to change my ways. On 15/10/2012 21:28, Jonathan Billings wrote: > On Mon, Oct 15, 2012 at 08:59:35PM -0400, Cale Fairchild wrote: >> Today I discovered a peculiar issue with the vsftpd init scripts. My >> vsftpd daemon stopped authenticating properly because when I >> restarted the service as root the vsftpd daemon inherited the >> current root environment which included redirected TMP variable set >> to /root/tmp. Of course when it was set that way the selinux context >> was incorrect and the permissions on the directory itself was very >> restrictive. I worked around the problem by resetting my TMP and >> TMPDIR variables to /tmp and restarting the service again but I am >> wondering if this should be filed as a bug? > This is one of the reasons you should always use '/sbin/service' > instead of running the /etc/rc.d/init.d/ directly. > The 'service' script scrubs your environment and sets the CWD to / > before executing the init script. The only environment variables from > your root shell that are preserved are $TERM and $LANG. > > -- > Jonathan Billings > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From greg at nytefyre.net Tue Oct 16 13:09:21 2012 From: greg at nytefyre.net (Greg Swift) Date: Tue, 16 Oct 2012 08:09:21 -0500 Subject: [rhelv6-list] Availability of fanotify in RHEL6. In-Reply-To: References: <507D377A.3080707@karan.org> Message-ID: On Tue, Oct 16, 2012 at 5:52 AM, gaurav sharma wrote: > On Tue, Oct 16, 2012 at 4:01 PM, Karanbir Singh > wrote: >> >> On 10/16/2012 10:01 AM, gaurav sharma wrote: >> > I am working on file event trapping application using fanotify and >> >> inotify not good enough ? > > > Wish it was for my task, which is also to block access if required :( So, if its in the upstream kernel, and you have a support contract, you can open a Request for Enhancement (RFE) ticket w/ RH support. They should make a bugzilla entry for it. Avoid giving them any 'sensitive' data that would go into the ticket so that you can get them to make it public (you have to request that). Then find other people that want this and get them to back your bugzilla. Cause without enough momentum behind it they'll let it bitrot (love ya RH but you've sat on these that were almost completely done for over 5 dot releases and then said,' oh, its too late to add this') So basically, if you do the leg work, keep on them, and get enough customer support for the feature you should be able to get it. Don't distress, its doable. For every one that I had bitrot, I usually had at least one that made it in. Oh, and its too late for RHEL5. -greg From derek at umiacs.umd.edu Wed Oct 17 19:38:26 2012 From: derek at umiacs.umd.edu (Derek Yarnell) Date: Wed, 17 Oct 2012 15:38:26 -0400 Subject: [rhelv6-list] java-1.6.0-sun Message-ID: <507F0932.5050205@umiacs.umd.edu> Hi, Does anyone know if this package is no longer going to be updated? Neither of the last two java updates (RHSA-2012:1384/1385 or RHSA-2012:1221/1222) have released packages specifically for java-1.6.0-sun. Are people just expected to migrate to the java-1.6.0-openjdk packages or java-1.7.0-oracle pacakges? We had people early on with our RHEL5/6 deployments have issues with the openjdk packages and is why we standardized on the sun ones. Do people believe openjdk is a drop in replacement for the sun package now? Thanks, derek -- --- Derek T. Yarnell University of Maryland Institute for Advanced Computer Studies From neo3matrix at gmail.com Fri Oct 19 06:32:01 2012 From: neo3matrix at gmail.com (neo3 matrix) Date: Fri, 19 Oct 2012 12:02:01 +0530 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? Message-ID: Hi all, I have installed RHEL6 as guest OS on Citrix Xen Server. After installation of OS, I can see disk names as /dev/xvda, /dev/xvdb instead of traditional convention like /dev/sda, /dev/sdb on guest OS. Generally, on physical machines, in /proc/scsi/scsi file, we get a unique entry for every disk connected to the system. For e.g. string "scsi02:00:00:01" indicates that this disk is connected to the machine via Host=2, Channel=00, Id=00 Lun=01. This helps me in my project to uniquely identify each and every disk in scenarios where many times after reboot OR in SAN boot cases OR in some Disaster Recovery procedures, disk names might change from say /dev/sda to /dev/sdb after reboot. But, this Host:Channel:ID:Lun combination remains same for every disk and I can uniquely identify the disks though their /dev/sd* names have changed. For my project, on Citrix Xenserver, I need to know the unique disk location for such Xen guest OS devices by which I can easily identify disks across the reboots for the above mentioned cases. So, I have couple of questions on this front. Please help me out or guide me for the same. 1. As /proc/scsi/scsi don't have such entry for /dev/xvdX type disks, do we have similar mechanism in Citrix XenServer to identify our guest OS disks uniquely? 2. This question is rather a continuation of previous one. While searching answer for above question, I found that for every /dev/xvdX disk, a unique device entry is present in /sys/block/xvdX/ directory in the format "vbd-XXX", for example, vbd-768, vbd-832, etc. Here, vbd stands for Virtual Block Device. But what is the significant of the numbers 768, 832 ,etc.? How these are generated? Are they indicating something like Host:Channel:Id:Lun? Can I trust these numbers to distinctly identify my disks? Are these numbers differ from one guest OS to other OR depend on Xenserver configuration? Please suggest me some answer/guideline on this front. Regards, Neo -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.haxby at gmail.com Fri Oct 19 07:38:50 2012 From: john.haxby at gmail.com (John Haxby) Date: Fri, 19 Oct 2012 08:38:50 +0100 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: References: Message-ID: On 19 October 2012 07:32, neo3 matrix wrote: > Hi all, > > I have installed RHEL6 as guest OS on Citrix Xen Server. After > installation of OS, I can see disk names as /dev/xvda, /dev/xvdb instead of > traditional convention like /dev/sda, /dev/sdb on guest OS. > > Generally, on physical machines, in /proc/scsi/scsi file, we get a unique > entry for every disk connected to the system. For e.g. string > "scsi02:00:00:01" indicates that this disk is connected to the machine via > Host=2, Channel=00, Id=00 Lun=01. This helps me in my project to uniquely > identify each and every disk in scenarios where many times after reboot OR > in SAN boot cases OR in some Disaster Recovery procedures, disk names might > change from say /dev/sda to /dev/sdb after reboot. But, this > Host:Channel:ID:Lun combination remains same for every disk and I can > uniquely identify the disks though their /dev/sd* names have changed. > > For my project, on Citrix Xenserver, I need to know the unique disk > location for such Xen guest OS devices by which I can easily identify disks > across the reboots for the above mentioned cases. > > Oooh. Complicated question. To start with, those SCSI-type disk identifiers are not as deterministic as you might hope. "Host=2" merely refers to the SCSI controller that was discovered at position number 2. These days, discovery order counts for nothing: devices are discovered and initialised concurrently, more or less, so while you might get devices discovered in the "right" order almost all the time, you might find that powering on a machine on a particularly cold morning changes the order in which things are discovered. Even worse, if what used to be /dev/sdb goes AWOL then you're not left with a hole in the sequence, everything from what used to be /dev/sdc onwards gets renamed. The good news with Xen disks is that they really do have deterministic slots. The virtual disk in slot xvdb will always be xvdb (the "vbd-NNN" numbers simply refer to event channels, they aren't random but they might as well be). You would need to edit the VM definition in the host to change the virtual disks. Even more good news: you don't need to use the /dev/sdX, /dev/xvdX, etc names at all. If you look in /dev/disk you'll find several directories. The one you're probably most interested in is /dev/disk/by-uuid: entries in /etc/fstab should be using the UUID= format to identify things that aren't logical volumes (logical volumes are named within their volume group and the physical volumes that make up a volume group aren't tied to specific devices although they do have specific UUIDs). Running "blkid" (as root) is quite useful as well. jch -------------- next part -------------- An HTML attachment was scrubbed... URL: From geslinux at gmail.com Sat Oct 20 14:26:25 2012 From: geslinux at gmail.com (Grzegorz Witkowski) Date: Sat, 20 Oct 2012 15:26:25 +0100 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: References: Message-ID: Use UUID and/or WWN when refering to block devices. They are consistent. Regards, Grzegorz On Oct 19, 2012 7:35 a.m., "neo3 matrix" wrote: > Hi all, > > I have installed RHEL6 as guest OS on Citrix Xen Server. After > installation of OS, I can see disk names as /dev/xvda, /dev/xvdb instead of > traditional convention like /dev/sda, /dev/sdb on guest OS. > > Generally, on physical machines, in /proc/scsi/scsi file, we get a unique > entry for every disk connected to the system. For e.g. string > "scsi02:00:00:01" indicates that this disk is connected to the machine via > Host=2, Channel=00, Id=00 Lun=01. This helps me in my project to uniquely > identify each and every disk in scenarios where many times after reboot OR > in SAN boot cases OR in some Disaster Recovery procedures, disk names might > change from say /dev/sda to /dev/sdb after reboot. But, this > Host:Channel:ID:Lun combination remains same for every disk and I can > uniquely identify the disks though their /dev/sd* names have changed. > > For my project, on Citrix Xenserver, I need to know the unique disk > location for such Xen guest OS devices by which I can easily identify disks > across the reboots for the above mentioned cases. > > So, I have couple of questions on this front. Please help me out or guide > me for the same. > > 1. As /proc/scsi/scsi don't have such entry for /dev/xvdX type disks, do > we have similar mechanism in Citrix XenServer to identify our guest OS > disks uniquely? > > 2. This question is rather a continuation of previous one. While searching > answer for above question, I found that for every /dev/xvdX disk, a unique > device entry is present in /sys/block/xvdX/ directory in the format > "vbd-XXX", for example, vbd-768, vbd-832, etc. Here, vbd stands for Virtual > Block Device. > > But what is the significant of the numbers 768, 832 ,etc.? How these are > generated? Are they indicating something like Host:Channel:Id:Lun? Can I > trust these numbers to distinctly identify my disks? Are these numbers > differ from one guest OS to other OR depend on Xenserver configuration? > > Please suggest me some answer/guideline on this front. > > > Regards, > Neo > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From neo3matrix at gmail.com Mon Oct 29 07:19:54 2012 From: neo3matrix at gmail.com (neo3 matrix) Date: Mon, 29 Oct 2012 12:49:54 +0530 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: References: Message-ID: Thank you John and Grzegorz for your quick replies. Sorry for late reply (as I was not in town). Basically, I am working on a Disaster Recovery software whose disk logic is totally dependent on disk mapping . Even in my project, I should be able to map a disk from one OS on Xenserver to other OS on other Xenserver. So, as John suggested, >>> "The good news with Xen disks is that they really do have deterministic slots. The virtual disk in slot xvdb will >>> always be xvdb (the "vbd-NNN" numbers simply refer to event channels." Here, I can't use vbd-XXX names as they differ from one guest OS to other and one Xenserver to other. Also, changing the Xenserver setting in VM definition file is in customer's hand which I cannot control. I can't try UUID as well for disk mapping because the problem is during disaster recovery process we used to repartition disks and due to that UUID of disk and partitions gets changed. So, to map disks from one xenserver to other, I need some mapping mechanism like host:channel:id:lun OR the way "lscsci" command gives output which is similar in other Xenserver as well and I can be able to map disks. Can you please help me out in the same? Thank you for your valuable suggestions. Regards, Neo On Fri, Oct 19, 2012 at 1:08 PM, John Haxby wrote: > > > On 19 October 2012 07:32, neo3 matrix wrote: > >> Hi all, >> >> I have installed RHEL6 as guest OS on Citrix Xen Server. After >> installation of OS, I can see disk names as /dev/xvda, /dev/xvdb instead of >> traditional convention like /dev/sda, /dev/sdb on guest OS. >> >> Generally, on physical machines, in /proc/scsi/scsi file, we get a unique >> entry for every disk connected to the system. For e.g. string >> "scsi02:00:00:01" indicates that this disk is connected to the machine via >> Host=2, Channel=00, Id=00 Lun=01. This helps me in my project to uniquely >> identify each and every disk in scenarios where many times after reboot OR >> in SAN boot cases OR in some Disaster Recovery procedures, disk names might >> change from say /dev/sda to /dev/sdb after reboot. But, this >> Host:Channel:ID:Lun combination remains same for every disk and I can >> uniquely identify the disks though their /dev/sd* names have changed. >> >> For my project, on Citrix Xenserver, I need to know the unique disk >> location for such Xen guest OS devices by which I can easily identify disks >> across the reboots for the above mentioned cases. >> >> > > Oooh. Complicated question. > > To start with, those SCSI-type disk identifiers are not as deterministic > as you might hope. "Host=2" merely refers to the SCSI controller that was > discovered at position number 2. These days, discovery order counts for > nothing: devices are discovered and initialised concurrently, more or less, > so while you might get devices discovered in the "right" order almost all > the time, you might find that powering on a machine on a particularly cold > morning changes the order in which things are discovered. Even worse, if > what used to be /dev/sdb goes AWOL then you're not left with a hole in the > sequence, everything from what used to be /dev/sdc onwards gets renamed. > > The good news with Xen disks is that they really do have deterministic > slots. The virtual disk in slot xvdb will always be xvdb (the "vbd-NNN" > numbers simply refer to event channels, they aren't random but they might > as well be). You would need to edit the VM definition in the host to > change the virtual disks. > > Even more good news: you don't need to use the /dev/sdX, /dev/xvdX, etc > names at all. > > If you look in /dev/disk you'll find several directories. The one you're > probably most interested in is /dev/disk/by-uuid: entries in /etc/fstab > should be using the UUID= format to identify things that aren't logical > volumes (logical volumes are named within their volume group and the > physical volumes that make up a volume group aren't tied to specific > devices although they do have specific UUIDs). > > Running "blkid" (as root) is quite useful as well. > > jch > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From herbert.van.den.bergh at oracle.com Mon Oct 29 15:12:17 2012 From: herbert.van.den.bergh at oracle.com (Herbert van den Bergh) Date: Mon, 29 Oct 2012 08:12:17 -0700 Subject: [rhelv6-list] How can I uniquely identify my disk in RHEL6 installed on Citrix Xenserver? In-Reply-To: References: Message-ID: <508E9CD1.1090003@oracle.com> The hardware mapping is not going to be deterministic between servers. So you need to rely on some unique identifier stored in the contents of the virtual disks. Which one you can use depends on how you backup and restore your virtual disks. Where does your DR restore run? In domU or in dom0? And how exactly do you backup and restore the virtual disks? Thanks, Herbert. On 10/29/12 12:19 AM, neo3 matrix wrote: > Thank you John and Grzegorz for your quick replies. > Sorry for late reply (as I was not in town). > > Basically, I am working on a Disaster Recovery software whose disk > logic is totally dependent on disk mapping . > > Even in my project, I should be able to map a disk from one OS on > Xenserver to other OS on other Xenserver. > > So, as John suggested, > >>> "The good news with Xen disks is that they really do have > deterministic slots. The virtual disk in slot xvdb will >>> always > be xvdb (the "vbd-NNN" numbers simply refer to event channels." > Here, I can't use vbd-XXX names as they differ from one guest OS to > other and one Xenserver to other. > Also, changing the Xenserver setting in VM definition file is in > customer's hand which I cannot control. > > I can't try UUID as well for disk mapping because the problem is > during disaster recovery process we used to repartition disks and due > to that UUID of disk and partitions gets changed. > > So, to map disks from one xenserver to other, I need some mapping > mechanism like host:channel:id:lun > OR > the way "lscsci" command gives output which is similar in other > Xenserver as well and I can be able to map disks. > > Can you please help me out in the same? > > Thank you for your valuable suggestions. > > Regards, > Neo > > > > > On Fri, Oct 19, 2012 at 1:08 PM, John Haxby > wrote: > > > > On 19 October 2012 07:32, neo3 matrix > wrote: > > Hi all, > > I have installed RHEL6 as guest OS on Citrix Xen Server. After > installation of OS, I can see disk names as /dev/xvda, > /dev/xvdb instead of traditional convention like /dev/sda, > /dev/sdb on guest OS. > > Generally, on physical machines, in /proc/scsi/scsi file, we > get a unique entry for every disk connected to the system. For > e.g. string "scsi02:00:00:01" indicates that this disk is > connected to the machine via Host=2, Channel=00, Id=00 Lun=01. > This helps me in my project to uniquely identify each and > every disk in scenarios where many times after reboot OR in > SAN boot cases OR in some Disaster Recovery procedures, disk > names might change from say /dev/sda to /dev/sdb after reboot. > But, this Host:Channel:ID:Lun combination remains same for > every disk and I can uniquely identify the disks though their > /dev/sd* names have changed. > > For my project, on Citrix Xenserver, I need to know the unique > disk location for such Xen guest OS devices by which I can > easily identify disks across the reboots for the above > mentioned cases. > > > > Oooh. Complicated question. > > To start with, those SCSI-type disk identifiers are not as > deterministic as you might hope. "Host=2" merely refers to the > SCSI controller that was discovered at position number 2. These > days, discovery order counts for nothing: devices are discovered > and initialised concurrently, more or less, so while you might get > devices discovered in the "right" order almost all the time, you > might find that powering on a machine on a particularly cold > morning changes the order in which things are discovered. Even > worse, if what used to be /dev/sdb goes AWOL then you're not left > with a hole in the sequence, everything from what used to be > /dev/sdc onwards gets renamed. > > The good news with Xen disks is that they really do have > deterministic slots. The virtual disk in slot xvdb will always > be xvdb (the "vbd-NNN" numbers simply refer to event channels, > they aren't random but they might as well be). You would need to > edit the VM definition in the host to change the virtual disks. > > Even more good news: you don't need to use the /dev/sdX, > /dev/xvdX, etc names at all. > > If you look in /dev/disk you'll find several directories. The one > you're probably most interested in is /dev/disk/by-uuid: entries > in /etc/fstab should be using the UUID= format to identify things > that aren't logical volumes (logical volumes are named within > their volume group and the physical volumes that make up a volume > group aren't tied to specific devices although they do have > specific UUIDs). > > Running "blkid" (as root) is quite useful as well. > > jch > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > > > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From jas at cse.yorku.ca Tue Oct 30 20:14:09 2012 From: jas at cse.yorku.ca (Jason Keltz) Date: Tue, 30 Oct 2012 16:14:09 -0400 Subject: [rhelv6-list] NFSv4 not translation UID, GID between freebsd server and rhel63 client Message-ID: <50903511.2030001@cse.yorku.ca> I have a FreeBSD 9.1RC2 server exporting an NFS v4 filesystem (a home directory actually) that I want to mount under my rhel63 nfs client. nfsuserd is running on FreeBSD (idmapd equivalent for Linux), idmapd is running on rhel63 and both are configured with the same domain and translation of nfsswitch. Both systems share the same users and groups in /etc/passwd and /etc/group. Sure, there are some additional users and groups on either system, but the real users I care about are in both with the same uid and gid. There are no duplicate entries. On Rhel6.3, I can mount the nfs v4 share from the FreeBSD server, and it shows up as vers=4, but all the files appear as nobody:nobody, even though they are all owned by user jast7 and group "zfstest" on the FreeBSD nfs server. Aha! That's a simple ID mapping problem, you say? Well, it's probably an ID mapping problem, but not sure that it's so simple.... The exported directory is owned by jast7, group zfstest. If the exported directory is set to mode 700, and user jast7 on the rhel63 client tries to write to the directory, he can write, and yet, if another user "jas" on the rhel63 client tries to write to the directory, he cannot... Hmmm??? So I continue ... when jast7 writes on the rhel63 client, the files show up as "nobody:nobody" on the rhel63 client, but under freebsd shows up as "jast7:zfstest" as should be the case. On the other hand, if I make the exported directory mode 707, then user "jas" on the rhel63 system can indeed write a file. This file shows up as "jas:nobody" on the rhel63 system, and shows up as "jas:zfstest" on the FreeBSD server. From FreeBSD passwd: jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false jas:x:1004:1000:Jason:/cs/home/jas:/cs/local/bin/tcsh From FreeBSD group: zfstest:*:1001: tech:*:1000:tdb From Linux passwd: jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false jas:x:1004:1000:Jason:/cs/home/jas:/cs/local/bin/tcsh From Linux group: zfstest:*:1001: tech:*:1000: Just to be sure, I have tried unmounting, "service rpcidmapd restart", then mounting the share, and no difference.. Any ideas? Jason. From cubodebits at gmail.com Tue Oct 30 20:36:42 2012 From: cubodebits at gmail.com (Antonio Lopez) Date: Tue, 30 Oct 2012 21:36:42 +0100 Subject: [rhelv6-list] NFSv4 not translation UID, GID between freebsd server and rhel63 client In-Reply-To: <50903511.2030001@cse.yorku.ca> References: <50903511.2030001@cse.yorku.ca> Message-ID: Have you tried to set params anonuid,anongid to the desired uid & gid in /etc/exports ? El 30/10/2012 21:18, "Jason Keltz" escribi?: > I have a FreeBSD 9.1RC2 server exporting an NFS v4 filesystem (a home > directory actually) that I want to mount under my rhel63 nfs client. > nfsuserd is running on FreeBSD (idmapd equivalent for Linux), idmapd is > running on rhel63 and both are configured with the same domain and > translation of nfsswitch. > Both systems share the same users and groups in /etc/passwd and > /etc/group. Sure, there are some additional users and groups on either > system, but the real users I care about are in both with the same uid and > gid. There are no duplicate entries. > > On Rhel6.3, I can mount the nfs v4 share from the FreeBSD server, and it > shows up as vers=4, but all the files appear as nobody:nobody, even though > they are all owned by user jast7 and group "zfstest" on the FreeBSD nfs > server. > Aha! That's a simple ID mapping problem, you say? Well, it's probably an > ID mapping problem, but not sure that it's so simple.... The exported > directory is owned by jast7, group zfstest. If the exported directory is > set to mode 700, and user jast7 on the rhel63 client tries to write to the > directory, he can write, and yet, if another user "jas" on the rhel63 > client tries to write to the directory, he cannot... Hmmm??? > So I continue ... when jast7 writes on the rhel63 client, the files show > up as "nobody:nobody" on the rhel63 client, but under freebsd shows up as > "jast7:zfstest" as should be the case. > On the other hand, if I make the exported directory mode 707, then user > "jas" on the rhel63 system can indeed write a file. This file shows up as > "jas:nobody" on the rhel63 system, and shows up as "jas:zfstest" on the > FreeBSD server. > > From FreeBSD passwd: > > jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false > jas:x:1004:1000:Jason:/cs/**home/jas:/cs/local/bin/tcsh > > From FreeBSD group: > > zfstest:*:1001: > tech:*:1000:tdb > > From Linux passwd: > > jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false > jas:x:1004:1000:Jason:/cs/**home/jas:/cs/local/bin/tcsh > > From Linux group: > > zfstest:*:1001: > tech:*:1000: > > Just to be sure, I have tried unmounting, "service rpcidmapd restart", > then mounting the share, and no difference.. > > Any ideas? > > Jason. > > ______________________________**_________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/**mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jas at cse.yorku.ca Tue Oct 30 20:43:42 2012 From: jas at cse.yorku.ca (Jason Keltz) Date: Tue, 30 Oct 2012 16:43:42 -0400 Subject: [rhelv6-list] NFSv4 not translation UID, GID between freebsd server and rhel63 client In-Reply-To: References: <50903511.2030001@cse.yorku.ca> Message-ID: <50903BFE.6060201@cse.yorku.ca> Hi Antonio, Thanks for your response. I need the uid/gid mapping to work for all accounts, not just one. Setting the anon account would "fix" the problem for this one account, but not for the other 1000 that I intend to map. Jason. On 10/30/2012 04:36 PM, Antonio Lopez wrote: > > Have you tried to set params anonuid,anongid to the desired uid & gid > in /etc/exports ? > > El 30/10/2012 21:18, "Jason Keltz" > escribi?: > > I have a FreeBSD 9.1RC2 server exporting an NFS v4 filesystem (a > home directory actually) that I want to mount under my rhel63 nfs > client. > nfsuserd is running on FreeBSD (idmapd equivalent for Linux), > idmapd is running on rhel63 and both are configured with the same > domain and translation of nfsswitch. > Both systems share the same users and groups in /etc/passwd and > /etc/group. Sure, there are some additional users and groups on > either system, but the real users I care about are in both with > the same uid and gid. There are no duplicate entries. > > On Rhel6.3, I can mount the nfs v4 share from the FreeBSD server, > and it shows up as vers=4, but all the files appear as > nobody:nobody, even though they are all owned by user jast7 and > group "zfstest" on the FreeBSD nfs server. > Aha! That's a simple ID mapping problem, you say? Well, it's > probably an ID mapping problem, but not sure that it's so > simple.... The exported directory is owned by jast7, group > zfstest. If the exported directory is set to mode 700, and user > jast7 on the rhel63 client tries to write to the directory, he can > write, and yet, if another user "jas" on the rhel63 client tries > to write to the directory, he cannot... Hmmm??? > So I continue ... when jast7 writes on the rhel63 client, the > files show up as "nobody:nobody" on the rhel63 client, but under > freebsd shows up as "jast7:zfstest" as should be the case. > On the other hand, if I make the exported directory mode 707, then > user "jas" on the rhel63 system can indeed write a file. This > file shows up as "jas:nobody" on the rhel63 system, and shows up > as "jas:zfstest" on the FreeBSD server. > > >From FreeBSD passwd: > > jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false > jas:x:1004:1000:Jason:/cs/home/jas:/cs/local/bin/tcsh > > >From FreeBSD group: > > zfstest:*:1001: > tech:*:1000:tdb > > >From Linux passwd: > > jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false > jas:x:1004:1000:Jason:/cs/home/jas:/cs/local/bin/tcsh > > >From Linux group: > > zfstest:*:1001: > tech:*:1000: > > Just to be sure, I have tried unmounting, "service rpcidmapd > restart", then mounting the share, and no difference.. > > Any ideas? > > Jason. > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list -------------- next part -------------- An HTML attachment was scrubbed... URL: From cubodebits at gmail.com Tue Oct 30 21:11:37 2012 From: cubodebits at gmail.com (Antonio Lopez) Date: Tue, 30 Oct 2012 22:11:37 +0100 Subject: [rhelv6-list] NFSv4 not translation UID, GID between freebsd server and rhel63 client In-Reply-To: <50903BFE.6060201@cse.yorku.ca> References: <50903511.2030001@cse.yorku.ca> <50903BFE.6060201@cse.yorku.ca> Message-ID: Oops, in that case it seems to be a config file related issue. Take a look to the idmapd config file, nfs and restart services both sides client & server paying attention to log files also. Give us feedback . Its an interesting *case* El 30/10/2012 21:49, "Jason Keltz" escribi?: > Hi Antonio, > > Thanks for your response. > I need the uid/gid mapping to work for all accounts, not just one. > Setting the anon account would "fix" the problem for this one account, but > not for the other 1000 that I intend to map. > > Jason. > > On 10/30/2012 04:36 PM, Antonio Lopez wrote: > > Have you tried to set params anonuid,anongid to the desired uid & gid in > /etc/exports ? > El 30/10/2012 21:18, "Jason Keltz" escribi?: > >> I have a FreeBSD 9.1RC2 server exporting an NFS v4 filesystem (a home >> directory actually) that I want to mount under my rhel63 nfs client. >> nfsuserd is running on FreeBSD (idmapd equivalent for Linux), idmapd is >> running on rhel63 and both are configured with the same domain and >> translation of nfsswitch. >> Both systems share the same users and groups in /etc/passwd and >> /etc/group. Sure, there are some additional users and groups on either >> system, but the real users I care about are in both with the same uid and >> gid. There are no duplicate entries. >> >> On Rhel6.3, I can mount the nfs v4 share from the FreeBSD server, and it >> shows up as vers=4, but all the files appear as nobody:nobody, even though >> they are all owned by user jast7 and group "zfstest" on the FreeBSD nfs >> server. >> Aha! That's a simple ID mapping problem, you say? Well, it's probably an >> ID mapping problem, but not sure that it's so simple.... The exported >> directory is owned by jast7, group zfstest. If the exported directory is >> set to mode 700, and user jast7 on the rhel63 client tries to write to the >> directory, he can write, and yet, if another user "jas" on the rhel63 >> client tries to write to the directory, he cannot... Hmmm??? >> So I continue ... when jast7 writes on the rhel63 client, the files show >> up as "nobody:nobody" on the rhel63 client, but under freebsd shows up as >> "jast7:zfstest" as should be the case. >> On the other hand, if I make the exported directory mode 707, then user >> "jas" on the rhel63 system can indeed write a file. This file shows up as >> "jas:nobody" on the rhel63 system, and shows up as "jas:zfstest" on the >> FreeBSD server. >> >> >From FreeBSD passwd: >> >> jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false >> jas:x:1004:1000:Jason:/cs/home/jas:/cs/local/bin/tcsh >> >> >From FreeBSD group: >> >> zfstest:*:1001: >> tech:*:1000:tdb >> >> >From Linux passwd: >> >> jast7:x:14975:1001:jas test 7:/cs/home/jast7:/bin/false >> jas:x:1004:1000:Jason:/cs/home/jas:/cs/local/bin/tcsh >> >> >From Linux group: >> >> zfstest:*:1001: >> tech:*:1000: >> >> Just to be sure, I have tried unmounting, "service rpcidmapd restart", >> then mounting the share, and no difference.. >> >> Any ideas? >> >> Jason. >> >> _______________________________________________ >> rhelv6-list mailing list >> rhelv6-list at redhat.com >> https://www.redhat.com/mailman/listinfo/rhelv6-list >> > > > _______________________________________________ > rhelv6-list mailing listrhelv6-list at redhat.comhttps://www.redhat.com/mailman/listinfo/rhelv6-list > > > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From danalmmp79437 at yahoo.com Tue Oct 30 21:44:09 2012 From: danalmmp79437 at yahoo.com (Staci Page) Date: Tue, 30 Oct 2012 14:44:09 -0700 (PDT) Subject: [rhelv6-list] NFSv4 not translation UID, GID between freebsd server and rhel63 client Message-ID: <1351633449.34223.YahooMailClassic@web124901.mail.ne1.yahoo.com> Finally got your reply! hehe! It is all good though because I am just now came back home from working. I'm wondering do ya figure that you'll be game for a little some some tonight or tomorrow? I am available either day. A little bit about me, I feel that I am cute, fun to be around, a bit of a kinky chick maybe;) I've got a profile on my page with some information about me and some pictures in case that you want to see what I look like. I have my cell number will be on there as well, dunno if you would want to give me a call or not in the event I am not your style. So like I told u I am free for setting something up tonight or later tomorrow so gimme a call if you would like to hang out. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danalmmp79437 at yahoo.com Tue Oct 30 21:44:19 2012 From: danalmmp79437 at yahoo.com (Staci Page) Date: Tue, 30 Oct 2012 14:44:19 -0700 (PDT) Subject: [rhelv6-list] NFSv4 not translation UID, GID between freebsd server and rhel63 client Message-ID: <1351633459.82367.YahooMailClassic@web124904.mail.ne1.yahoo.com> Hey once again! Are u any good at giving a full body massage? Working is sort of a hurter and I have not had a rub down in awhile. I can host if you would want, just lemme know when is good for u. I have got a adjustable schedule and do online college in between so I can make something work. Oh yea I've got photos on this site if you see. You can do the screener thing and it'll give u my cell number and we can text or talk and get to know each other better. I like you so far! I know its kind of weird to do that thing, but a couple of my friends who've hooked up on Craigs list said to do it since another friend of ours was raped when she met a guy from a dating site and its worked out just fine for them. I'm sure u understand now. Send me a message so that I'll know that ya got my number. | |} Talk soon -------------- next part -------------- An HTML attachment was scrubbed... URL: