From rhelv6-list at redhat.com Tue Feb 5 18:30:53 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Tue, 05 Feb 2013 20:30:53 +0200 Subject: [rhelv6-list] Disk Partitioning & Multipathing Question Message-ID: <13cab9ff97c.4695957847837201862.-6435178644632143748@zoho.com> Hi All! I have a strange issue and I'll need your opinion! I have a rhel 6.3 full updated 64bit installation on a brand new server. Now I'm trying to configure the multipath daemon... So I have one disk from my storage with 4 paths, the sdb, sdc, sde and sdf. Also, the mpathb is the pseudo device created by the multipath daemon for the 4 paths (sdb, sdc, sde, sdf). The first partition was successfully created using fdisk -cu /dev/mapper/mpathb (first partition path: /dev/mapper/mpathbp1). The problem that I have is that I can not see any partitions on the output of the "cat /proc/partitions" command. I was expecting the sdb1, sdc1, sde1 and sdf1, but I can see only the sdb, sdc, sde,sdf. After that, I ran the partprobe command. And now I can see the right output of the "cat /proc/partitions" command. The problem is that if I reboot the server, then the /proc/partitions doesn't display the right partition tables for the sdb, sdc, sde and sdf and I have to rerun partprobe to update the /proc/partition. Any ideas? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Thu Feb 7 17:51:06 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 7 Feb 2013 11:51:06 -0600 Subject: [rhelv6-list] winbind for logon when lost networking Message-ID: Hello, I'm currently using winbind to allow users to login via their AD credentials. When it works, it works. However, if DNS or networking on the machine fails, simple things like listing files becomes impossible, and many applications fail. There must be a simple setting I missed to allow group/user enumeration while offline. I see there are offline and cached options in smb.conf and pam_winbind.conf, any tips on how to best make use of those and if they'll resolve my issue? Thanks! -Eugene -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Thu Feb 7 18:06:03 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 7 Feb 2013 13:06:03 -0500 Subject: [rhelv6-list] winbind for logon when lost networking In-Reply-To: References: Message-ID: On Thu, Feb 7, 2013 at 12:51 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Hello, > I'm currently using winbind to allow users to login via their AD > credentials. When it works, it works. > However, if DNS or networking on the machine fails, simple things like > listing files becomes impossible, and many applications fail. > There must be a simple setting I missed to allow group/user enumeration > while offline. I see there are offline and cached options in smb.conf and > pam_winbind.conf, any tips on how to best make use of those and if they'll > resolve my issue? There are numerous scenarios that can be used with AD and RHEL6, including your case where your AD admins do not maintain the required Identity Management for UNIX (aka IETF RFC2307), and you must use a local (non-centralized) POSIX attribute mapping solution like Winbindd on individual NSS/PAM-capable client like Linux (or Solaris). Red Hat covers these in its details (and rather extensive) Integration Reference Architecture document. [1] Now SSSD in RHEL6 (and RHEL5.6+, 5.7+errata recommended) _should_ be able to cache Winbindd mapped credentials as well, but it will vary based on your AD implementation. If you can send me your sssd.conf off-line, I could possibly assist. Do know that in RHEL6.4, SSSD 1.9 is included, which has the capability to replace Winbindd for even local (non-centralized) POSIX attribute mapping. I.e., SSSD no longer requires centralized POSIX attribute storage (e.g., IdM for UNIX in AD), and can do local (non-centralized) POSIX attribute mapping like Winbindd. That naturally gives automagic caching thanx to SSSD. Now, again and Ideally back to my earlier hint, if your AD admins could store your POSIX attributes in AD itself with the _built-in_ IdM for UNIX (2003R2 and later, 2008+ recommended), that would solve this altogether. You wouldn't need Winbindd for this, SSSD could access them directly, _regardless_ of SSSD version (including in RHEL5). But most AD admins don't understand NTuser v. POSIX attributes, so they won't follow this concept. In fact, you can have more Microsoft certs than them, let alone helped write a Samba book, and they will still tell you that Samba is always the solution, without knowing anything about it. -- bjs [1] http://www.redhat.com/resourcelibrary/reference-architectures/integrating-red-hat-enterprise-linux-6-with-active-directory -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith ------------------------------------------------------------ American Libertarism died in the '70s with the invention of sensationalist US mass media. Two great casualties have been the NRA and Planned Parenthood; demonized by opposing media, all while ignoring their history and the 97% they really do. From rhelv6-list at redhat.com Sat Feb 9 17:28:43 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Sat, 09 Feb 2013 11:28:43 -0600 Subject: [rhelv6-list] winbind for logon when lost networking In-Reply-To: References: Message-ID: <1614745.jxErDyHbFD@fedora-local> On Thursday, February 07, 2013 01:06:03 PM Red Hat Enterprise Linux 6 discussion mailing-list wrote: > Now SSSD in RHEL6 (and RHEL5.6+, 5.7+errata recommended) should be > able to cache Winbindd mapped credentials as well, but it will vary > based on your AD implementation. If you can send me your sssd.conf > off-line, I could possibly assist. Hi Bryan, Thank you for your in-depth answer. The reference architecture doc looks quite thorough, and I may re-do this some time in the future. I don't have SSSD enabled, nor the possiblity at this time of implementing RFC2307. The 6.3 deploment guide mentions: "SSSD works with LDAP identity providers (including OpenLDAP, Red Hat Directory Server, and Microsoft Active Directory) and can use native LDAP authentication or Kerberos authentication." Do you have any notes or tips on caching SSD + Winbind? Regards, Eugene From rhelv6-list at redhat.com Sun Feb 10 04:19:03 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Sat, 9 Feb 2013 23:19:03 -0500 Subject: [rhelv6-list] winbind for logon when lost networking In-Reply-To: <1614745.jxErDyHbFD@fedora-local> References: <1614745.jxErDyHbFD@fedora-local> Message-ID: On Sat, Feb 9, 2013 at 12:28 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Thank you for your in-depth answer. The reference architecture doc looks > quite thorough, and I may re-do this some time in the future. I don't understand what you mean by "re-do"? Maybe I should step back. I mentioned the doc because _every_ admin deploying RHEL6 who must use AD _should_ read it. Even if you end up only being able to do #1, it is very, very educational. It might even be helpful in dealing with technology-ignorant AD admins. ;) Now with that said, I don't want to go down that rabbit hole, which I'll leave to my "P.S." Let's focus on your primary issue ... DNS resolution. > I don't have SSSD enabled, I did some more digging and it's clear SSSD isn't going to help you much here (until RHEL 6.4 and SSSD 1.9). SSSD waits for DNS resolution issues to figure out off-line mode. I'm not sure Winbindd does this or has similar logic. However, Winbindd _does_ caching itself. _And_ you could enable dnsmasq on every system too. The combination should do away with your DNS query issues and Winbindd lookup problems. And even if you switch to SSSD 1.9 when RHEL 6.4 comes out, you'll still probably want dnsmasq running if your network has so many issues with DNS and connectivity. BTW, you _could_ use SSSD to migrate logins to another store (e.g., LDAP), and put your UID, GID, homedir, etc... there instead. That's how most "enterprises" do it when AD's refuse to centralize POSIX attributes in AD. It usually becomes a "compliance" issue** at that point, as the AD admins refuse to offer it. > nor the possiblity at this time of implementing RFC2307. I understand this. The great majority of AD designs I've been exposed to are very poorly designed, just for Windows. And some of us have even been involved with writing LDIF and other things for AD setups, because the AD admins don't understand such things. ;) > The 6.3 deploment guide mentions: > "SSSD works with LDAP identity providers (including OpenLDAP, Red Hat > Directory Server, and Microsoft Active Directory) and can use native LDAP > authentication or Kerberos authentication." Yeah, SSSD (through 1.8) requires the POSIX attributes be installed (IdM for UNIX) and populated. > Do you have any notes or tips on caching SSD + Winbind? Winbindd has its own caching. But I think your bigger issue is DNS. If DNS is unreliable, then that's a problem in itself. SSSD 1.9 (RHEL 6.4) will help mitigate some issues, but I think your issues are bigger and elsewhere. In fact, is the AD group doing your DNS as well? ;) -- bjs **P.S. Again, the doc assumes you have AD, and isn't trying to sell you on another identity solution (e.g., RHDS, IdM-IPA, etc...). The doc outlines four (4) options, not all but most available through RHEL 6.3. They are ... 1. Samba Winbindd (idmap_rip) 2. Samba Winbindd (idmap_ad) -- requires IdM for UNIX 3. SSSD Kerberos+LDAP -- requires IdM for UNIX 4. Kerberos+LDAP -- legacy (don't recommend it) Now you said your AD does _not_ offer centralized POSIX attributes -- i.e., IdM for UNIX neither enabled nor populated. The latter is always good to point out, because AD admins are often wholly ignorant that IETF/POSIX open standard systems cannot use Windows-only NTuser attributes (e.g., SIDs, UNC home path, etc...). ;) So that leaves you with just #1, as #2 and #3 require it, and #4 is a legacy approach I would not recommend (difficult to manage). I wish there was an option for SSSD caching end-to-end, but that's not added until SSSD 1.9 (RHEL 6.4) when SSSD adds local re-mapping like Winbindd. When you start talking 100% Microsoft supported IdM for UNIX, you get "dumb stares" from AD admins because the don't even understand how NTuser and Windows-only attributes work. Ironically and to Microsoft's credit, it attempts to offer an "open standard" solution in AD so enterprises can centralize basic POSIX (UNIX/Linux) attributes. SSSD was not only designed to work with that, but cache them, from Day 1. Without them, one can't have centralized authentication for Linux with AD (I've had this discussion too many times**). It's actually done locally by mapping at the individual systems, non-centralized (such as via Winbindd, or SSSD 1.9). Even more ironic, many organizations want to pay money (high, per-system CAL license fees) for a proprietary, off-AD store, instead of the "open standard" solution Microsoft provides. So they put those attributes in a store that can only be utilized by a proprietary vendor's solution with its per-system CAL licensing. Even funnier, most of the time they end up just managing the same POSIX attributes any way, the ones they were complaining "Linux shouldn't require" in AD (the IdM for UNIX attributes). In most cases, once I prove AD can _only_ do centralized management of POSIX attributes by installing IdM for UNIX, I finally get it installed. A quick history lesson on how Windows and IETF/POSIX differ (with Microsoft not using the latter for Windows) "educates" most AD admins (aka "my fellow MCITP/MCSE/MCSAs" as I humor them). Then they realize they aren't dong any "centralized management," and relying on each individual system to locally re-map, which is often out-of-compliance. If the AD admins still refuse, then I have a justification for management for standing up an LDAP server for this, so it is finally centralized. ;) I still cannot believe how many AD admins say "AD is our corporate standard" but then don't populate non-Windows attributes. Once someone like myself comes in and explains this to his "fellow MCITP/MCSE/MCSA peers," this usually either gets them populating them, or us using our own, centralized solution for attributes, even if AD still provides Kerberos authentication. And with SSSD, we can even migrate authentication if we want as well. ;) From rhelv6-list at redhat.com Thu Feb 21 09:37:21 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 09:37:21 +0000 Subject: [rhelv6-list] 6.4 anyone? Message-ID: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> Updating now..... -------------------------------- NOTICE OF CONFIDENTIALITY This E-mail message and its attachments (if any) are intended solely for the use of the addressees hereof. In addition, this message and the attachments (if any) may contain information that is confidential, privileged and exempt from disclosure under applicable law. If you are not the intended recipient of this message, you are prohibited from reading, disclosing, reproducing, distributing, disseminating or otherwise using this transmission. Delivery of this message to any person other than the intended recipient is not intended to waive any right or privilege. If you have received this message in error, please promptly notify the sender by reply E-mail and immediately delete this message from your system. From rhelv6-list at redhat.com Thu Feb 21 09:48:41 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 10:48:41 +0100 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> Message-ID: On Thu, Feb 21, 2013 at 10:37 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Updating now..... I see that on RHN if you download rh el 6 you now gets 6.4.... But why don't they first announce it (at list on mailing lists) and only after officially release updates? Gianluca From rhelv6-list at redhat.com Thu Feb 21 13:49:13 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 08:49:13 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> Message-ID: <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> On Feb 21, 2013, at 4:48 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On Thu, Feb 21, 2013 at 10:37 AM, Red Hat Enterprise Linux 6 > (Santiago) discussion mailing-list wrote: >> Updating now..... > > I see that on RHN if you download rh el 6 you now gets 6.4.... > > But why don't they first announce it (at list on mailing lists) and > only after officially release updates? People complain either way. :) They try to have all individual RPM updates in the appropriate channels, then send the announcement. /Brian/ From rhelv6-list at redhat.com Thu Feb 21 14:04:27 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 15:04:27 +0100 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> Message-ID: On Thu, Feb 21, 2013 at 2:49 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On Feb 21, 2013, at 4:48 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > >> On Thu, Feb 21, 2013 at 10:37 AM, Red Hat Enterprise Linux 6 >> (Santiago) discussion mailing-list wrote: >>> Updating now..... >> >> I see that on RHN if you download rh el 6 you now gets 6.4.... >> >> But why don't they first announce it (at list on mailing lists) and >> only after officially release updates? > > People complain either way. :) They try to have all individual RPM updates in the appropriate channels, then send the announcement. > I think it would be better to post the official announcement and at the same time communicate that they are going to feed the mirrors/channels in the next/few hours... more fair in my opinion than what is currently in place. Or conversely configure by default that one system will stay at its minor version unless manually change. BTW: in 5.9 should be present an option to force a system in its minor version (I read this on release notes), but I didn't find how to realize that and I don't know if this was already possible in 6.3/6.4 Gianluca From rhelv6-list at redhat.com Thu Feb 21 14:38:11 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 09:38:11 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> Message-ID: <51263153.5010606@brocku.ca> On 21/02/2013 09:04, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On Thu, Feb 21, 2013 at 2:49 PM, Red Hat Enterprise Linux 6 (Santiago) > discussion mailing-list wrote: >> On Feb 21, 2013, at 4:48 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: >> >>> On Thu, Feb 21, 2013 at 10:37 AM, Red Hat Enterprise Linux 6 >>> (Santiago) discussion mailing-list wrote: >>>> Updating now..... >>> I see that on RHN if you download rh el 6 you now gets 6.4.... >>> >>> But why don't they first announce it (at list on mailing lists) and >>> only after officially release updates? >> People complain either way. :) They try to have all individual RPM updates in the appropriate channels, then send the announcement. >> > I think it would be better to post the official announcement and at > the same time communicate that they are going to feed the > mirrors/channels in the next/few hours... more fair in my opinion than > what is currently in place. > Or conversely configure by default that one system will stay at its > minor version unless manually change. > > BTW: in 5.9 should be present an option to force a system in its minor > version (I read this on release notes), but I didn't find how to > realize that and I don't know if this was already possible in 6.3/6.4 > > Gianluca > To take it one step further, I would like to see an announcement go out on the lists a week in advance so that we know it is coming. A couple of times now I have had maintenance scheduled on my production servers with everything prepared the night before and then found 100+ extra packages ready for install the next morning due to a new release. Could there not be a prior announcement made stating the time frame when the repositories will be updated with the current release. It would also prevent us from scheduling upgrades during that period and therefore help them out a bit with any load issues during the repository synchronization. Just my two cents. Cale From rhelv6-list at redhat.com Thu Feb 21 15:51:56 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 09:51:56 -0600 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <51263153.5010606@brocku.ca> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> Message-ID: <1298E81544388440ADBE9B0072AABD81103DF749@slhmail2003.ad.slh.wisc.edu> Cale: > To take it one step further, I would like to see an announcement go > out on the lists a week in advance so that we know it is coming... While entirely agreeing with this point, I would note that historical practice by Redhat regarding point releases is fairly predictable: * beta periods last 2 months * releases happen on Thursdays I was _expecting_ to see 6.4 today. -- Jim Leinweber State Laboratory of Hygiene, University of Wisconsin - Madison phone +1 608 221 6281 PGP fp: D573 AF7D F484 EE2A F0B6 B7DB A870 7518 F87D A0D1 From rhelv6-list at redhat.com Thu Feb 21 16:04:58 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 10:04:58 -0600 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <1298E81544388440ADBE9B0072AABD81103DF749@slhmail2003.ad.slh.wisc.edu> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> <1298E81544388440ADBE9B0072AABD81103DF749@slhmail2003.ad.slh.wisc.edu> Message-ID: <512645AA.6010805@redhat.com> On 02/21/2013 09:51 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Cale: >> To take it one step further, I would like to see an announcement go >> out on the lists a week in advance so that we know it is coming... > > While entirely agreeing with this point, I would note that historical > practice by Redhat regarding point releases is fairly predictable: > > * beta periods last 2 months > * releases happen on Thursdays > > I was _expecting_ to see 6.4 today. DISCLAIMER: I work for Red Hat, but I am NOT in a business unit which releases updates, so this is NOT to be interpreted as official Red Hat policy! It's based on about seven and a half years of experience here. Having said that: What you said is *not* a reliable indicator of future behavior. It could very well change. We release updates when they're ready, not according to an arbitrary date on a calendar. IMHO, the frustration of unpredictable release dates is FAR outweighed by the frustration of a busted update. If you start engineering to dates, rather than to quality control, you're MUCH more likely to cause problems for customers. We really, really don't want to rush something out to make a date, only to have something half-baked take down customer systems. We release when it's ready. Make sense? -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US +1-512-241-0774 office / +1-512-585-5631 cell / +1-512-857-1345 fax 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 rhelv6-list at redhat.com Thu Feb 21 16:10:07 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 11:10:07 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> Message-ID: On Thu, Feb 21, 2013 at 9:04 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > I think it would be better to post the official announcement and at > the same time communicate that they are going to feed the > mirrors/channels in the next/few hours... more fair in my opinion than > what is currently in place. I absolutely disagree. The aimport should be so at the announcement, all of the distributed RHN/Customer servers (world-wide) should have a _full_, "discrete'n complete" changeset you can now sync your RHN Satellite Server to, or update your systems directly from, RHN. I would not want to satellite-sync and find I only received half of an Update (Point) Release. Best Practice (Western Hemisphere): Do your sync's/updates at lunchtime. This way if there is any issues, you can address them in the afternoon. It also schedules perfectly for Thursday morning Update (Point) Release announcements. Better Practice: Consider the Extended Update Support (EUS) entitlement [1] for your organization. I would still recommend EUS even if you clone channels in RHN Satellite Server (especially for obvious security reasons). > Or conversely configure by default that one system will stay at its > minor version unless manually change. That's exactly what the Extended Update Support (EUS) entitlement [1] is for, so you can configure your system to be on a Z-stream (e.g., EUS 5.6.z, 6.2.z, etc...). -- bjs [1] https://access.redhat.com/support/policy/updates/errata/ -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith From rhelv6-list at redhat.com Thu Feb 21 16:12:34 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 17:12:34 +0100 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <1298E81544388440ADBE9B0072AABD81103DF749@slhmail2003.ad.slh.wisc.edu> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> <1298E81544388440ADBE9B0072AABD81103DF749@slhmail2003.ad.slh.wisc.edu> Message-ID: <2F11D070582AE147B143A73E2B05E3C2050254A32E@ZMPMX009.rechtspraak.minjus.nl> >>I was _expecting_ to see 6.4 today. http://www.redhat.com/about/news/press-archive/2013/2/red-hat-announces-general-availability-of-next-minor-release-of-red-hat-enterprise-linux-6 Stefan Informatie van de Raad voor de rechtspraak, de rechtbanken, de gerechtshoven en de bijzondere colleges vindt u op www.rechtspraak.nl. From rhelv6-list at redhat.com Thu Feb 21 16:16:43 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 11:16:43 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <51263153.5010606@brocku.ca> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> Message-ID: <57BF9EF4-FF78-4B5F-84FC-463E060485C4@cisco.com> On Feb 21, 2013, at 9:38 AM, "Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list" wrote: >> >> > To take it one step further, I would like to see an announcement go out on the lists a week in advance so that we know it is coming. > A couple of times now I have had maintenance scheduled on my production servers with everything prepared the night before and then found 100+ extra packages ready for install the next morning due to a new release. Could there not be a prior announcement made stating the time frame when the repositories will be updated with the current release. It would also prevent us from scheduling upgrades during that period and therefore help them out a bit with any load issues during the repository synchronization. Cale, if you don't want to pay for Satellite to handle this situation, I recommend you set up mrepo and generate your own yum repos. Your production hosts would update from your internal yum repos instead of directly from RHN. This would allow you to rely on the yum updates being stable during your update schedule and not rely directly on RHN. Just my 2 cents. /Brian/ From rhelv6-list at redhat.com Thu Feb 21 16:22:37 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 10:22:37 -0600 Subject: [rhelv6-list] RH lists munging From: header Message-ID: <20130221162237.GA12934@hiwaay.net> Has anybody else noticed that the Red Hat mailing lists get the From: header munged to the list address? I believe this started around the beginning of the year. This is highly annoying, as it completely removes the original sender's address (unless they have it in the body), making off-list replies impossible. I've never seen a list run this way; who thought this was a good idea? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From rhelv6-list at redhat.com Thu Feb 21 16:22:26 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 11:22:26 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <512645AA.6010805@redhat.com> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> <1298E81544388440ADBE9B0072AABD81103DF749@slhmail2003.ad.slh.wisc.edu> <512645AA.6010805@redhat.com> Message-ID: On Thu, Feb 21, 2013 at 11:04 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > DISCLAIMER: I work for Red Hat, but I am NOT in a business unit which > releases updates, so this is NOT to be interpreted as official Red Hat > policy! It's based on about seven and a half years of experience here. > Having said that: What you said is *not* a reliable indicator of future > behavior. It could very well change. > We release updates when they're ready, not according to an arbitrary date on > a calendar. IMHO, the frustration of unpredictable release dates is FAR > outweighed by the frustration of a busted update. If you start engineering > to dates, rather than to quality control, you're MUCH more likely to cause > problems for customers. We really, really don't want to rush something out > to make a date, only to have something half-baked take down customer > systems. We release when it's ready. > Make sense? Just to add some (even if biased) food for thought to this ... keep three things in mind ... 1. Red Hat doesn't point fingers when it's 'not Red Hat's fault,' as Red Hat is a catalyst and enabler, and takes the burden on its shoulders, for its greater community, so it always takes ownership regardless 2. If Red Hat pre-announced, then pushed it back a week, there would be an even bigger set of complaints (especially me as I would have to explain to customers/partners), so understand why this has _never_ been done, especially since ... (keeping #1 in mind) ... 3. "Acts of God" are not the only things outside of Red Hat's control, even if some entities feel they have the same power ... ;) And with #3 ... /me runs -- bjs From rhelv6-list at redhat.com Thu Feb 21 16:26:31 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 10:26:31 -0600 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <20130221162237.GA12934@hiwaay.net> References: <20130221162237.GA12934@hiwaay.net> Message-ID: <51264AB7.8000205@redhat.com> On 02/21/2013 10:22 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Has anybody else noticed that the Red Hat mailing lists get the From: > header munged to the list address? I believe this started around the > beginning of the year. > > This is highly annoying, as it completely removes the original sender's > address (unless they have it in the body), making off-list replies > impossible. I've never seen a list run this way; who thought this was a > good idea? > Yeah, I saw that, too. I've notified our IT folks, hopefully they'll get it squared away. Sorry about that. :-( -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Central US +1-512-241-0774 office / +1-512-585-5631 cell / +1-512-857-1345 fax 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 rhelv6-list at redhat.com Thu Feb 21 16:27:39 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 11:27:39 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <512645AA.6010805@redhat.com> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> <1298E81544388440ADBE9B0072AABD81103DF749@slhmail2003.ad.slh.wisc.edu> <512645AA.6010805@redhat.com> Message-ID: <51264AFB.1010306@brocku.ca> On 21/02/2013 11:04, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On 02/21/2013 09:51 AM, Red Hat Enterprise Linux 6 (Santiago) > discussion mailing-list wrote: >> Cale: >>> To take it one step further, I would like to see an announcement go >>> out on the lists a week in advance so that we know it is coming... >> >> While entirely agreeing with this point, I would note that historical >> practice by Redhat regarding point releases is fairly predictable: >> >> * beta periods last 2 months >> * releases happen on Thursdays >> >> I was _expecting_ to see 6.4 today. > > DISCLAIMER: I work for Red Hat, but I am NOT in a business unit which > releases updates, so this is NOT to be interpreted as official Red Hat > policy! It's based on about seven and a half years of experience here. > > Having said that: What you said is *not* a reliable indicator of > future behavior. It could very well change. > > We release updates when they're ready, not according to an arbitrary > date on a calendar. IMHO, the frustration of unpredictable release > dates is FAR outweighed by the frustration of a busted update. If you > start engineering to dates, rather than to quality control, you're > MUCH more likely to cause problems for customers. We really, really > don't want to rush something out to make a date, only to have > something half-baked take down customer systems. We release when it's > ready. > > Make sense? I fully agree with not rushing a release to meet a deadline set a weeks ahead of time. However unless there are any serious security releases in the point release, which should likely not be put off until the rest of the point release packages are ready anyways, could you not give a buffer of a day or two between when the point release is announced (because it is ready to go) and when it is released? That way administrators could plan their maintenance schedules with a little more notice. I must admit that I have not had alot of experience with the beta releases, as I have limited time and money for test servers, so I have not paid alot of attention to when they are released, so it is my fault that releases sneak up on me without notice. This is not a serious issue to me or I would look into the other entitlements mentioned, however I do find the release procedure a little clunky and since someone brought up the topic I thought I would just express some options. I hope I have not wasted too much of everyone's time. Cale From rhelv6-list at redhat.com Thu Feb 21 16:28:45 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 16:28:45 +0000 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <20130221162237.GA12934@hiwaay.net> References: <20130221162237.GA12934@hiwaay.net> Message-ID: I hadn't noticed, but it is a really bad idea. Could the list admin please put the originator and the reply-to back as they should be (orignator and list respectively). jch -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Thu Feb 21 16:28:57 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 11:28:57 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <57BF9EF4-FF78-4B5F-84FC-463E060485C4@cisco.com> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> <57BF9EF4-FF78-4B5F-84FC-463E060485C4@cisco.com> Message-ID: On Thu, Feb 21, 2013 at 11:16 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > yum updates being stable I would use the phrase "yum updates being 'discrete'" or "yum updates being 'atomic'" (instead of the word 'stable', which suggests another issue). Again, if you are in the Western Hemisphere, the sync/release/announcement should work well if you update during lunch. If you update weekly, then make Thursday noon'ish your aim-point. If you are not, then offset appropriately. But just to agree with this, among other posters, if you're looking for 100% discrete/atomic updates at any single second over the Internet, then your expectations will always fail with any software distribution (Red Hat or not). It doesn't matter what your chosen solution is (RHN Satellite Server, YUM reposync, etc...), there are reasons why all enterprises utilize a solution to deal with this reality. -- bjs From rhelv6-list at redhat.com Thu Feb 21 16:49:03 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 17:49:03 +0100 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <20130221162237.GA12934@hiwaay.net> References: <20130221162237.GA12934@hiwaay.net> Message-ID: <20130221174903.155b98bd@gmail.com> On Thu, 21 Feb 2013 10:22:37 -0600, Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list wrote: > Has anybody else noticed that the Red Hat mailing lists get the From: > header munged to the list address? I believe this started around the > beginning of the year. True, as can be seen in the archives, too. https://www.redhat.com/archives/rhelv6-list/2013-January/author.html Early November for rhelv5-list: https://www.redhat.com/archives/rhelv5-list/2012-November/author.html -- M From rhelv6-list at redhat.com Thu Feb 21 16:35:00 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 11:35:00 -0500 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <51264AB7.8000205@redhat.com> References: <20130221162237.GA12934@hiwaay.net> <51264AB7.8000205@redhat.com> Message-ID: <51264CB4.9030605@brocku.ca> On 21/02/2013 11:26, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On 02/21/2013 10:22 AM, Red Hat Enterprise Linux 6 (Santiago) > discussion mailing-list wrote: >> Has anybody else noticed that the Red Hat mailing lists get the From: >> header munged to the list address? I believe this started around the >> beginning of the year. >> >> This is highly annoying, as it completely removes the original sender's >> address (unless they have it in the body), making off-list replies >> impossible. I've never seen a list run this way; who thought this was a >> good idea? >> > > Yeah, I saw that, too. I've notified our IT folks, hopefully they'll > get it squared away. Sorry about that. :-( I had noticed this a while back and looked into it. If it helps them track it down the behavior appears to have changed on Jan 7th 2013 for this list and November 7, 2012 for rhelv5. From rhelv6-list at redhat.com Thu Feb 21 17:03:59 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 12:03:59 -0500 Subject: [rhelv6-list] Update (Point) Releases and Pre-announcements -- WAS: 6.4 anyone? Message-ID: [ My last post on the matter. 100% of my comments are 100% based on long-standing experience, including with integrators and partners, with Red Hat distribution and release since Red Hat Linux 4.2 ('90s), as well as every Advanced Server / Enterprise product release. I make them as a peer professional and no other assumptions should be made. ] On Thu, Feb 21, 2013 at 11:27 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > I fully agree with not rushing a release to meet a deadline set a weeks > ahead of time. However unless there are any serious security releases in the > point release, which should likely not be put off until the rest of the > point release packages are ready anyways, Understand there are a many considerations in an Update (Point) Release. These include (my apologies if you are already quite familiar): - RHEA (Enhancements): Rarely ever released as mid-Update errata, usually saved for an Update (especially if anything is going to be rebased) - RHBA (Bugfixes): More sparingly released as mid-Update errata - RHSA (Security): Regularly released as mid-Update errata As you noted, most RHSA are released as required, as mid-Update errata, and are not held-up. But understand some Bugfix and most Enhancements must be not just unit and integration tested, but regression, integrator and other partner tested. That's a lot of moving parts, and with entities other than just Red Hat involved, there are always a lot of considerations. With that said, _if_ you would like to have an official response from Red Hat, consider filing a GSS Case. That way you could get an explanation or response from Engineering or Product Management. This list is _hardly_ the place to make such requests. Alternatively, contact your individual Red Hat representative(s). > could you not give a buffer of a day or two between when the point release is announced > (because it is ready to go) and when it is released? And what happens if there is an issue in distribution outside of Red Hat's control? Again, as someone who has done a _lot_ of deployment, management and update of _all_ sorts of platforms (I get dragged into a lot of Solaris and Windows too), I'd rather have a discrete, atomic and fully available changeset when something is announced. In fact, wouldn't it be a real issue if you set all of your updates for a specific time and then some distribution snafu hit that prevented it from being such? Red Hat has never, ever, officially pre-announced products as policy (there are exceptions, such as a Summit and other, strategic announcements), and it makes total sense to me why Red Hat does not. > That way administrators could plan their maintenance schedules with a little more > notice. Your individual Red Hat representatives is who you should be asking this of, not publicly in a Red Hat list (which will never get an answer). Many sales, solutions architects, consultants, TAMs and other individuals in Red Hat want to be ensure your continued deployment and integration success. So they will help you plan and coordinate, although remember that no date is ever set-in-stone, and don't throw them under-the-bus if they give you a "target timeframe" and it falls outside of it. > I must admit that I have not had alot of experience with the beta releases, > as I have limited time and money for test servers, so I have not paid alot > of attention to when they are released, so it is my fault that releases > sneak up on me without notice. Red Hat extremely values those customers that take the time, effort and expense to coordinate with Beta releases and their testing. To this end, Red Hat tries to meet and exceed the expectations of customers who do take the time to do so, including providing resources that are directly available. Again, please contact your individual Red Hat representatives to find out what those options and resources might be for your organization. > This is not a serious issue to me or I would look into the other entitlements mentioned, Remember, every software distribution and release entity has its own method -- and definitely tools -- for addressing asynchronous, Internet-based distribution. E.g., RHN Satellite Server would not exist if customers didn't ask for it. Same goes for the Extended Update Support (EUS) entitlement. Red Hat(R) has always been customer-driven, with the utmost consideration for community as well (beyond just Fedora(TM) and others). There are several Entitlement solutions, Enterprise tools, as well as even "free beer" community tools, and use of at least one solution is highly recommended. > however I do find the release procedure a little clunky and since someone brought > up the topic I thought I would just express some options. I hope I have not wasted > too much of everyone's time. It's never a matter of "time waste," but more of a matter of different people asking the same questions over time, and they are answered or at least mitigated, only for more people to come along and make the same set of requests or related questions. As professionals, we must ensure we mitigate risks to our organizations or customer organizations, and everything I've seen from Red Hat over the last eighteen (18) years suggest they have tried to mitigate issues in their release model. For me, almost entirely working in the western hemisphere (although with some notable development/integration successes worldwide in my time), the release model is easy to schedule. But when I've had _any_ concern, or needed a "timeframe" for internal or customer considerations, I've found my individual Red Hat representatives invaluable in assisting. Just don't go to making their timeframe suggestions into specific, hard dates (which too many customers always do). -- bjs From rhelv6-list at redhat.com Thu Feb 21 16:38:33 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 11:38:33 -0500 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <20130221162237.GA12934@hiwaay.net> References: <20130221162237.GA12934@hiwaay.net> Message-ID: <51264D89.4060804@cse.yorku.ca> On 02/21/2013 11:22 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Has anybody else noticed that the Red Hat mailing lists get the From: > header munged to the list address? I believe this started around the > beginning of the year. > > This is highly annoying, as it completely removes the original sender's > address (unless they have it in the body), making off-list replies > impossible. I've never seen a list run this way; who thought this was a > good idea? Hi. There were several "bots" on the RH list, harvesting e-mail addresses from senders to the list, and then sending rather inappropriate pictures to those senders on the list from a huge inventory of e-mail addresses. I believe that RH made the change at that time in order to stop this behavior. I know because I received those messages for quite some time! Jason. From rhelv6-list at redhat.com Thu Feb 21 18:08:27 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 12:08:27 -0600 (CST) Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! Message-ID: Hi all, Just did my first update of RHEL6.4 and experienced a very painful issue with udev renaming ethernet devices. Unfortunately, I did not capture the initial udev ethernet rules prior to the reboot. My system has an onboard NIC and a PCIE card. 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express (rev 02) With RHEL6.3, I had eth0 <-- motherboard NIC p1p1 <-- port 0 of PCIE card p1p2 <-- port 1 of PCIE card I rebooted and this came to the messages: Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth2 to rename4 Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth0 to eth2 Feb 21 10:34:59 d0 kernel: udev: renamed network interface rename4 to eth0 I needed up with eth1 <-- port 1 of the PCIE card eth2 <-- port 0 of the PCIE card I repaired my /etc/sysconfig/network-scripts/ifcfg-* files and rebooted again and now got this: Feb 21 11:47:48 d0 kernel: udev: renamed network interface eth1 to eth2 and the order is a bit different again! Anybody else having issues like I am? Are the pXpX names no longer being used? thanks, daryl From rhelv6-list at redhat.com Thu Feb 21 18:16:33 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 19:16:33 +0100 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <51264D89.4060804@cse.yorku.ca> References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> Message-ID: <20130221191633.29235c9f@gmail.com> On Thu, 21 Feb 2013 11:38:33 -0500, Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list wrote: > There were several "bots" on the RH list, harvesting e-mail addresses > from senders to the list, and then sending rather inappropriate pictures > to those senders on the list from a huge inventory of e-mail addresses. > I believe that RH made the change at that time in order to stop this > behavior. I know because I received those messages for quite some time! That may work, but *your* address is still in the "Received" headers, jas at ... so a more clever bot would still get your address from there. -- M From rhelv6-list at redhat.com Thu Feb 21 18:18:49 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 13:18:49 -0500 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: Message-ID: On Thu, Feb 21, 2013 at 1:08 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Hi all, > Just did my first update of RHEL6.4 and experienced a very painful issue > with udev renaming ethernet devices. Unfortunately, I did not capture the > initial udev ethernet rules prior to the reboot. My system has an onboard > NIC and a PCIE card. > > 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > Gigabit Ethernet (rev 20) > 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > Gigabit Ethernet (rev 20) > 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit > Ethernet PCI Express (rev 02) > > With RHEL6.3, I had > eth0 <-- motherboard NIC > p1p1 <-- port 0 of PCIE card > p1p2 <-- port 1 of PCIE card > > I rebooted and this came to the messages: > > Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth2 to rename4 > Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth0 to eth2 > Feb 21 10:34:59 d0 kernel: udev: renamed network interface rename4 to eth0 > > I needed up with > eth1 <-- port 1 of the PCIE card > eth2 <-- port 0 of the PCIE card > > I repaired my /etc/sysconfig/network-scripts/ifcfg-* files and rebooted > again and now got this: > > Feb 21 11:47:48 d0 kernel: udev: renamed network interface eth1 to eth2 > > and the order is a bit different again! Anybody else having issues like I > am? Are the pXpX names no longer being used? First off, check your /etc/udev/rules.d/ files (probably 70-persistent-* or something). You can always change the names to match the MAC addresses in that file to the names you want. Secondly, _file_ a Case immediately. This should _not_ be seen on RHEL6, and I don't see it in the Release Notes (I'm now checking the Technical Notes) either. The Dell (among other IHV) implemented em?, p?p?, etc... nomenclature should still be upstream-only, and not seen until RHEL7. Is this a Dell server? Are you running any (possibly updated?) IHV packages, even if not Dell? -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith From rhelv6-list at redhat.com Thu Feb 21 18:38:30 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 12:38:30 -0600 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: Message-ID: Hi, Thanks for the response. I think RHEL 6 has been using these device names for a while now. http://en.community.dell.com/techcenter/b/techcenter/archive/2011/05/26/meaningful-names-for-network-devices-in-rhel-6-sp1-on-dell-systems.aspx rpm -qi biosdevname shows the package coming from redhat On another system, I have devices named em1 and em2 for example. Interestingly, this system also is missing a 70-persistent-net.rules file in udev/rules.d! I better tread carefully with reboots :) PS. We are a academic customer and can't open cases for issues like this. Unless, it is happening on our satellite or proxy! :) daryl On Thu, Feb 21, 2013 at 12:18 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On Thu, Feb 21, 2013 at 1:08 PM, Red Hat Enterprise Linux 6 (Santiago) > discussion mailing-list wrote: > > Hi all, > > Just did my first update of RHEL6.4 and experienced a very painful issue > > with udev renaming ethernet devices. Unfortunately, I did not capture > the > > initial udev ethernet rules prior to the reboot. My system has an > onboard > > NIC and a PCIE card. > > > > 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > > Gigabit Ethernet (rev 20) > > 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 > > Gigabit Ethernet (rev 20) > > 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 > Gigabit > > Ethernet PCI Express (rev 02) > > > > With RHEL6.3, I had > > eth0 <-- motherboard NIC > > p1p1 <-- port 0 of PCIE card > > p1p2 <-- port 1 of PCIE card > > > > I rebooted and this came to the messages: > > > > Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth2 to > rename4 > > Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth0 to eth2 > > Feb 21 10:34:59 d0 kernel: udev: renamed network interface rename4 to > eth0 > > > > I needed up with > > eth1 <-- port 1 of the PCIE card > > eth2 <-- port 0 of the PCIE card > > > > I repaired my /etc/sysconfig/network-scripts/ifcfg-* files and rebooted > > again and now got this: > > > > Feb 21 11:47:48 d0 kernel: udev: renamed network interface eth1 to eth2 > > > > and the order is a bit different again! Anybody else having issues like > I > > am? Are the pXpX names no longer being used? > > First off, check your /etc/udev/rules.d/ files (probably > 70-persistent-* or something). You can always change the names to > match the MAC addresses in that file to the names you want. > > Secondly, _file_ a Case immediately. This should _not_ be seen on > RHEL6, and I don't see it in the Release Notes (I'm now checking the > Technical Notes) either. > > The Dell (among other IHV) implemented em?, p?p?, etc... nomenclature > should still be upstream-only, and not seen until RHEL7. Is this a > Dell server? Are you running any (possibly updated?) IHV packages, > even if not Dell? > > > -- > Bryan J Smith - Professional, Technical Annoyance > b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Thu Feb 21 19:00:24 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 14:00:24 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> <57BF9EF4-FF78-4B5F-84FC-463E060485C4@cisco.com> Message-ID: <51266EC8.4060402@brocku.ca> Please excuse this last superfluous message on this thread. I would like to apologize to anyone who was offended by my replies to this posting. I never intended to suggest or imply that the Red Hat process was broken, I just got to musing about the current process when the topic came up. As an administrator in an academic setting we are very grateful for Red Hat's continued support with the academic programs. When replying to the original post, I did not search the archives to see if my opinions had been expressed before on this list and I apologize for that and the resulting chatter. In the future I will endeavour to keep my musings to myself. Cale From rhelv6-list at redhat.com Thu Feb 21 19:12:14 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 14:12:14 -0500 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: Message-ID: On Thu, Feb 21, 2013 at 1:38 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Hi, > Thanks for the response. I think RHEL 6 has been using these device names > for a while now. Ugh, I read your initial post wrong. Disregard my prior. I apologize as none of my RHEL6 Servers have it installed. I must apologize as I have been working with a lot of whitebox, IBM blade and other solutions as of late, including KVM and RHEV guest instances too. In most cases, I have a single interface (eth0), while the chassis or hypervisor has bonded ones. I guess that's my oversight. However, it would not surprise me if Dell systems have switched, possibly some pizza-type tier-1 boxes where your end-instance is the actual, physical NICs out. This was their idea. Upstream Fedora has been using them for some time as well, so I expect it will be a standard in RHEL7. Indeed, biosdevname re-educated me. It's providing those OEM mappings. > http://en.community.dell.com/techcenter/b/techcenter/archive/2011/05/26/meaningful-names-for-network-devices-in-rhel-6-sp1-on-dell-systems.aspx > rpm -qi biosdevname shows the package coming from redhat Red Hat develops a lot of packages with assistance from IHV, including specifics for their hardware, that are in Red Hat's packages. Indeed, biosdevname is the Red Hat solution that allows renaming to the BIOS devname (OEM name). > On another system, I have devices named em1 and em2 for example. > Interestingly, this system also is missing a 70-persistent-net.rules file in > udev/rules.d! It can be set in several places. As with most standards, the /etc/ entries are usually for site-local or post-install changes, while [/var]/lib or /usr/share tends to be the location for defaults. I'm now seeing /etc/udev/rules.d/71-biosdevname.rules. > I better tread carefully with reboots :) > PS. We are a academic customer and can't open cases for issues like this. > Unless, it is happening on our satellite or proxy! :) Duly noted. My apologies for misreading your initial post. -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith From rhelv6-list at redhat.com Thu Feb 21 19:16:18 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 14:16:18 -0500 Subject: [rhelv6-list] 6.4 anyone? In-Reply-To: <51266EC8.4060402@brocku.ca> References: <18ACE6C30FF1454D93B4C039FB62EA762891598A@SPO-MAIL.stfd.ro> <13F07215-C3B2-44F8-99C1-C56B034ACFFA@cisco.com> <51263153.5010606@brocku.ca> <57BF9EF4-FF78-4B5F-84FC-463E060485C4@cisco.com> <51266EC8.4060402@brocku.ca> Message-ID: I'm not offended, and took the time to post today (normally I let most things go). And in the future, if this comes up again, just refer people to my recent post [1], or a better one from the archives. -- bjs [1] https://www.redhat.com/archives/rhelv6-list/2013-February/msg00023.html On Thu, Feb 21, 2013 at 2:00 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Please excuse this last superfluous message on this thread. > > I would like to apologize to anyone who was offended by my replies to this > posting. I never intended to suggest or imply that the Red Hat process was > broken, I just got to musing about the current process when the topic came > up. As an administrator in an academic setting we are very grateful for Red > Hat's continued support with the academic programs. > When replying to the original post, I did not search the archives to see if > my opinions had been expressed before on this list and I apologize for that > and the resulting chatter. In the future I will endeavour to keep my musings > to myself. From rhelv6-list at redhat.com Thu Feb 21 19:49:02 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 14:49:02 -0500 Subject: [rhelv6-list] Red Hat Enterprise Linux 6.4 is now available Message-ID: <51267A2E.2070007@redhat.com> Today, Red Hat announced the general availability of the next minor release of Red Hat Enterprise Linux 6, Red Hat Enterprise Linux 6.4. This release includes a broad set of updates to the existing feature set and provides rich new functionality in the areas of identity management, file system, virtualization, resource management, networks, storage, security, and end-user productivity tools. We continue to work with our customers and partners as well as the open source community to deliver technology that is innovative yet stable. Red Hat Enterprise Linux 6.4 has been designed for optimized performance, stability, and scalability to cater to today's diverse workloads running in physical, virtual, and cloud environments. Key new features and enhancements include: Identity Management * System Security Services Daemon (SSSD) enhancements extend the interoperability experience with Microsoft Active Directory by providing centralized identity access control for Linux/Unix clients in a heterogeneous environment. * Administrators can now manage Secure Shell (SSH) keys across multiple systems from a single server. * It is now possible to map user records to their associated SELinux records, making it easier to manage user access across platforms. * Administrators can assign priorities to servers so that identity lookup occurs in the defined order which can reduce network traffic. This provides IT with another tool to help meet Quality of Service (QoS) commitments or performance expectations. File System * Red Hat has taken a lead role with its partners and the upstream community on the parallel Network File System (pNFS) industry standard, driving the addition of capabilities that allow database workloads to benefit from the advantages of pNFS. This functionality offers performance gains for I/O intensive workloads like database access. Using the first-to-market, fully supported pNFS (file layout) client -- delivered in Red Hat Enterprise Linux 6.4 -- customers can begin to plan and design next-generation, scalable file system solutions based on pNFS. Virtualization * Red Hat Enterprise Linux 6.4 includes the Microsoft Hyper-V Linux drivers, which were recently accepted by the upstream Linux community, improving the overall performance of Red Hat Enterprise Linux when running as a guest on Microsoft Hyper-V. * Installation support for the VMware and Hyper-V para-virtualization drivers enable easy deployment of Red Hat Enterprise Linux as a guest in these environments. * A new storage architecture for virtual environments (virtio-scsi) provides guests with industry-leading scalable access to the storage stack. Resource Management * Enhancement to control groups (cgroups) delivers the ability to migrate multi-threaded applications without errors. * An optimized version of perf, the performance monitoring tool, is now available for the newer Intel processors. Networking * Red Hat Enterprise Linux 6.4 introduces the Precision Time Protocol (PTP) as a feature in Technology Preview. This feature is hardware dependent and applies to a set of new devices. PTP is known for CPU efficiency, network bandwidth, and low administration effort. It provides clock synchronization across the network in the sub-microsecond range by eliminating network and equipment timing variability or ?jitter.? * The Stream Control Transmission Protocol (SCTP) provides support for multi-homing communication. Multi-homing allows a single SCTP endpoint to support multiple IP addresses, which means that a session is more likely to survive a network failure. Red Hat Enterprise 6.4 implements the protocol?s ?Quick Failover Algorithm? to reduce the amount of time it takes to migrate from a failed connection to an active connection. * NetworkManager now has a standard, easy-to-use graphical user interface (GUI) for configuring and managing network interface controller (NIC) bonding and network bridges. Storage * New system log features identify the mapping from logical block device name to physical device identifier ? allowing an administrator to easily identify specific physical devices as needed. * New support for scalable snapshots and thinly-provisioned volumes in the Logical Volume Manager (LVM) allows storage pool capacity to be used as efficiently as possible. Thinly provisioned volumes consume storage space only when data has been written to them - and only as long as that data is still in use. Thin snapshot volumes allow many virtual devices to share the data blocks they hold in common. * The number of supported virtual tape drives has increased from 100 to 512. Security * Red Hat Enterprise Linux 6.4 complies with Transport Layer Security (TLS) 1.1. The 1.1 version of TLS increases communication security and integrity. It has the ability to protect against cipher block chaining (CBC) attacks. Other enhancements to TLS include improved error handling and operations between networked nodes. * The Security Content Automation Protocol (SCAP) is a standardized suite of specifications used in facilitating security auditing for enterprise-class systems. Red Hat Enterprise Linux 6.4 now supports SCAP 1.2. * System administrators can now define the amount of time that must lapse before an account is considered inactive. This automates locking inactive accounts and closes the gap during which these accounts can be exploited. Productivity Tools * Evolution now interoperates better with Microsoft Exchange. Productivity functions such as calendar support with alarm notification and meeting scheduling are improved. * Customers such as animation studios and graphic design houses now have support for the newer Wacom Intuos tablets. We greatly appreciate the dedication and collaboration within the company and with our partners and community to develop and deliver the highest quality open source enterprise platform available today. Sincerely, The Red Hat Enterprise Linux Team To read the Red Hat press release, please visit: http://www.redhat.com/about/news/press-archive/2013/2/red-hat-announces-general-availability-of-next-minor-release-of-red-hat-enterprise-linux-6 To access and download an evaluation copy for Red Hat Enterprise Linux 6.4, please visit: https://access.redhat.com/downloads/ Please note that this requires an active account on the Red Hat customer portal, and the user must filter and navigate to Red Hat Enterprise Linux 6 and the architecture of interest (e.g., x86_64, IBM Power, IBM System z, etc.). For access to the documentation for Red Hat Enterprise Linux 6.4 including the release notes, please visit: https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Linux/ From rhelv6-list at redhat.com Thu Feb 21 21:31:16 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 21 Feb 2013 22:31:16 +0100 Subject: [rhelv6-list] rhel6.4 kernel breaks server hardware vendor mgmt tools Message-ID: <15tehg9e4m3.fsf@tux.uio.no> Hi all, The decision to statically link the IPMI kernel modules in rhel6.4 breaks various vendor hardware management tools. So far I've confirmed that Dell Openmanage Server Administrator (OMSA) and HP Proliant support pack depend on those modules being standalone like before. These tools don't work with the 6.4 kernel. It's probably just the init scripts for the services that need to be fixed in order to work with statically linked IPMI modules, but out of the box these services are broken. Just a heads-up for anyone planning to upgrade their physical servers to rhel6.4. Regards, -- Trond H. Amundsen Center for Information Technology Services, University of Oslo From rhelv6-list at redhat.com Fri Feb 22 10:47:59 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 11:47:59 +0100 Subject: [rhelv6-list] rhel6.4 kernel breaks server hardware vendor mgmt tools In-Reply-To: <15tehg9e4m3.fsf@tux.uio.no> References: <15tehg9e4m3.fsf@tux.uio.no> Message-ID: <20130222114759.0fb07bc4@r2d2.marmotte.net> On Thu, 21 Feb 2013 22:31:16 +0100 "Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list" wrote: > The decision to statically link the IPMI kernel modules in rhel6.4 > breaks various vendor hardware management tools. So far I've confirmed > that Dell Openmanage Server Administrator (OMSA) and HP Proliant > support pack depend on those modules being standalone like before. > These tools don't work with the 6.4 kernel. > > It's probably just the init scripts for the services that need to be > fixed in order to work with statically linked IPMI modules, but out of > the box these services are broken. > > Just a heads-up for anyone planning to upgrade their physical servers > to rhel6.4. FWIW, I've had no problem using Dell's CLI update_firmware after updating to RHEL 6.4, and that's part of OMSA. I did notice that the ipmi_si and ipmi_msghandler modules were no longer there (since I typically try to manually load them), but bootstrap_firmware, inventory_firwmare and update_firmware all worked fine. This was a PE2950 on which I updated the main BIOS, the PERC6/i, the Broadcom NICs and the Seagate SAS disks. Maybe you were referring to some other parts of OMSA, in which case I'd be interested in knowing which. Matthias -- Matthias Saou ?? ?? ?? ?? Web: http://matthias.saou.eu/ ?????????????? Mail/XMPP: matthias at saou.eu ???? ?????? ???? ?????????????????????? GPG: 4096R/E755CC63 ?? ?????????????? ?? 8D91 7E2E F048 9C9C 46AF ?? ?? ?? ?? 21A9 7A51 7B82 E755 CC63 ???? ???? From rhelv6-list at redhat.com Fri Feb 22 10:59:58 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 11:59:58 +0100 Subject: [rhelv6-list] RHEL 6.4 update : GlusterFS client access SELinux problems Message-ID: <20130222115958.244a3d5a@r2d2.marmotte.net> Hi, Like many, I'm updating some servers to 6.4, and it has been mostly good so far. One problem I just ran into is some GlusterFS clients no longer being able to mount the GlusterFS share. On boot I see these denials : type=1400 audit(1361527863.287:4): avc: denied { execute } for pid=872 comm="mount.glusterfs" name="glusterfsd" dev=vda2 ino=396095 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:glusterd_exec_t:s0 tclass=file type=1400 audit(1361527863.293:5): avc: denied { execute } for pid=872 comm="mount.glusterfs" name="glusterfsd" dev=vda2 ino=396095 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:glusterd_exec_t:s0 tclass=file And when trying to "manually" mount, this error : # service netfs restart Mounting other filesystems: /sbin/mount.glusterfs: line 130: /usr/sbin/glusterfs: Permission denied Mount failed. Please check the log file for more details. With the same SELinux denials logged. This is a fully updated RHEL 6.4 system, including the updated SELinux policy packages, and with a full relabel performed "just in case" : selinux-policy-3.7.19-195.el6_4.1.noarch selinux-policy-targeted-3.7.19-195.el6_4.1.noarch Has anyone else seen this? For now, I'll put in a quick fix to stop these denials, but it seems like a proper fix might be needed in the main policy. Matthias -- Matthias Saou ?? ?? ?? ?? Web: http://matthias.saou.eu/ ?????????????? Mail/XMPP: matthias at saou.eu ???? ?????? ???? ?????????????????????? GPG: 4096R/E755CC63 ?? ?????????????? ?? 8D91 7E2E F048 9C9C 46AF ?? ?? ?? ?? 21A9 7A51 7B82 E755 CC63 ???? ???? From rhelv6-list at redhat.com Fri Feb 22 11:01:17 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 12:01:17 +0100 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: Message-ID: <20130222110117.GA5972@lists> On Thu, Feb 21, 2013 at 12:38:30PM -0600, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > PS. We are a academic customer and can't open cases for issues like this. > Unless, it is happening on our satellite or proxy! :) Official support is important to further grow product development and receive also more from Red Hat then an ISO-image for installation. Red Hat cares a lot about having a technical good product and is very responsive to bug-reports in bugzilla. Even if you don't have official support, you should actively report problems there. In some way you help them develop the product by giving them "free" feedback. ;-) best regards, Florian La Roche From rhelv6-list at redhat.com Fri Feb 22 12:35:29 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 13:35:29 +0100 Subject: [rhelv6-list] rhel6.4 kernel breaks server hardware vendor mgmt tools In-Reply-To: <20130222114759.0fb07bc4@r2d2.marmotte.net> (Red Hat Enterprise Linux's message of "Fri, 22 Feb 2013 11:47:59 +0100") References: <15tehg9e4m3.fsf@tux.uio.no> <20130222114759.0fb07bc4@r2d2.marmotte.net> Message-ID: <15tvc9kbk6m.fsf@tux.uio.no> "Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list" writes: >> The decision to statically link the IPMI kernel modules in rhel6.4 >> breaks various vendor hardware management tools. So far I've confirmed >> that Dell Openmanage Server Administrator (OMSA) and HP Proliant >> support pack depend on those modules being standalone like before. >> These tools don't work with the 6.4 kernel. >> >> It's probably just the init scripts for the services that need to be >> fixed in order to work with statically linked IPMI modules, but out of >> the box these services are broken. >> >> Just a heads-up for anyone planning to upgrade their physical servers >> to rhel6.4. > > FWIW, I've had no problem using Dell's CLI update_firmware after > updating to RHEL 6.4, and that's part of OMSA. I did notice that > the ipmi_si and ipmi_msghandler modules were no longer there (since I > typically try to manually load them), but bootstrap_firmware, > inventory_firwmare and update_firmware all worked fine. > > This was a PE2950 on which I updated the main BIOS, the PERC6/i, the > Broadcom NICs and the Seagate SAS disks. > > Maybe you were referring to some other parts of OMSA, in which case I'd > be interested in knowing which. Yes, I would expect some parts of OMSA to continue working, and update_firmware seems to not be affected. I'm referring to the parts of OMSA that communicates with the hardware for management and monitoring purposes. E.g. on a rhel6.3 server the following commands work as expected: # omreport chassis Health Main System Chassis SEVERITY : COMPONENT Ok : Fans Ok : Intrusion Ok : Memory Ok : Power Supplies Ok : Power Management Ok : Processors Ok : Temperatures Ok : Voltages Ok : Hardware Log Ok : Batteries # omreport storage controller Controller PERC H700 Integrated (Embedded) Controllers ID : 0 Status : Ok [...etc...] While on rhel6.4: # omreport chassis Health # omreport storage controller No controllers found If you try restarting the srvadmin services, you'll see that the IPMI stuff fails to start: # srvadmin-services.sh restart Shutting down DSM SA Shared Services: [ OK ] Shutting down DSM SA Connection Service: [ OK ] Stopping Systems Management Data Engine: Stopping dsm_sa_snmpd: Not started [FAILED] Stopping dsm_sa_eventmgrd: Not started [FAILED] Stopping dsm_sa_datamgrd: Not started [FAILED] Stopping Systems Management Device Drivers: Stopping dell_rbu: [ OK ] Starting Systems Management Device Drivers: Starting dell_rbu: [ OK ] Starting ipmi driver: [FAILED] Starting Systems Management Device Drivers: Starting dell_rbu: Already started [ OK ] Starting ipmi driver: [FAILED] Starting DSM SA Shared Services: [ OK ] Starting DSM SA Connection Service: [ OK ] Regards, -- Trond H. Amundsen Center for Information Technology Services, University of Oslo From rhelv6-list at redhat.com Fri Feb 22 16:42:44 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 09:42:44 -0700 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: Message-ID: <5127A004.8010508@rincon.com> On 02/21/13 11:08, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Hi all, > > Just did my first update of RHEL6.4 and experienced a very painful issue with udev renaming > ethernet devices. Unfortunately, I did not capture the initial udev ethernet rules prior to the > reboot. My system has an onboard NIC and a PCIE card. > > 01:00.0 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) > 01:00.1 Ethernet controller: Broadcom Corporation NetXtreme II BCM5709 Gigabit Ethernet (rev 20) > 03:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5754 Gigabit Ethernet PCI Express > (rev 02) > > With RHEL6.3, I had > eth0 <-- motherboard NIC > p1p1 <-- port 0 of PCIE card > p1p2 <-- port 1 of PCIE card > > I rebooted and this came to the messages: > > Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth2 to rename4 > Feb 21 10:34:59 d0 kernel: udev: renamed network interface eth0 to eth2 > Feb 21 10:34:59 d0 kernel: udev: renamed network interface rename4 to eth0 > > I needed up with > eth1 <-- port 1 of the PCIE card > eth2 <-- port 0 of the PCIE card > > I repaired my /etc/sysconfig/network-scripts/ifcfg-* files and rebooted again and now got this: > > Feb 21 11:47:48 d0 kernel: udev: renamed network interface eth1 to eth2 > > and the order is a bit different again! Anybody else having issues like I am? Are the pXpX names > no longer being used? > > thanks, > daryl > Reading through the RHEL 6.4 tech notes, stumbled across this in Chapter 4.1 (known issues): kernel component Recent Red Hat Enterprise Linux 6 releases use a new naming scheme for network interfaces on some machines. As a result, the installer may use different names during an upgrade in certain scenarios (typically em 1 is used instead of eth0 on new Dell machines). However, the previously used network interface names are preserved on the system and the upgraded system will still use the previously used interfaces. This is not the case for Yum upgrades. .. so using the install media to upgrade preserves device names, but on *some* machines upgrading using yum will clobber device names. Known issue, but no bugzilla entry cited. It would have been nice if they pointed to a more detailed description of how & when this happens. Good luck, -Bob Arendt From rhelv6-list at redhat.com Fri Feb 22 17:01:26 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 12:01:26 -0500 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: <5127A004.8010508@rincon.com> References: <5127A004.8010508@rincon.com> Message-ID: Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Reading through the RHEL 6.4 tech notes, stumbled across this in > Chapter 4.1 (known issues): > > kernel component > Recent Red Hat Enterprise Linux 6 releases use a new naming scheme for > network interfaces on some machines. As a result, the installer may > use different names during an upgrade in certain scenarios (typically > em 1 is used instead of eth0 on new Dell machines). However, > the previously used network interface names are preserved on the > system and the upgraded system will still use the previously used > interfaces. This is not the case for Yum upgrades. I looked through the notes, but missed it, especially that last statement ... "This is not the case for Yum upgrades" Which was preceded by ... "the previously used network interface names are preserved on the system and the upgraded system will still use the previously used interfaces." > .. so using the install media to upgrade preserves device names, but on > *some* machines upgrading using yum will clobber device names. To put it technically (if I'm understanding this correctly) ... - Anaconda (off-line upgrade) is preserving the names - YUM (on-line upgrade) is not, at least for some OEM hardware > Known issue, but no bugzilla entry cited. I'm going to look up the "biosdevname" and related package BZs and get the full story, if there is one. I know upstream Fedora switched to the new nomenclature awhile back (and "biodevname" does seem to be installed on all of my Fedora systems). But as I mentioned before, RHEL6 does not, and I'm ignorant of the logic whenever it may (Customer opt-in? Anaconda detection of select OEM hardware? Other?). Precision (expected results) is what I'm looking to explain, at least for myself. > It would have been nice if they pointed to a more detailed description > of how & when this happens. Well, the OEMs and their BIOSes are involved here. There is likely a bigger story to this. I also use Cobbler, although I'd be interested to know if that is causing any deployment issues for those leveraging biosdevname (since I have not been). Again, my prior ignorance, I thought it wasn't going to be enabled (at least by default) until RHEL7, as I had never seen it on 6.2 or 6.3 with many bare metal solutions, including IBM Blades. But I haven't had brought hardware exposure as of late, and definitely not Dell in any recent years. In fact, that's entirely why I read the OP information incorrectly (i.e., I thought they switched to the biosdevnames, when it was they switched back from the biosdevnames after upgrading to 6.4). -- bjs P.S. This will be my last post on-list. I will just respond to just those who inquire off-list. From rhelv6-list at redhat.com Fri Feb 22 22:41:07 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 23:41:07 +0100 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: <5127A004.8010508@rincon.com> Message-ID: On Fri, Feb 22, 2013 at 6:01 PM, bjs wrote: > I'm going to look up the "biosdevname" and related package BZs and get > the full story, if there is one. > > I know upstream Fedora switched to the new nomenclature awhile back > (and "biodevname" does seem to be installed on all of my Fedora > systems). But as I mentioned before, RHEL6 does not, and I'm ignorant > of the logic whenever it may (Customer opt-in? Anaconda detection of > select OEM hardware? Other?). It's definitely customer opt-in . The RHEL 6.1 release notes say : https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.1_Release_Notes/index.html#idp82636784 Red Hat Enterprise Linux 6.1 introduces biosdevname, an optional convention for naming network interfaces. biosdevname assigns names to network interfaces based on their physical location. Note, however that biosdevname is disabled by default, except for a limited set of Dell systems. HTH -- Fran Garcia From rhelv6-list at redhat.com Fri Feb 22 22:59:14 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Fri, 22 Feb 2013 16:59:14 -0600 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: <5127A004.8010508@rincon.com> Message-ID: On Fri, Feb 22, 2013 at 4:41 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On Fri, Feb 22, 2013 at 6:01 PM, bjs wrote: > > I'm going to look up the "biosdevname" and related package BZs and get > > the full story, if there is one. > > > > I know upstream Fedora switched to the new nomenclature awhile back > > (and "biodevname" does seem to be installed on all of my Fedora > > systems). But as I mentioned before, RHEL6 does not, and I'm ignorant > > of the logic whenever it may (Customer opt-in? Anaconda detection of > > select OEM hardware? Other?). > > It's definitely customer opt-in . The RHEL 6.1 release notes say : > > > https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/6.1_Release_Notes/index.html#idp82636784 > > Red Hat Enterprise Linux 6.1 introduces biosdevname, an optional > convention for naming network interfaces. biosdevname assigns names to > network interfaces based on their physical location. Note, however > that biosdevname is disabled by default, except for a limited set of > Dell systems. > > Thanks all for the responses. I definitely did not manually install this package. It may have come in with OMSA or something else I installed. I missed the 'yum update' note in the technical release notes that somebody else posted, sigh. I did another system with em1 and em2 devices and no udev net-rules file and it rebooted just fine, puzzling. daryl -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Mon Feb 25 08:50:38 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 08:50:38 +0000 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <20130221191633.29235c9f@gmail.com> References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> <20130221191633.29235c9f@gmail.com> Message-ID: On 21 February 2013 18:16, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > On Thu, 21 Feb 2013 11:38:33 -0500, Red Hat Enterprise Linux 6 > \(Santiago\) discussion mailing-list wrote: > > > There were several "bots" on the RH list, harvesting e-mail addresses > > from senders to the list, and then sending rather inappropriate pictures > > to those senders on the list from a huge inventory of e-mail addresses. > > I believe that RH made the change at that time in order to stop this > > behavior. I know because I received those messages for quite some time! > > That may work, but *your* address is still in the "Received" headers, jas@ > ... > so a more clever bot would still get your address from there. > > I've had addresses harvested from all over the place, not just the From: header. The more amusing ones are MIME boundaries and message-ids. I notice that the list is still marking everything as from itself rather than the author and with the announcement of 6.4 this has changed from a "meh" to a real annoyance. Can we have the normal behaviour back please and let the harvesters get on with culling messages from the archives like they always do. jch -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Mon Feb 25 09:02:57 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 01:02:57 -0800 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> <20130221191633.29235c9f@gmail.com> Message-ID: On Mon, Feb 25, 2013 at 12:50 AM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > > > > On 21 February 2013 18:16, Red Hat Enterprise Linux 6 (Santiago) discussion > mailing-list wrote: >> >> On Thu, 21 Feb 2013 11:38:33 -0500, Red Hat Enterprise Linux 6 >> \(Santiago\) discussion mailing-list wrote: >> >> > There were several "bots" on the RH list, harvesting e-mail addresses >> > from senders to the list, and then sending rather inappropriate pictures >> > to those senders on the list from a huge inventory of e-mail addresses. >> > I believe that RH made the change at that time in order to stop this >> > behavior. I know because I received those messages for quite some time! >> >> That may work, but *your* address is still in the "Received" headers, >> jas at ... >> so a more clever bot would still get your address from there. >> > > > I've had addresses harvested from all over the place, not just the From: > header. The more amusing ones are MIME boundaries and message-ids. > > I notice that the list is still marking everything as from itself rather > than the author and with the announcement of 6.4 this has changed from a > "meh" to a real annoyance. > > Can we have the normal behaviour back please and let the harvesters get on > with culling messages from the archives like they always do. > > jch I totally agree. Right now, I have no idea who is posting, and there is no way to respond to the poster personally when that is a desirable action. (no name here) From rhelv6-list at redhat.com Mon Feb 25 10:44:07 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 11:44:07 +0100 Subject: [rhelv6-list] rhel6.4 kernel breaks server hardware vendor mgmt tools In-Reply-To: <15tehg9e4m3.fsf@tux.uio.no> References: <15tehg9e4m3.fsf@tux.uio.no> Message-ID: <512B4077.10700@gmx.de> Am 21.02.2013 22:31, schrieb Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list: > > Hi all, > > The decision to statically link the IPMI kernel modules in rhel6.4 > breaks various vendor hardware management tools. So far I've confirmed > that Dell Openmanage Server Administrator (OMSA) and HP Proliant support > pack depend on those modules being standalone like before. These tools > don't work with the 6.4 kernel. > > It's probably just the init scripts for the services that need to be > fixed in order to work with statically linked IPMI modules, but out of > the box these services are broken. Have you had the chance to take a look at the OMSA stuff? If it is really only the init script? Thx Rainer From rhelv6-list at redhat.com Mon Feb 25 13:17:08 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 08:17:08 -0500 Subject: [rhelv6-list] rhel6.4 kernel breaks server hardware vendor mgmt tools In-Reply-To: <512B4077.10700@gmx.de> References: <15tehg9e4m3.fsf@tux.uio.no> <512B4077.10700@gmx.de> Message-ID: <20130225131708.GA21296@sws1.ornl.gov> On Mon, Feb 25, 2013 at 11:44:07AM +0100, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > Am 21.02.2013 22:31, schrieb Red Hat Enterprise Linux 6 (Santiago) > discussion mailing-list: > > > >Hi all, > > > >The decision to statically link the IPMI kernel modules in rhel6.4 > >breaks various vendor hardware management tools. So far I've confirmed > >that Dell Openmanage Server Administrator (OMSA) and HP Proliant support > >pack depend on those modules being standalone like before. These tools > >don't work with the 6.4 kernel. > > > >It's probably just the init scripts for the services that need to be > >fixed in order to work with statically linked IPMI modules, but out of > >the box these services are broken. > > Have you had the chance to take a look at the OMSA stuff? > If it is really only the init script? > > Thx > Rainer Try the following to get OMSA working: yum install OpenIPMI chkconfig ipmi on service ipmi start /opt/dell/srvadmin/sbin/srvadmin-services.sh restart That also got OMSA working on a PowerEdge C2100 with OMSA 7.1.0. Without OpenIMPI the C2100 had the same symptoms (no hardware/storage info in OMSA). Jim From rhelv6-list at redhat.com Mon Feb 25 13:54:54 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 07:54:54 -0600 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> <20130221191633.29235c9f@gmail.com> Message-ID: <201302251354.r1PDssoC001606@particle.nhn.ou.edu> Hi all, > >> > There were several "bots" on the RH list, harvesting e-mail addresses > >> > from senders to the list, and then sending rather inappropriate pictures > >> > to those senders on the list from a huge inventory of e-mail addresses. > >> > I believe that RH made the change at that time in order to stop this > >> > behavior. I know because I received those messages for quite some time! > >> > >> That may work, but *your* address is still in the "Received" headers, > >> jas at ... > >> so a more clever bot would still get your address from there. I don't think that's the case, since as far as I understand, your email address only appears in the email that was actually sent to you, so I don't think that bots will ever see that -- unless your account is already hacked and a bot is going through your email, or unless the email you received gets posted with full headers somewhere, which I don't think should normally happen. That said, though, see below ... > > I've had addresses harvested from all over the place, not just the From: > > header. The more amusing ones are MIME boundaries and message-ids. > > > > I notice that the list is still marking everything as from itself rather > > than the author and with the announcement of 6.4 this has changed from a > > "meh" to a real annoyance. > > > > Can we have the normal behaviour back please and let the harvesters get on > > with culling messages from the archives like they always do. > > > > jch > > I totally agree. Right now, I have no idea who is posting, and there > is no way to respond to the poster personally when that is a desirable > action. > > (no name here) I also agree that it would be much more useful to know who's posting what. I've had this email address -- which you can't see :) -- for over 15 years now, so it's pointless to try to hide it from people now. My 2c, Horst From rhelv6-list at redhat.com Mon Feb 25 14:58:36 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 15:58:36 +0100 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <201302251354.r1PDssoC001606@particle.nhn.ou.edu> References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> <20130221191633.29235c9f@gmail.com> <201302251354.r1PDssoC001606@particle.nhn.ou.edu> Message-ID: <20130225155836.4207a584@gmail.com> On Mon, 25 Feb 2013 07:54:54 -0600, Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list wrote: > > >> That may work, but *your* address is still in the "Received" headers, > > >> jas at ... > > >> so a more clever bot would still get your address from there. > > I don't think that's the case, since as far as I understand, your > email address only appears in the email that was actually sent to you, Then I suggest you check out the headers of the message I had replied to. ;) Here, I only modified the domains a bit: Received: from [130.63.97.125] (ident=jas) by bronze.cs.yorku.ca with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.76) (envelope-from ) id 1U8ZAH-0004tO-Fn for rhelv6-list at redhat.com.invalid; Thu, 21 Feb 2013 11:38:33 -0500 And yes, that doesn't apply to every mail and every user. From rhelv6-list at redhat.com Mon Feb 25 15:23:50 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 09:23:50 -0600 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <20130225155836.4207a584@gmail.com> References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> <20130221191633.29235c9f@gmail.com> <201302251354.r1PDssoC001606@particle.nhn.ou.edu> <20130225155836.4207a584@gmail.com> Message-ID: <201302251523.r1PFNocQ004098@particle.nhn.ou.edu> Hi again, > > > >> That may work, but *your* address is still in the "Received" headers, > > > >> jas at ... > > > >> so a more clever bot would still get your address from there. > > > > I don't think that's the case, since as far as I understand, your > > email address only appears in the email that was actually sent to you, > > Then I suggest you check out the headers of the message I had replied to. ;) > Here, I only modified the domains a bit: > > Received: from [130.63.97.125] (ident=jas) > by bronze.cs.yorku.ca with esmtpsa (TLSv1:CAMELLIA256-SHA:256) > (Exim 4.76) (envelope-from ) id 1U8ZAH-0004tO-Fn > for rhelv6-list at redhat.com.invalid; Thu, 21 Feb 2013 11:38:33 -0500 > > And yes, that doesn't apply to every mail and every user. Interesting. I looked through all the recent emails I got, and I didn't find a single one which had an email address in the headers or envelope. A few domains in the Reference sections, but no complete email address. Maybe that depends on the receiving mail server ...? Either way, I'm not trying to argue FOR this anonymizing of the posts, I'm arguing AGAINST it. :) Cheers, Horst From rhelv6-list at redhat.com Mon Feb 25 20:28:50 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 21:28:50 +0100 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <201302251523.r1PFNocQ004098@particle.nhn.ou.edu> References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> <20130221191633.29235c9f@gmail.com> <201302251354.r1PDssoC001606@particle.nhn.ou.edu> <20130225155836.4207a584@gmail.com> <201302251523.r1PFNocQ004098@particle.nhn.ou.edu> Message-ID: <20130225212850.758cab14@gmail.com> On Mon, 25 Feb 2013 09:23:50 -0600, Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list wrote: > Interesting. I looked through all the recent emails I got, > and I didn't find a single one which had an email address in the headers > or envelope. A few domains in the Reference sections, but no complete > email address. Maybe that depends on the receiving mail server ...? No, the sending one advertizes it: $ wget https://www.redhat.com/archives/rhelv6-list/2013-February.txt.gz $ zgrep envelope-from 2013-February.txt.gz ... :-p > Either way, I'm not trying to argue FOR this anonymizing of the posts, > I'm arguing AGAINST it. :) Of course. From rhelv6-list at redhat.com Mon Feb 25 21:08:55 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Mon, 25 Feb 2013 15:08:55 -0600 Subject: [rhelv6-list] RH lists munging From: header In-Reply-To: <20130225212850.758cab14@gmail.com> References: <20130221162237.GA12934@hiwaay.net> <51264D89.4060804@cse.yorku.ca> <20130221191633.29235c9f@gmail.com> <201302251354.r1PDssoC001606@particle.nhn.ou.edu> <20130225155836.4207a584@gmail.com> <201302251523.r1PFNocQ004098@particle.nhn.ou.edu> <20130225212850.758cab14@gmail.com> Message-ID: <201302252108.r1PL8taD004945@particle.nhn.ou.edu> Wait -- looking at that archive text file, https://www.redhat.com/archives/rhelv6-list/2013-February.txt.gz I see the email addresses of EVERY SINGLE poster in plain text in the first line of each email entry: >From mschwendt at gmail.com Mon Feb 25 15:36:38 2013 So if some bot would like to harvest email addresses, they don't need to subscribe to this list and look for the small fraction of 'envelope-from' email addresses, they can simply download this file and get them all! So I really think we should stop discussing this now, and just change these lists back so that we can see who is sending what, without having to do the above ourselves ... ;) Cheers, Horst "Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list" wrote: > On Mon, 25 Feb 2013 09:23:50 -0600, Red Hat Enterprise Linux 6 \(Santiago\) discussion mailing-list wrote: > > > Interesting. I looked through all the recent emails I got, > > and I didn't find a single one which had an email address in the headers > > or envelope. A few domains in the Reference sections, but no complete > > email address. Maybe that depends on the receiving mail server ...? > > No, the sending one advertizes it: > > $ wget https://www.redhat.com/archives/rhelv6-list/2013-February.txt.gz > $ zgrep envelope-from 2013-February.txt.gz > ... > > :-p > > > Either way, I'm not trying to argue FOR this anonymizing of the posts, > > I'm arguing AGAINST it. :) > > Of course. > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list From rhelv6-list at redhat.com Wed Feb 27 19:05:20 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Wed, 27 Feb 2013 14:05:20 -0500 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: References: Message-ID: <512E58F0.5090902@pari.edu> On 02/21/2013 01:18 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > The Dell (among other IHV) implemented em?, p?p?, etc... nomenclature > should still be upstream-only, and not seen until RHEL7. Is this a > Dell server? Are you running any (possibly updated?) IHV packages, > even if not Dell On a Dell Precision M65 laptop here, running CentOS 6.3 (kernel 2.6.32-279.22.1.el6.x86_64): [lowen at dhcp-pool146 ~]$ ifconfig eth0 Link encap:Ethernet HWaddr xxxxxxxxxxxxxxxxxx inet6 addr: xxxxxxxxxx/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:1049 TX packets:0 errors:6 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:17 Base address:0xc000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:18 errors:0 dropped:0 overruns:0 frame:0 TX packets:18 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1060 (1.0 KiB) TX bytes:1060 (1.0 KiB) p4p1 Link encap:Ethernet HWaddr 00:15:C5:XX:XX:XX inet addr:192.168.1.146 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: xxxxxxxxxxxxxxx/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:80601 errors:0 dropped:0 overruns:0 frame:0 TX packets:44526 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:56461092 (53.8 MiB) TX bytes:5885252 (5.6 MiB) Interrupt:18 virbr0 Link encap:Ethernet HWaddr 52:54:00:XX:XX:XX inet addr:192.168.122.1 Bcast:192.168.122.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:27 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:4652 (4.5 KiB) [lowen at dhcp-pool146 ~]$ eth0 is the BCM4321 _WIRELESS_ card; p4p1 is: 09:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5752 Gigabit Ethernet PCI Express (rev 02) And while I know this is CentOS, not RHEL, it should act the same being built from the same sources; it's been this way since the initial 6.3 release kernel (2.6.32-279.el6.x86_64). Now, I do have an RHEL 6.x box, and I'm getting ready to file a bugzilla with it, since the 358.el6.i686 (and the quick-released 358.0.1.el6.i686) kernels panic on boot, but the 279.22.1 kernel does not. That's a Supermicro dual Xeon board, an oldie but a goodie P4DP6 with 32-bit 2.8GHz Xeons. But that's a separate issue.... From rhelv6-list at redhat.com Wed Feb 27 19:46:15 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Wed, 27 Feb 2013 20:46:15 +0100 Subject: [rhelv6-list] Red Hat Developer Toolset for Workstation? Message-ID: Hello. I'm using Red Hat Enterprise Linux 6.4 Workstation. Recently I found out that Red Hat provides newer development tools through Red Hat Developer Toolset. I purchased a subscription to Red Hat Enterprise Linux Developer Suite. I can successfully add the subscription to my workstation but when I enable the repositories only the debug symbols are available. There are zero packages available in rhel-workstation-dts-6-rpms. The developer suite included a development subscription for RHEL server. Just out of curiosity I installed it and then I could also install the developer tools there. But I would like to use the developer tools on Workstation. Have I purchased the wrong subscription? Is there any way to install Red Hat Developer Toolset on RHEL Workstation? John -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Thu Feb 28 00:45:22 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Wed, 27 Feb 2013 19:45:22 -0500 Subject: [rhelv6-list] RHEL 6.4 udev just butchered my ethernet device names! In-Reply-To: <512E58F0.5090902@pari.edu> References: <512E58F0.5090902@pari.edu> Message-ID: On Wed, Feb 27, 2013 at 2:05 PM, Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list wrote: > And while I know this is CentOS, not RHEL, it should act the same being > built from the same sources; > it's been this way since the initial 6.3 release kernel > (2.6.32-279.el6.x86_64). > As someone corrected me, while it is still not the default, as of 6.1, use of the package "biosdevname" (which some, very select IHVs install and/or mark as a dependency) will change it. I.e., Dell But as far as I know, the default does not change for all systems until the next released, based on upstream changes. -- bjs -------------- next part -------------- An HTML attachment was scrubbed... URL: From rhelv6-list at redhat.com Thu Feb 28 21:56:44 2013 From: rhelv6-list at redhat.com (Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list) Date: Thu, 28 Feb 2013 21:56:44 +0000 Subject: [rhelv6-list] Status of nouveau 3d support Message-ID: Is there a timeline for enabling GNOME desktop effects with the nouveau driver? My fully updated RHEL 6.4 system still doesn't allow that. I'd prefer to use the open-source drivers included with the distribution than having to maintain a separate set of packages for the proprietary drivers. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: