From bdwheele at indiana.edu Mon Jun 3 14:02:52 2013 From: bdwheele at indiana.edu (Brian Wheeler) Date: Mon, 03 Jun 2013 10:02:52 -0400 Subject: [rhelv6-list] RHEL7 Beta? Message-ID: <51ACA20C.8010609@indiana.edu> I know the answer is "it will be released when its ready" but does anyone have any insight on a release time frame for the RHEL7 beta? All of the stuff I've seen online says 1H13, but I was wondering if that was still true (since we're running out of 1H!), or if the F18 delays pushed it back some. Brian From mike at linuxexam.com Tue Jun 4 00:58:15 2013 From: mike at linuxexam.com (MJang) Date: Mon, 03 Jun 2013 17:58:15 -0700 Subject: [rhelv6-list] RHEL7 Beta? In-Reply-To: <51ACA20C.8010609@indiana.edu> References: <51ACA20C.8010609@indiana.edu> Message-ID: <1370307495.3770.20.camel@kauai> On Mon, 2013-06-03 at 10:02 -0400, Brian Wheeler wrote: > I know the answer is "it will be released when its ready" but does > anyone have any insight on a release time frame for the RHEL7 beta? All > of the stuff I've seen online says 1H13, but I was wondering if that was > still true (since we're running out of 1H!), or if the F18 delays pushed > it back some. My original understanding, based on what came out of the Red Hat summit in '12, is the same as yours, which suggested that RHEL 7 would be based on F18. Wild guess -- the basis for RHEL 7 was affected by the problems around F18. I note Alan Cox's negative review of that release, ref https://plus.google.com/111104121194250082892/posts/aCiB7kTLXTh . i.e., I'm guessing that led to some reassessment within Red Hat. It's easy to find bugzillas related to RHEL 7 alpha, which suggests (to me) that Red Hat might want to base RHEL 7 on F19. Vague memories, something similar happened in the F12/F13 timeframe, before RHEL 6 beta. That suggests a RHEL 7 release sometime in Q1 2014. Thanks, Mike From dsavage at peaknet.net Tue Jun 4 01:24:05 2013 From: dsavage at peaknet.net (Robert G. (Doc) Savage) Date: Mon, 03 Jun 2013 20:24:05 -0500 Subject: [rhelv6-list] RHEL7 Beta? In-Reply-To: <1370307495.3770.20.camel@kauai> References: <51ACA20C.8010609@indiana.edu> <1370307495.3770.20.camel@kauai> Message-ID: <1370309045.21747.134.camel@lion.protogeek.org> On Mon, 2013-06-03 at 17:58 -0700, MJang wrote: > On Mon, 2013-06-03 at 10:02 -0400, Brian Wheeler wrote: > > I know the answer is "it will be released when its ready" but does > > anyone have any insight on a release time frame for the RHEL7 beta? All > > of the stuff I've seen online says 1H13, but I was wondering if that was > > still true (since we're running out of 1H!), or if the F18 delays pushed > > it back some. > > My original understanding, based on what came out of the Red Hat summit > in '12, is the same as yours, which suggested that RHEL 7 would be based > on F18. > > Wild guess -- the basis for RHEL 7 was affected by the problems around > F18. I note Alan Cox's negative review of that release, ref > https://plus.google.com/111104121194250082892/posts/aCiB7kTLXTh . > > i.e., I'm guessing that led to some reassessment within Red Hat. It's > easy to find bugzillas related to RHEL 7 alpha, which suggests (to me) > that Red Hat might want to base RHEL 7 on F19. Certainly the graphical anaconda installer from F19. Much improved over the first attempt. --Doc Savage Fairview Heights IL From b.j.smith at ieee.org Tue Jun 4 01:30:58 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Mon, 3 Jun 2013 21:30:58 -0400 Subject: [rhelv6-list] RHEL7 Beta? In-Reply-To: <1370307495.3770.20.camel@kauai> References: <51ACA20C.8010609@indiana.edu> <1370307495.3770.20.camel@kauai> Message-ID: Instead of speculating ... Red Hat will be directly addressing the Enterprise Linux roadmap at Summit next week, specifically the Wednesday, June 12th afternoon sessions. [1] If any and all past Summit roadmap sessions are of any consideration, Red Hat is always forward and open with details in on-going developments. Consider coming to Summit to directly ask questions. Otherwise, if any and all past Summit roadmaps are of any consideration, the presentations and videos of the event are usually available shortly after. Additionally, your Red Hat representative(s) are often your best avenue for assistance when it comes to planning and strategy for forthcoming Red Hat releases. Just FYI ... given the exact and relevant Summit session [1] has been posted publicly. ;) -- bjs [1] http://www.redhat.com/summit/sessions/topics/red-hat-enterprise-linux.html#138 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdwheele at indiana.edu Tue Jun 4 01:37:34 2013 From: bdwheele at indiana.edu (Brian Wheeler) Date: Mon, 03 Jun 2013 21:37:34 -0400 Subject: [rhelv6-list] RHEL7 Beta? In-Reply-To: References: <51ACA20C.8010609@indiana.edu> <1370307495.3770.20.camel@kauai> Message-ID: <51AD44DE.4080609@indiana.edu> Heh, I forgot that was coming up...looks like there will be updated information soon :) On 06/03/2013 09:30 PM, Bryan J Smith wrote: > Instead of speculating ... > > Red Hat will be directly addressing the Enterprise Linux roadmap at > Summit next week, specifically the Wednesday, June 12th afternoon > sessions. [1] > > If any and all past Summit roadmap sessions are of any consideration, > Red Hat is always forward and open with details in on-going > developments. Consider coming to Summit to directly ask questions. > Otherwise, if any and all past Summit roadmaps are of any > consideration, the presentations and videos of the event are usually > available shortly after. > > Additionally, your Red Hat representative(s) are often your best > avenue for assistance when it comes to planning and strategy for > forthcoming Red Hat releases. > > Just FYI ... given the exact and relevant Summit session [1] has been > posted publicly. ;) > > -- bjs > > [1] > http://www.redhat.com/summit/sessions/topics/red-hat-enterprise-linux.html#138 > > > > > _______________________________________________ > 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 leonfauster at googlemail.com Tue Jun 4 08:35:20 2013 From: leonfauster at googlemail.com (Leon Fauster) Date: Tue, 4 Jun 2013 10:35:20 +0200 Subject: [rhelv6-list] RHEL7 Beta? In-Reply-To: <1370307495.3770.20.camel@kauai> References: <51ACA20C.8010609@indiana.edu> <1370307495.3770.20.camel@kauai> Message-ID: <0E704093-84CC-4FE7-A6E5-4F616BFB4430@googlemail.com> Am 04.06.2013 um 02:58 schrieb MJang : > On Mon, 2013-06-03 at 10:02 -0400, Brian Wheeler wrote: >> I know the answer is "it will be released when its ready" but does >> anyone have any insight on a release time frame for the RHEL7 beta? All >> of the stuff I've seen online says 1H13, but I was wondering if that was >> still true (since we're running out of 1H!), or if the F18 delays pushed >> it back some. > > My original understanding, based on what came out of the Red Hat summit > in '12, is the same as yours, which suggested that RHEL 7 would be based > on F18. > > Wild guess -- the basis for RHEL 7 was affected by the problems around > F18. I note Alan Cox's negative review of that release, ref > https://plus.google.com/111104121194250082892/posts/aCiB7kTLXTh . > > i.e., I'm guessing that led to some reassessment within Red Hat. It's > easy to find bugzillas related to RHEL 7 alpha, which suggests (to me) > that Red Hat might want to base RHEL 7 on F19. > > Vague memories, something similar happened in the F12/F13 timeframe, > before RHEL 6 beta. > > That suggests a RHEL 7 release sometime in Q1 2014. Here an overview of the actual releases: http://fedoraproject.org/wiki/Red_Hat_Enterprise_Linux#History -- LF From clydekunkel7734 at verizon.net Tue Jun 4 19:59:02 2013 From: clydekunkel7734 at verizon.net (Clyde E. Kunkel) Date: Tue, 04 Jun 2013 15:59:02 -0400 Subject: [rhelv6-list] RHEL7 Beta? In-Reply-To: <51ACA20C.8010609@indiana.edu> References: <51ACA20C.8010609@indiana.edu> Message-ID: <51AE4706.1070308@verizon.net> On 06/03/2013 10:02 AM, Brian Wheeler wrote: > I know the answer is "it will be released when its ready" but does > anyone have any insight on a release time frame for the RHEL7 beta? All > of the stuff I've seen online says 1H13, but I was wondering if that was > still true (since we're running out of 1H!), or if the F18 delays pushed > it back some. > > https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-June/004404.html -- Regards, OldFart From eng-partner-management at redhat.com Wed Jun 5 21:38:31 2013 From: eng-partner-management at redhat.com (Engineering Partner Management) Date: Wed, 05 Jun 2013 17:38:31 -0400 Subject: [rhelv6-list] Red Hat Software Collections 1.0 Beta Now Available for Testing Message-ID: <51AFAFD7.9070101@redhat.com> Red Hat is pleased to announce the Beta release of Red Hat Software Collections 1.0. Red Hat Software Collections 1.0 delivers the latest, stable versions of some of the most popular web development languages and open source databases for use with Red Hat Enterprise Linux. It features a three-year life cycle and is the first in a series of planned releases designed to allow developers to take advantage of new capabilities faster as they build and deploy modern, enterprise-ready web applications. The success of today?s enterprise is dependent upon developers? ability to remain agile, flexible and ready to incorporate new technologies, even as they take on additional responsibilities as new roles like DevOps emerge and evolve. With Red Hat Software Collections, developers can build and deploy applications on Red Hat Enterprise Linux with the confidence that their efforts will be backed by long-term support. In addition, Red Hat plans a frequent release cadence for Red Hat Software Collections, providing developers with updated runtime components on which they can create new features and capabilities. Red Hat Software Collections 1.0 Beta includes access to the latest stable versions of the following dynamic languages: * Ruby 1.9.3 with Rails 3.2.8, which delivers substantial performance improvements for web-based applications. This results in faster load times, improved unicode support and threading, and a large collection of ruby gems. * Python version 2.7, which includes new unit test features, faster I/O, and tools and back-ported features from Python 3 to make future migration easier. * Python version 3.3, which offers significant improvements in language consistency, Unicode performance, imports, and distribution of packages. * PHP version 5.4, which includes new language syntax, improved performance and reduced memory consumption, and a built-in web server in CLI mode to simplify development workflows and testing. * Perl version 5.16.3, which includes improved unicode support, performance enhancements, new debugging options, enhanced security, and a number of new and updated modules. * Technology Preview of node.js version 0.10, which delivers an easy to use module for handling streams, better error handling with domains, and performance improvements for web application development. Red Hat Software Collections 1.0 Beta also includes access to the latest stable versions of the following runtime databases: * MariaDB version 5.5, which introduces an easy-to-adopt alternative for MySQL for Red Hat Enterprise Linux users. Binary compatibility allows MySQL users to drop-in MariaDB without converting data files. * MySQL version 5.5, which offers performance, scalability, and usability enhancements. * PostgreSQL version 9.2, which includes native JSON support, covering indexes, and significant improvements in replication, high availability and performance. RED HAT SOFTWARE COLLECTIONS 1.0 BETA AVAILABILITY Red Hat Software Collections 1.0 Beta is available now for use with Red Hat Enterprise Linux 6 to customers and partners with select active Red Hat Enterprise Linux Server, Red Hat Enterprise Linux Workstation or developer-related subscriptions. Follow this link to find the Red Hat Software Collections channels: https://www.redhat.com/wapps/sso/login.html?redirect=https%3A%2F%2Frhn.redhat.com%2Frhn%2Fsoftware%2Fchannels%2FBeta.do PARTICIPATING IN THE RED HAT SOFTWARE COLLECTIONS 1.0 BETA Active subscribers who are interested in participating can access Red Hat Software Collections 1.0 Beta on Red Hat Network (http://rhn.redhat.com). View the Red Hat Software Collections 1.0 Beta release notes (https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1-Beta/html/1.0_Release_Notes/index.html) for more information. ADDITIONAL RESOURCES To access documentation for Red Hat Developer Toolset (requires login), visit: * Latest Red Hat Software Collections release notes: https://access.redhat.com/site/documentation/en-US/Red_Hat_Software_Collections/1-Beta/html/1.0_Release_Notes/index.html * Red Hat Enterprise Linux Developer Guide: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Developer_Guide/index.html * Red Hat Enterprise Linux documentation: https://access.redhat.com/knowledge/docs/Red_Hat_Enterprise_Linux/ Sincerely, The Red Hat Enterprise Linux Team From colin.coe at gmail.com Thu Jun 13 00:25:48 2013 From: colin.coe at gmail.com (Colin Coe) Date: Thu, 13 Jun 2013 08:25:48 +0800 Subject: [rhelv6-list] Using mrepo to mirror RHN Classic Message-ID: Hi all I've been using mrepo to mirror a few channels out of RHN Classic for a while. Now I hev the requirement to get package group info (think comps.xml) as well. I've googled and tried various things to make this happen without any success. I see that createrepo has a '-g' flag but I've no idea how to get mrepo to pass the '*comps*.xml' filename to createrepo correctly. Is anyone successfully mirroring RHN Classic with mrepo and getting the package group info? If so, could you post a sanitised version of your mrepo config? Thanks CC -- RHCE#805007969328369 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgerow at afflictions.org Thu Jun 13 10:48:15 2013 From: dgerow at afflictions.org (Damian Gerow) Date: Thu, 13 Jun 2013 08:18:15 -0230 Subject: [rhelv6-list] Modifications to the Base SELinux Policy Message-ID: <20130613104815.GA4673@plebeian> A while back, I started writing some policy modules for some in-house software. Unfortunately, this software used a port that was claimed by hplip_port_t somewhere in the base policy, and there didn't seem to be a way to remove the port from hplip_port_t: Port tcp/xxxx is defined in policy, cannot be deleted The 'fix' I have for this is that we now have our own base policy, that is simply the 'targeted' policy with the appropriate ports removed from hplip_port_t. Which is a giant pain, as we now have to re-compile our base policy, updated to the new source, whenever there's an SELinux update. Is there a better way to override a port that's defined in the base policy, or is providing a different base policy the way to go? (Changing the port for our software is a non-option at this point, unfortunately.) From matthias at saou.eu Thu Jun 13 12:02:59 2013 From: matthias at saou.eu (Matthias Saou) Date: Thu, 13 Jun 2013 14:02:59 +0200 Subject: [rhelv6-list] Modifications to the Base SELinux Policy In-Reply-To: <20130613104815.GA4673@plebeian> References: <20130613104815.GA4673@plebeian> Message-ID: <20130613140259.0bc252b9@r2d2.marmotte.net> On Thu, 13 Jun 2013 08:18:15 -0230 Damian Gerow wrote: > A while back, I started writing some policy modules for some in-house > software. Unfortunately, this software used a port that was claimed > by hplip_port_t somewhere in the base policy, and there didn't seem > to be a way to remove the port from hplip_port_t: > > Port tcp/xxxx is defined in policy, cannot be deleted > > The 'fix' I have for this is that we now have our own base policy, > that is simply the 'targeted' policy with the appropriate ports > removed from hplip_port_t. Which is a giant pain, as we now have to > re-compile our base policy, updated to the new source, whenever > there's an SELinux update. > > Is there a better way to override a port that's defined in the base > policy, or is providing a different base policy the way to go? > > (Changing the port for our software is a non-option at this point, > unfortunately.) What about a "mildly-ugly" solution of allowing access to ports of hplip_port_t type in your custom module? It does have the downside of allowing binding to a lot more ports than you need (I see 18), but that's probably not a major issue. 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 brilong at cisco.com Thu Jun 13 12:06:26 2013 From: brilong at cisco.com (Brian Long (brilong)) Date: Thu, 13 Jun 2013 12:06:26 +0000 Subject: [rhelv6-list] Using mrepo to mirror RHN Classic In-Reply-To: References: Message-ID: On Jun 12, 2013, at 8:25 PM, Colin Coe > wrote: Hi all I've been using mrepo to mirror a few channels out of RHN Classic for a while. Now I hev the requirement to get package group info (think comps.xml) as well. I've googled and tried various things to make this happen without any success. I see that createrepo has a '-g' flag but I've no idea how to get mrepo to pass the '*comps*.xml' filename to createrepo correctly. Is anyone successfully mirroring RHN Classic with mrepo and getting the package group info? If so, could you post a sanitised version of your mrepo config? You may want to ask this question on tools at lists.repoforge.org, the mrepo mailing list. /Brian/ -- Brian Long | | Research Triangle Park, NC . | | | . | | | . ' ' C I S C O -------------- next part -------------- An HTML attachment was scrubbed... URL: From dgerow at afflictions.org Thu Jun 13 12:50:55 2013 From: dgerow at afflictions.org (Damian Gerow) Date: Thu, 13 Jun 2013 10:20:55 -0230 Subject: [rhelv6-list] Modifications to the Base SELinux Policy In-Reply-To: <20130613140259.0bc252b9@r2d2.marmotte.net> References: <20130613104815.GA4673@plebeian> <20130613140259.0bc252b9@r2d2.marmotte.net> Message-ID: <20130613125055.GB7510@plebeian> Matthias Saou wrote: > > Is there a better way to override a port that's defined in the base > > policy, or is providing a different base policy the way to go? > > > > (Changing the port for our software is a non-option at this point, > > unfortunately.) > > What about a "mildly-ugly" solution of allowing access to ports of > hplip_port_t type in your custom module? It does have the downside of > allowing binding to a lot more ports than you need (I see 18), but > that's probably not a major issue. Gah. I meant to point that out as another option that we're considering, but don't love. It's certainly easier than a custom base policy, but it does minimally increase the access of our software to our host. (Whether or not having access to those ports is a bad thing is a whole other story, and can likely be mitigated with interface labels, or with the introduction of a few other booleans to restrict what it can do with hplip_port_t.) Something else we've considered is pulling in a much later version of refpolicy (20110726 looks like a viable candidate, without requiring checkpolicy/libsepol updates), but I don't look forward to the patchwork that may be required. From bdwheele at indiana.edu Thu Jun 13 14:17:50 2013 From: bdwheele at indiana.edu (Brian Wheeler) Date: Thu, 13 Jun 2013 10:17:50 -0400 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? Message-ID: <51B9D48E.4090203@indiana.edu> I couldn't find any links or info anywhere on the RH Summit sites, but does anyone know what the availability of the slide decks and/or video of yesterday's RHEL roadmap sessions is? [hmm. I think that's correct English -- "availability ... is" but it reads funny. Oh well] Brian From b.j.smith at ieee.org Thu Jun 13 15:23:53 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Thu, 13 Jun 2013 11:23:53 -0400 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: <51B9D48E.4090203@indiana.edu> References: <51B9D48E.4090203@indiana.edu> Message-ID: The Keynotes should already be up, and provides some strategic directions. Several presenters Tuesday and yesterday also mentioned their slides would be available Friday around the conclusion of Summit. Several are recorded, so I'm sure editing and other things are in-progress. Have meet a great number from Academia and Research here at Summit (my first since 2008), including community maintainers - even of Enterprise Linux Rebuilds. On Jun 13, 2013 10:19 AM, "Brian Wheeler" wrote: > I couldn't find any links or info anywhere on the RH Summit sites, but > does anyone know what the availability of the slide decks and/or video of > yesterday's RHEL roadmap sessions is? > > [hmm. I think that's correct English -- "availability ... is" but it > reads funny. Oh well] > > Brian > > ______________________________**_________________ > 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 b.j.smith at ieee.org Thu Jun 13 21:25:34 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Thu, 13 Jun 2013 17:25:34 -0400 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: References: <51B9D48E.4090203@indiana.edu> Message-ID: On Thu, Jun 13, 2013 at 11:23 AM, Bryan J Smith wrote: > The Keynotes should already be up, and provides some strategic directions. > > Several presenters Tuesday and yesterday also mentioned their slides would > be available Friday around the conclusion of Summit. Several are recorded, > so I'm sure editing and other things are in-progress. > Actually, just looked, and noticed the videos for _both_ sessions on the RHEL Roadmap are in the Gallery under the appropriate tab. [1] There's also an interview article with a few details by Denise for those that don't have 2 hours to sit through the videos (with far more details). [2] -- bjs [1] Gallery - scroll to bottom, click tab "Application & platform infrastructure sessions" - http://www.redhat.com/summit/2013/gallery/ [2] "Red Hat discloses RHEL roadmap" - http://searchdatacenter.techtarget.com/news/2240185580/Red-Hat-discloses-RHEL-roadmap -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith -------------- next part -------------- An HTML attachment was scrubbed... URL: From bdwheele at indiana.edu Thu Jun 13 21:57:55 2013 From: bdwheele at indiana.edu (Brian Wheeler) Date: Thu, 13 Jun 2013 17:57:55 -0400 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: References: <51B9D48E.4090203@indiana.edu> Message-ID: <51BA4063.2080807@indiana.edu> Awesome, thanks! On 06/13/2013 05:25 PM, Bryan J Smith wrote: > On Thu, Jun 13, 2013 at 11:23 AM, Bryan J Smith > wrote: > > The Keynotes should already be up, and provides some strategic > directions. > > Several presenters Tuesday and yesterday also mentioned their > slides would be available Friday around the conclusion of Summit. > Several are recorded, so I'm sure editing and other things are > in-progress. > > Actually, just looked, and noticed the videos for _both_ sessions on > the RHEL Roadmap are in the Gallery under the appropriate tab. [1] > > There's also an interview article with a few details by Denise for > those that don't have 2 hours to sit through the videos (with far more > details). [2] > > -- bjs > > [1] Gallery - scroll to bottom, click tab "Application & platform > infrastructure sessions" > - http://www.redhat.com/summit/2013/gallery/ > > [2] "Red Hat discloses RHEL roadmap" > - > http://searchdatacenter.techtarget.com/news/2240185580/Red-Hat-discloses-RHEL-roadmap > > > -- > 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 b.j.smith at ieee.org Thu Jun 13 22:10:36 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Thu, 13 Jun 2013 18:10:36 -0400 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: <51BA4063.2080807@indiana.edu> References: <51B9D48E.4090203@indiana.edu> <51BA4063.2080807@indiana.edu> Message-ID: On Thu, Jun 13, 2013 at 5:57 PM, Brian Wheeler wrote: > Awesome, thanks! > No problem. People on LinkedIn in a couple of groups were looking for them as well. [A] -- bjs [A] http://tinyurl.com/keft5qj -------------- next part -------------- An HTML attachment was scrubbed... URL: From colin.coe at gmail.com Fri Jun 14 00:58:13 2013 From: colin.coe at gmail.com (Colin Coe) Date: Fri, 14 Jun 2013 08:58:13 +0800 Subject: [rhelv6-list] Using mrepo to mirror RHN Classic In-Reply-To: References: Message-ID: Hi Damian Yep, if/when I get the answers I'll repost. Satellite does this out of the box as can Spacewalk except it has to be able to get the info first. This is the situation I'm in. I use mrepo to get the content out of RHN Classic and then provide it internally with Spacewalk. Hi Brian I've reposted to tools at lists.repoforge.org as suggested. Thanks CC On Thu, Jun 13, 2013 at 8:06 PM, Brian Long (brilong) wrote: > > On Jun 12, 2013, at 8:25 PM, Colin Coe wrote: > > Hi all > > I've been using mrepo to mirror a few channels out of RHN Classic for a > while. Now I hev the requirement to get package group info (think > comps.xml) as well. > > I've googled and tried various things to make this happen without any > success. I see that createrepo has a '-g' flag but I've no idea how to get > mrepo to pass the '*comps*.xml' filename to createrepo correctly. > > Is anyone successfully mirroring RHN Classic with mrepo and getting the > package group info? If so, could you post a sanitised version of your > mrepo config? > > > You may want to ask this question on tools at lists.repoforge.org, the > mrepo mailing list. > > /Brian/ > > -- > Brian Long | | > Research Triangle Park, NC . | | | . | | | . > ' ' > C I S C O > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -- RHCE#805007969328369 -------------- next part -------------- An HTML attachment was scrubbed... URL: From janfrode at tanso.net Sat Jun 15 01:06:50 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Sat, 15 Jun 2013 03:06:50 +0200 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: References: <51B9D48E.4090203@indiana.edu> <51BA4063.2080807@indiana.edu> Message-ID: <20130615010650.GA16235@mushkin.tanso.net> One interesting thing that was mentioned in one of the sessions was there should be some announcement of puppet integration with the satellite server. Unfortunately I didn't catch the real announcement, so did anybody else, or does anybody know anything about this ? -jf From janfrode at tanso.net Mon Jun 17 13:57:29 2013 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Mon, 17 Jun 2013 15:57:29 +0200 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: <20130615010650.GA16235@mushkin.tanso.net> References: <51B9D48E.4090203@indiana.edu> <51BA4063.2080807@indiana.edu> <20130615010650.GA16235@mushkin.tanso.net> Message-ID: <20130617135729.GA13888@mushkin.tanso.net> On Sat, Jun 15, 2013 at 03:06:50AM +0200, Jan-Frode Myklebust wrote: > One interesting thing that was mentioned in one of the sessions > was there should be some announcement of puppet integration > with the satellite server. > http://rhsummit.files.wordpress.com/2013/06/caplan_rhsatellite.pdf Satellite v6: - Puppet for configuration - Foreman for provisioning -jf From b.j.smith at ieee.org Mon Jun 17 17:50:34 2013 From: b.j.smith at ieee.org (Bryan J Smith) Date: Mon, 17 Jun 2013 13:50:34 -0400 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: References: <51B9D48E.4090203@indiana.edu> Message-ID: Several of the presentations are available in PDF format now [3], although the RHEL Roadmap I & II sessions were not as of mid-Monday US EDT. -- bjs [3] http://www.redhat.com/summit/2013/presentations/ On Thu, Jun 13, 2013 at 5:25 PM, Bryan J Smith wrote: > On Thu, Jun 13, 2013 at 11:23 AM, Bryan J Smith wrote: > >> The Keynotes should already be up, and provides some strategic directions. >> >> Several presenters Tuesday and yesterday also mentioned their slides >> would be available Friday around the conclusion of Summit. Several are >> recorded, so I'm sure editing and other things are in-progress. >> > Actually, just looked, and noticed the videos for _both_ sessions on the > RHEL Roadmap are in the Gallery under the appropriate tab. [1] > > There's also an interview article with a few details by Denise for those > that don't have 2 hours to sit through the videos (with far more details). > [2] > > -- bjs > > [1] Gallery - scroll to bottom, click tab "Application & platform > infrastructure sessions" > - http://www.redhat.com/summit/2013/gallery/ > > [2] "Red Hat discloses RHEL roadmap" > - > http://searchdatacenter.techtarget.com/news/2240185580/Red-Hat-discloses-RHEL-roadmap > -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith -------------- next part -------------- An HTML attachment was scrubbed... URL: From Sandro.Roth at zurich-airport.com Tue Jun 18 06:39:02 2013 From: Sandro.Roth at zurich-airport.com (Roth, Sandro) Date: Tue, 18 Jun 2013 06:39:02 +0000 Subject: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? In-Reply-To: References: <51B9D48E.4090203@indiana.edu> Message-ID: All the videos are now up on youtube as well: Part 1: http://www.youtube.com/watch?v=GRF4ZRCPMzo Part 2: http://www.youtube.com/watch?v=kkAeahvm_rA Sandro From: rhelv6-list-bounces at redhat.com [mailto:rhelv6-list-bounces at redhat.com] On Behalf Of Bryan J Smith Sent: Montag, 17. Juni 2013 19:51 To: rhelv6-list at redhat.com Subject: Re: [rhelv6-list] availability of yesterday's RHEL roadmap sessions? Several of the presentations are available in PDF format now [3], although the RHEL Roadmap I & II sessions were not as of mid-Monday US EDT. -- bjs [3] http://www.redhat.com/summit/2013/presentations/ On Thu, Jun 13, 2013 at 5:25 PM, Bryan J Smith > wrote: On Thu, Jun 13, 2013 at 11:23 AM, Bryan J Smith > wrote: The Keynotes should already be up, and provides some strategic directions. Several presenters Tuesday and yesterday also mentioned their slides would be available Friday around the conclusion of Summit. Several are recorded, so I'm sure editing and other things are in-progress. Actually, just looked, and noticed the videos for _both_ sessions on the RHEL Roadmap are in the Gallery under the appropriate tab. [1] There's also an interview article with a few details by Denise for those that don't have 2 hours to sit through the videos (with far more details). [2] -- bjs [1] Gallery - scroll to bottom, click tab "Application & platform infrastructure sessions" - http://www.redhat.com/summit/2013/gallery/ [2] "Red Hat discloses RHEL roadmap" - http://searchdatacenter.techtarget.com/news/2240185580/Red-Hat-discloses-RHEL-roadmap -- Bryan J Smith - Professional, Technical Annoyance b.j.smith at ieee.org - http://www.linkedin.com/in/bjsmith This email message and any attachments are confidential and may be privileged. If you are not the intended recipient, please notify us immediately and destroy the original transmittal. You are hereby notified that any review, copying or distribution of it is strictly prohibited. Thank you for your cooperation. Header information contained in E-mails to and from the company are monitored for operational reasons in accordance with swiss data protection act. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bda20 at cam.ac.uk Tue Jun 18 11:00:52 2013 From: bda20 at cam.ac.uk (Ben) Date: Tue, 18 Jun 2013 12:00:52 +0100 (BST) Subject: [rhelv6-list] Dell servers stopping at GRUB if no manual input Message-ID: I have a few Dell servers of varying marques: R710, R420, etc. I've installed RHEL6 (64bit) on them via DRAC/serial console. The grub.conf looks like this: default=0 timeout=5 serial --unit=1 --speed=115200 terminal --timeout=5 serial console title Red Hat Enterprise Linux Server (2.6.32-358.11.1.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-358.11.1.el6.x86_64 ro root=/dev/mapper/vg_pinky-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_LVM_LV=vg_pinky/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto console=ttyS1,115200 rd_LVM_LV=vg_pinky/lv_root rd_NO_DM initrd /initramfs-2.6.32-358.11.1.el6.x86_64.img title Red Hat Enterprise Linux (2.6.32-358.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-358.el6.x86_64 ro root=/dev/mapper/vg_pinky-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_LVM_LV=vg_pinky/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto console=ttyS1,115200 rd_LVM_LV=vg_pinky/lv_root rd_NO_DM initrd /initramfs-2.6.32-358.el6.x86_64.img Whenever I reboot them and I'm not connected to the serial console (or have a keyboard and monitor plugged in) and don't press and/or at the point at which it says "Press any key to continue." to get the GRUB boot menu up, the servers don't boot. They just appear to stop at some point and are non-responsive via any method (connecting to the DRAC/serial console, or plugging in a keyboard and mouse) until rebooted. Any ideas why, please? This didn't used to happen with RHEL5, I don't think. Ben -- Unix Support, MISD, University of Cambridge, England From matthias at saou.eu Tue Jun 18 11:27:26 2013 From: matthias at saou.eu (Matthias Saou) Date: Tue, 18 Jun 2013 13:27:26 +0200 Subject: [rhelv6-list] Dell servers stopping at GRUB if no manual input In-Reply-To: References: Message-ID: <20130618132726.5226c8f6@r2d2.marmotte.net> On Tue, 18 Jun 2013 12:00:52 +0100 (BST) Ben wrote: > I have a few Dell servers of varying marques: R710, R420, etc. I've > installed RHEL6 (64bit) on them via DRAC/serial console. The > grub.conf looks like this: > > default=0 > timeout=5 > serial --unit=1 --speed=115200 > terminal --timeout=5 serial console > title Red Hat Enterprise Linux Server (2.6.32-358.11.1.el6.x86_64) > root (hd0,0) > kernel /vmlinuz-2.6.32-358.11.1.el6.x86_64 ro > root=/dev/mapper/vg_pinky-lv_root rd_NO_LUKS KEYBOARDTYPE=pc > KEYTABLE=uk LANG=en_US.UTF-8 rd_LVM_LV=vg_pinky/lv_swap rd_NO_MD > SYSFONT=latarcyrheb-sun16 crashkernel=auto console=ttyS1,115200 > rd_LVM_LV=vg_pinky/lv_root rd_NO_DM > initrd /initramfs-2.6.32-358.11.1.el6.x86_64.img title Red Hat > Enterprise Linux (2.6.32-358.el6.x86_64) root (hd0,0) > kernel /vmlinuz-2.6.32-358.el6.x86_64 ro > root=/dev/mapper/vg_pinky-lv_root rd_NO_LUKS KEYBOARDTYPE=pc > KEYTABLE=uk LANG=en_US.UTF-8 rd_LVM_LV=vg_pinky/lv_swap rd_NO_MD > SYSFONT=latarcyrheb-sun16 crashkernel=auto console=ttyS1,115200 > rd_LVM_LV=vg_pinky/lv_root rd_NO_DM > initrd /initramfs-2.6.32-358.el6.x86_64.img > > Whenever I reboot them and I'm not connected to the serial console > (or have a keyboard and monitor plugged in) and don't press > and/or at the point at which it says "Press any key to > continue." to get the GRUB boot menu up, the servers don't boot. > They just appear to stop at some point and are non-responsive via any > method (connecting to the DRAC/serial console, or plugging in a > keyboard and mouse) until rebooted. > > Any ideas why, please? This didn't used to happen with RHEL5, I > don't think. You might want to check the "Redirection after boot" setting for the serial configuration in the BIOS. Typically, since you've set up a proper serial console at the GRUB level (and hopefully after too), then it should be "Disabled". If that's not the issue, then I don't know what could be, and haven't seen that issue with RHEL6 on similar hardware. 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 bda20 at cam.ac.uk Tue Jun 18 11:48:01 2013 From: bda20 at cam.ac.uk (Ben) Date: Tue, 18 Jun 2013 12:48:01 +0100 (BST) Subject: [rhelv6-list] Dell servers stopping at GRUB if no manual input In-Reply-To: <20130618132726.5226c8f6@r2d2.marmotte.net> References: <20130618132726.5226c8f6@r2d2.marmotte.net> Message-ID: On Tue, 18 Jun 2013, Matthias Saou wrote: > On Tue, 18 Jun 2013 12:00:52 +0100 (BST) > Ben wrote: > >> I have a few Dell servers of varying marques: R710, R420, etc. I've >> installed RHEL6 (64bit) on them via DRAC/serial console. The grub.conf >> looks like this: >> >> [blah] >> >> Whenever I reboot them and I'm not connected to the serial console (or >> have a keyboard and monitor plugged in) and don't press and/or >> at the point at which it says "Press any key to continue." to >> get the GRUB boot menu up, the servers don't boot. They just appear to >> stop at some point and are non-responsive via any method (connecting to >> the DRAC/serial console, or plugging in a keyboard and mouse) until >> rebooted. >> >> Any ideas why, please? This didn't used to happen with RHEL5, I don't >> think. > > You might want to check the "Redirection after boot" setting for the > serial configuration in the BIOS. Typically, since you've set up a > proper serial console at the GRUB level (and hopefully after too), then > it should be "Disabled". That's a very good point. I checked, and they're set to "Enabled". So, good catch. Normally I do change that to "Disabled", but seem to have missed it on recent builds. However, someone on Freenode/#rhel suggested adding the "--silent" option to the terminal line in GRUB. This appears to have fixed my issue, too, without changing the BIOS option above. However, it does stop the "Hit any key to continue." messages. This isn't a problem for me, but might be for others. > If that's not the issue, then I don't know what could be, and haven't seen > that issue with RHEL6 on similar hardware. It was the serial redirection after boot thing. However, I'm going to leave the BIOSes alone on those servers that were exhibiting this behaviour and go with the "--silent" option, as that won't require a reboot. Thanks for the help! Ben -- Unix Support, MISD, University of Cambridge, England From darren.patterson at stanford.edu Tue Jun 18 15:38:22 2013 From: darren.patterson at stanford.edu (Darren Patterson) Date: Tue, 18 Jun 2013 09:38:22 -0600 Subject: [rhelv6-list] Dell servers stopping at GRUB if no manual input In-Reply-To: References: Message-ID: <7D3AE1F2-CE09-40B9-8EAB-A4E021EC017E@stanford.edu> This sounds like the ancient serial console timeout issue that was mitigated by changing the terminal line to be: terminal -timeout=5 serial console Specifically, remove one hyphen before timeout. Cobbler has setup all my systems like this at build time like this since RHEL3. If this bug and subsequent work-around is still bothering people using serial console, it wouldn't surprise me. Thanks, -darren On Jun 18, 2013, at 5:00 AM, Ben wrote: > I have a few Dell servers of varying marques: R710, R420, etc. I've installed RHEL6 (64bit) on them via DRAC/serial console. The grub.conf looks like this: > > default=0 > timeout=5 > serial --unit=1 --speed=115200 > terminal --timeout=5 serial console > title Red Hat Enterprise Linux Server (2.6.32-358.11.1.el6.x86_64) > root (hd0,0) > kernel /vmlinuz-2.6.32-358.11.1.el6.x86_64 ro root=/dev/mapper/vg_pinky-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_LVM_LV=vg_pinky/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto console=ttyS1,115200 rd_LVM_LV=vg_pinky/lv_root rd_NO_DM > initrd /initramfs-2.6.32-358.11.1.el6.x86_64.img > title Red Hat Enterprise Linux (2.6.32-358.el6.x86_64) > root (hd0,0) > kernel /vmlinuz-2.6.32-358.el6.x86_64 ro root=/dev/mapper/vg_pinky-lv_root rd_NO_LUKS KEYBOARDTYPE=pc KEYTABLE=uk LANG=en_US.UTF-8 rd_LVM_LV=vg_pinky/lv_swap rd_NO_MD SYSFONT=latarcyrheb-sun16 crashkernel=auto console=ttyS1,115200 rd_LVM_LV=vg_pinky/lv_root rd_NO_DM > initrd /initramfs-2.6.32-358.el6.x86_64.img > > Whenever I reboot them and I'm not connected to the serial console (or have a keyboard and monitor plugged in) and don't press and/or at the point at which it says "Press any key to continue." to get the GRUB boot menu up, the servers don't boot. They just appear to stop at some point and are non-responsive via any method (connecting to the DRAC/serial console, or plugging in a keyboard and mouse) until rebooted. > > Any ideas why, please? This didn't used to happen with RHEL5, I don't think. > > Ben > -- > Unix Support, MISD, University of Cambridge, England > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list ----------------------- Darren Patterson Stanford IT Services 650.804.8143 (cell) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at redhat.com Sun Jun 23 05:37:12 2013 From: thomas at redhat.com (thomas at redhat.com) Date: Sun, 23 Jun 2013 00:37:12 -0500 Subject: [rhelv6-list] I know this is a stretch, but... Message-ID: <51C68988.2050209@redhat.com> I am putting together an infiniband network at my home lab. I found a used 24-port IB switch on eBay for $150, so I bought it. I got the QLogic SilverStorm InfiniBand Edge (9024-CU24-ST2-DDR) 24-port switch. It seems to power up just fine, but it was apparently not restored to factory defaults when it was retired. I Have tried to run tcpdump against the Ethernet port when it boots to see if it's talking on Ethernet at all, and I am seeing nothing. I've tried pinging 255.255.255.255 to see if it will respond. No joy. I really just want to restore this thing to factory defaults, but I can't find any documentation on doing that anywhere. Apparently QLogic sold this line to Intel a few years ago, and I can't find much on either the QLogic or Intel sites beyond the user's guide, CLI guide, and hardware installation guide, but none of them discuss resetting the unit to defaults. I opened it up and found a button on a daughter board which seems to soft reset the unit, but I can't figure out any magical incantation to reset it to defaults. I see jumpers right next to the switch, so I'm guessing that there's probably a jumper I can set to do this, but I'm a little scared of randomly powering the thing up with jumpers applied. :-) Is anyone familiar with this switch? Got any words of wisdom? -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Western 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 thomas at redhat.com Sun Jun 23 06:43:20 2013 From: thomas at redhat.com (thomas at redhat.com) Date: Sun, 23 Jun 2013 01:43:20 -0500 Subject: [rhelv6-list] I know this is a stretch, but... In-Reply-To: <51C68988.2050209@redhat.com> References: <51C68988.2050209@redhat.com> Message-ID: <51C69908.2070103@redhat.com> On 06/23/2013 12:37 AM, thomas at redhat.com wrote: > I am putting together an infiniband network at my home lab. I found a > used 24-port IB switch on eBay for $150, so I bought it. > > I got the QLogic SilverStorm InfiniBand Edge (9024-CU24-ST2-DDR) 24-port > switch. It seems to power up just fine, but it was apparently not > restored to factory defaults when it was retired. > > I Have tried to run tcpdump against the Ethernet port when it boots to > see if it's talking on Ethernet at all, and I am seeing nothing. > > I've tried pinging 255.255.255.255 to see if it will respond. No joy. > > I really just want to restore this thing to factory defaults, but I > can't find any documentation on doing that anywhere. > > Apparently QLogic sold this line to Intel a few years ago, and I can't > find much on either the QLogic or Intel sites beyond the user's guide, > CLI guide, and hardware installation guide, but none of them discuss > resetting the unit to defaults. > > I opened it up and found a button on a daughter board which seems to > soft reset the unit, but I can't figure out any magical incantation to > reset it to defaults. I see jumpers right next to the switch, so I'm > guessing that there's probably a jumper I can set to do this, but I'm a > little scared of randomly powering the thing up with jumpers applied. :-) > > Is anyone familiar with this switch? Got any words of wisdom? Forgot to mention: I've been trying to get serial connectivity, but the docs are not terribly clear about how to do it. The pinout they describe in the appendix of the hardware installation guide doesn't make sense, at least not to me. I bought a DB9F to RJ11 Modular to D-Sub Adaptor Kit from Fry's and I *thought* I plugged it together right, but I get nothing from minicom. Of course, I am going over a USB to serial adapter, and I know that introduces its own set of oddities, so... -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Western 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 fmdlc at code4life.com.ar Sun Jun 23 07:16:22 2013 From: fmdlc at code4life.com.ar (Facundo M. de la Cruz) Date: Sun, 23 Jun 2013 04:16:22 -0300 Subject: [rhelv6-list] I know this is a stretch, but... In-Reply-To: <51C69908.2070103@redhat.com> References: <51C68988.2050209@redhat.com> <51C69908.2070103@redhat.com> Message-ID: Can you try with another terminal emulator like screen? In some cases I could'nt get any response from Minicom, but when I tried using screen I had this response, anyway you can play with others terminal configuaration (just check your vendor manual for do it). What cable are you using? The pinout is correct?. I'm trying to give you some tips for do it. Good luck and regards El 23/06/2013 03:47, "thomas at redhat.com" escribi?: > On 06/23/2013 12:37 AM, thomas at redhat.com wrote: > >> I am putting together an infiniband network at my home lab. I found a >> used 24-port IB switch on eBay for $150, so I bought it. >> >> I got the QLogic SilverStorm InfiniBand Edge (9024-CU24-ST2-DDR) 24-port >> switch. It seems to power up just fine, but it was apparently not >> restored to factory defaults when it was retired. >> >> I Have tried to run tcpdump against the Ethernet port when it boots to >> see if it's talking on Ethernet at all, and I am seeing nothing. >> >> I've tried pinging 255.255.255.255 to see if it will respond. No joy. >> >> I really just want to restore this thing to factory defaults, but I >> can't find any documentation on doing that anywhere. >> >> Apparently QLogic sold this line to Intel a few years ago, and I can't >> find much on either the QLogic or Intel sites beyond the user's guide, >> CLI guide, and hardware installation guide, but none of them discuss >> resetting the unit to defaults. >> >> I opened it up and found a button on a daughter board which seems to >> soft reset the unit, but I can't figure out any magical incantation to >> reset it to defaults. I see jumpers right next to the switch, so I'm >> guessing that there's probably a jumper I can set to do this, but I'm a >> little scared of randomly powering the thing up with jumpers applied. :-) >> >> Is anyone familiar with this switch? Got any words of wisdom? >> > > Forgot to mention: I've been trying to get serial connectivity, but the > docs are not terribly clear about how to do it. The pinout they describe in > the appendix of the hardware installation guide doesn't make sense, at > least not to me. > > I bought a DB9F to RJ11 Modular to D-Sub Adaptor Kit from Fry's and I > *thought* I plugged it together right, but I get nothing from minicom. Of > course, I am going over a USB to serial adapter, and I know that introduces > its own set of oddities, so... > > -- > Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX > Chief Architect, Western 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 > > ______________________________**_________________ > 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 thomas at redhat.com Sun Jun 23 07:37:16 2013 From: thomas at redhat.com (thomas at redhat.com) Date: Sun, 23 Jun 2013 02:37:16 -0500 Subject: [rhelv6-list] I know this is a stretch, but... In-Reply-To: References: <51C68988.2050209@redhat.com> <51C69908.2070103@redhat.com> Message-ID: <51C6A5AC.7070006@redhat.com> On 06/23/2013 02:16 AM, Facundo M. de la Cruz wrote: > Can you try with another terminal emulator like screen? In some cases I > could'nt get any response from Minicom, but when I tried using screen I > had this response, anyway you can play with others terminal > configuaration (just check your vendor manual for do it). What cable are > you using? The pinout is correct?. I'm trying to give you some tips for > do it. > > Good luck and regards Hi Facundo - I was using the DB9F to RJ11 Modular to D-Sub Adaptor Kit at http://www.frys.com/product/2402370, but I realized a few minutes ago that I definitely pinned it incorrectly. Hopefully that is the issue... Unfortunately I only bought one, and I can't see a way to pull the pins back out, I think they only connect one time and then they're permanent. I'll go get another one tomorrow and pin it correctly. I think the correct pinout is at http://goldfndr.home.mindspring.com/digitraveler.html - if anyone has any corrections, I'd love to know. I am also using the Link Depot USB to DB9 Serial at http://www.frys.com/product/6819966. It shows up fine as /dev/ttyUSB0. I think my serial communications problem is just that I pinned the DB9F to RJ11 Modular to D-Sub Adaptor wrong. -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Western 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 bill at magicdigits.com Sun Jun 23 14:01:41 2013 From: bill at magicdigits.com (Bill) Date: Sun, 23 Jun 2013 07:01:41 -0700 Subject: [rhelv6-list] I know this is a stretch, but... In-Reply-To: <51C6A5AC.7070006@redhat.com> References: <51C68988.2050209@redhat.com> <51C69908.2070103@redhat.com> <51C6A5AC.7070006@redhat.com> Message-ID: <20130623135444.M43855@part103.org> Tom, I have removed pins hundreds of times from those connectors using a paper clip. There is a specialty tool for removing those pins, but I never seem to have it with me when I need it. Using the small normal sized paper clip, bend the outermost part 90 degrees up. Then place the clip on a desk the way it would normally lay. Then press the dsub pin hole onto the paper clip with about 10 pounds of force. There will be a snap and the pin will be free. Only takes 1/8 of an inch movement. I have removed and replaced wires 1/2 dozen times on the same connector without problems. Save you a trip to Frys ( and keep you from spending another $100 for other stuff you **need** =) Bill Watson bill at magicdigits.com ---------- Original Message ----------- From: "thomas at redhat.com" To: rhelv6-list at redhat.com Sent: Sun, 23 Jun 2013 02:37:16 -0500 Subject: Re: [rhelv6-list] I know this is a stretch, but... > On 06/23/2013 02:16 AM, Facundo M. de la Cruz wrote: > > Can you try with another terminal emulator like screen? In some cases I > > could'nt get any response from Minicom, but when I tried using screen I > > had this response, anyway you can play with others terminal > > configuaration (just check your vendor manual for do it). What cable are > > you using? The pinout is correct?. I'm trying to give you some tips for > > do it. > > > > Good luck and regards > > Hi Facundo - > > I was using the DB9F to RJ11 Modular to D-Sub Adaptor Kit at > http://www.frys.com/product/2402370, but I realized a few minutes ago > that I definitely pinned it incorrectly. Hopefully that is the issue... > Unfortunately I only bought one, and I can't see a way to pull the pins > back out, I think they only connect one time and then they're permanent. > I'll go get another one tomorrow and pin it correctly. I think the > correct pinout is at > http://goldfndr.home.mindspring.com/digitraveler.html - if anyone has > any corrections, I'd love to know. > > I am also using the Link Depot USB to DB9 Serial at > http://www.frys.com/product/6819966. It shows up fine as /dev/ttyUSB0. > > I think my serial communications problem is just that I pinned the DB9F > to RJ11 Modular to D-Sub Adaptor wrong. > -- > Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX > Chief Architect, Western 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 > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list ------- End of Original Message ------- From bill at magicdigits.com Sun Jun 23 14:20:32 2013 From: bill at magicdigits.com (Bill) Date: Sun, 23 Jun 2013 07:20:32 -0700 Subject: [rhelv6-list] I know this is a stretch, but... In-Reply-To: <51C6A5AC.7070006@redhat.com> References: <51C68988.2050209@redhat.com> <51C69908.2070103@redhat.com> <51C6A5AC.7070006@redhat.com> Message-ID: <20130623140309.M30828@part103.org> As for the pinout, 2,3,5 on the dsub is all the signal lines you should need, but sometimes some emulators want more pins shorted together to set the cts/rts or dsr/dtr signals on. That would be hooking 4 to 6 and 7 to 8 on the dsub. If you have a volt meter, you should see -12v on the wire you connect to pin 2 compared to the pin you connect to 5. The wire to 3 should float, meaning it should be able to be shorted to either 2 or 5 without changing the -12v difference between the two by 1v. This is because the wire to 2 should carry the data from the switch to the pc and 5 should be the ground. The wire to 3 should carry -12v from the PC back to the switch. I have seen pinouts like your chosen diagram, but there are also many where 2,3 are the red/green (2,3) pair. Many use the black instead of yellow for ground on 5. Every combination is possible. There has never been a standard. Even within dsubs the red/green and yel/blk are swapped sometimes. Be sure your phone cable connects at least 4 wires. Sometimes only the middle 2 are connected in some phone cables. Bill Watson bill at magicdigits.com ---------- Original Message ----------- From: "thomas at redhat.com" To: rhelv6-list at redhat.com Sent: Sun, 23 Jun 2013 02:37:16 -0500 Subject: Re: [rhelv6-list] I know this is a stretch, but... > On 06/23/2013 02:16 AM, Facundo M. de la Cruz wrote: > > Can you try with another terminal emulator like screen? In some cases I > > could'nt get any response from Minicom, but when I tried using screen I > > had this response, anyway you can play with others terminal > > configuaration (just check your vendor manual for do it). What cable are > > you using? The pinout is correct?. I'm trying to give you some tips for > > do it. > > > > Good luck and regards > > Hi Facundo - > > I was using the DB9F to RJ11 Modular to D-Sub Adaptor Kit at > http://www.frys.com/product/2402370, but I realized a few minutes ago > that I definitely pinned it incorrectly. Hopefully that is the issue... > Unfortunately I only bought one, and I can't see a way to pull the pins > back out, I think they only connect one time and then they're permanent. > I'll go get another one tomorrow and pin it correctly. I think the > correct pinout is at > http://goldfndr.home.mindspring.com/digitraveler.html - if anyone has > any corrections, I'd love to know. > > I am also using the Link Depot USB to DB9 Serial at > http://www.frys.com/product/6819966. It shows up fine as /dev/ttyUSB0. > > I think my serial communications problem is just that I pinned the DB9F > to RJ11 Modular to D-Sub Adaptor wrong. > -- > Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX > Chief Architect, Western 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 > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list ------- End of Original Message ------- From thomas at redhat.com Sun Jun 23 16:45:19 2013 From: thomas at redhat.com (thomas at redhat.com) Date: Sun, 23 Jun 2013 11:45:19 -0500 Subject: [rhelv6-list] I know this is a stretch, but... In-Reply-To: <20130623135444.M43855@part103.org> References: <51C68988.2050209@redhat.com> <51C69908.2070103@redhat.com> <51C6A5AC.7070006@redhat.com> <20130623135444.M43855@part103.org> Message-ID: <51C7261F.30105@redhat.com> On 06/23/2013 09:01 AM, Bill wrote: > Tom, > I have removed pins hundreds of times from those connectors using a paper clip. There > is a specialty tool for removing those pins, but I never seem to have it with me when > I need it. Using the small normal sized paper clip, bend the outermost part 90 degrees > up. Then place the clip on a desk the way it would normally lay. Then press the dsub > pin hole onto the paper clip with about 10 pounds of force. There will be a snap and > the pin will be free. Only takes 1/8 of an inch movement. I have removed and replaced > wires 1/2 dozen times on the same connector without problems. > > Save you a trip to Frys ( and keep you from spending another $100 for other stuff you > **need** =) Heh - I wish I'd seen this in the wee hours while I was attacking the adapter. I wound up breaking a wire trying to pull it out. I'm looking at http://goldfndr.home.mindspring.com/digitraveler.html - it appears to call out the correct pins... can you confirm that, Bill? I bought this rj11 cable: http://www.frys.com/product/3550704. I also bought a couple of the adapters. I'll break out a paper clip as well. :-) Thanks! -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Western 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 thomas at redhat.com Sun Jun 23 21:12:36 2013 From: thomas at redhat.com (thomas at redhat.com) Date: Sun, 23 Jun 2013 16:12:36 -0500 Subject: [rhelv6-list] I know this is a stretch, but... In-Reply-To: <51C7261F.30105@redhat.com> References: <51C68988.2050209@redhat.com> <51C69908.2070103@redhat.com> <51C6A5AC.7070006@redhat.com> <20130623135444.M43855@part103.org> <51C7261F.30105@redhat.com> Message-ID: <51C764C4.3070900@redhat.com> On 06/23/2013 11:45 AM, thomas at redhat.com wrote: > On 06/23/2013 09:01 AM, Bill wrote: >> Tom, >> I have removed pins hundreds of times from those connectors using a >> paper clip. There >> is a specialty tool for removing those pins, but I never seem to have >> it with me when >> I need it. Using the small normal sized paper clip, bend the outermost >> part 90 degrees >> up. Then place the clip on a desk the way it would normally lay. Then >> press the dsub >> pin hole onto the paper clip with about 10 pounds of force. There will >> be a snap and >> the pin will be free. Only takes 1/8 of an inch movement. I have >> removed and replaced >> wires 1/2 dozen times on the same connector without problems. >> >> Save you a trip to Frys ( and keep you from spending another $100 for >> other stuff you >> **need** =) > > Heh - I wish I'd seen this in the wee hours while I was attacking the > adapter. I wound up breaking a wire trying to pull it out. > > I'm looking at http://goldfndr.home.mindspring.com/digitraveler.html - > it appears to call out the correct pins... can you confirm that, Bill? > > I bought this rj11 cable: http://www.frys.com/product/3550704. I also > bought a couple of the adapters. I'll break out a paper clip as well. :-) > > Thanks! Good news! I was never able to get minicom to work, but I finally got "screen /dev/ttyS0 57600" to at least show me the POST messages from the unit. I was able to find the IP address and get logged in. I now have infiniband running in my little lab! I used the pinout from http://goldfndr.home.mindspring.com/digitraveler.html. Now to re-rack everything! -- Thomas Cameron, RHCA, RHCSS, RHCDS, RHCVA, RHCX Chief Architect, Western 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 i.mortimer at uq.edu.au Mon Jun 24 04:35:13 2013 From: i.mortimer at uq.edu.au (Ian Mortimer) Date: Mon, 24 Jun 2013 14:35:13 +1000 Subject: [rhelv6-list] anaconda times out when downloading kickstart file. Message-ID: <51C7CC81.6030801@uq.edu.au> Hi Is there anyway to stop anaconda going to the manual install screen when kickstarting or at least increase the timeout? I'm trying to remotely kickstart hosts on a slow network. Sometimes the pxe boot times out but that's no problem - I can just try again. Dhcp was timing out but I fixed that by passing a large dhcptimeout value to anaconda. However it's then (mostly) timing out when downloading the kickstart file which means a long trip to push the restart button. After a few retries it succeeds but it would be a lot easier if I could get rid of the timeouts. Thanks -- Ian i.mortimer at uq.edu.au Ian Mortimer Tel: +61 7 3346 8528 Science IT University of Queensland From patrik.martinsson at smhi.se Mon Jun 24 20:45:12 2013 From: patrik.martinsson at smhi.se (Martinsson Patrik) Date: Mon, 24 Jun 2013 20:45:12 +0000 Subject: [rhelv6-list] Red Hat 6.4, keepalived and ipv6 Message-ID: Hello, This is not a specific Red Hat 6 question, but there seems to be a lot of people with general knowledge here so I'm going to take my chances. Already tried keepalived-mailinglist but no answer. I'm really trying to understand how keepalived handles ipv6 VIP's and what's the general idea and best practise is, however I seem to miss something. I don't understand why you wouldn't want to have keepalived to set the preferred_lft to zero when bringing up the VIP's, or actually what I don't understand is how to make various checks work with the source-address beeing the VIP and not the "iron-address". So, here's the simple configuration, # keepalived.conf, global_defs { notification_email_from foo at bar.com smtp_server bar.com smtp_connect_timeout 30 lvs_id ER-TST-LD-MASTER } vrrp_instance VI_1 { state MASTER interface eth0 lvs_sync_daemon_interface eth0 virtual_router_id 56 priority 150 advert_int 1 smtp_alert authentication { auth_type PASS auth_pass example } virtual_ipaddress { XXXX:XXX:XXX:XXXX::46 } } virtual_server XXXX:XXX:XXX:XXXX::46 0 { delay_loop 10 lb_algo rr lb_kind DR persistence_timeout 900 protocol TCP real_server XXXX:XXX:XXX:XXXX::17 0 { weight 1 inhibit_on_failure MISC_CHECK { misc_path "/etc/keepalived/check_tcp -H XXXX:XXX:XXX:XXXX::17 -p 21" misc_timeout 30 } } } # end keepalived.conf So, this would mean that when keepalived performs the check to see if the realserver (XX:17 on port 21) is alive, the source-address of that packet is the VIP (XX:46), which of course also is up on the realserver, which in turns would mean that the packet never returns to keepalived. And thus making keepalived to mark the realserver as down (since it doesnt get any reply). So, what I'm I missing here, how is this suppose to work ? I've been trying to read the following discussions, they seem to have the same problem, http://www.ietf.org/mail-archive/web/v6ops/current/msg15266.html http://marc.info/?l=keepalived-devel&m=130200733315039 (there's a patch that would make sense to me, but never got accepted if I'm not mistaken) Patrik Martinsson ITi SMHI Telefon 011 - 495 84 17 Fax 011 - 495 83 50 Mobil 011 - 495 84 17 Epost Patrik.Martinsson at smhi.se 601 76 Norrk?ping Bes?ksadress Folkborgsv?gen 1 www.smhi.se From matthias at saou.eu Tue Jun 25 10:31:07 2013 From: matthias at saou.eu (Matthias Saou) Date: Tue, 25 Jun 2013 12:31:07 +0200 Subject: [rhelv6-list] Red Hat 6.4, keepalived and ipv6 In-Reply-To: References: Message-ID: <20130625123107.52d405e0@r2d2.marmotte.net> On Mon, 24 Jun 2013 20:45:12 +0000 Martinsson Patrik wrote: > Hello, > > This is not a specific Red Hat 6 question, but there seems to be a > lot of people with general knowledge here so I'm going to take my > chances. Already tried keepalived-mailinglist but no answer. > > > I'm really trying to understand how keepalived handles ipv6 VIP's and > what's the general idea and best practise is, however I seem to miss > something. I don't understand why you wouldn't want to have > keepalived to set the preferred_lft to zero when bringing up the > VIP's, or actually what I don't understand is how to make various > checks work with the source-address beeing the VIP and not the > "iron-address". > > So, here's the simple configuration, > > # keepalived.conf, > global_defs { > notification_email_from foo at bar.com > smtp_server bar.com > smtp_connect_timeout 30 > lvs_id ER-TST-LD-MASTER > } > > vrrp_instance VI_1 { > state MASTER > interface eth0 > lvs_sync_daemon_interface eth0 > virtual_router_id 56 > priority 150 > advert_int 1 > smtp_alert > authentication { > auth_type PASS > auth_pass example > } > virtual_ipaddress { > XXXX:XXX:XXX:XXXX::46 > } > } > > virtual_server XXXX:XXX:XXX:XXXX::46 0 { > delay_loop 10 > lb_algo rr > lb_kind DR > persistence_timeout 900 > protocol TCP > real_server XXXX:XXX:XXX:XXXX::17 0 { > weight 1 > inhibit_on_failure > MISC_CHECK { > misc_path "/etc/keepalived/check_tcp -H > XXXX:XXX:XXX:XXXX::17 -p 21" misc_timeout 30 > } > } > } > # end keepalived.conf > > > So, this would mean that when keepalived performs the check to see if > the realserver (XX:17 on port 21) is alive, the source-address of > that packet is the VIP (XX:46), which of course also is up on the > realserver, which in turns would mean that the packet never returns > to keepalived. And thus making keepalived to mark the realserver as > down (since it doesnt get any reply). > > So, what I'm I missing here, how is this suppose to work ? > > I've been trying to read the following discussions, they seem to have > the same problem, > http://www.ietf.org/mail-archive/web/v6ops/current/msg15266.html > http://marc.info/?l=keepalived-devel&m=130200733315039 (there's a > patch that would make sense to me, but never got accepted if I'm not > mistaken) I'm using keepalived on RHEL6 with IPv6 just fine, for both VRRP and LVS. The main differences I see with your setup is that I'm using RFC4193 addresses on my private LAN (eth1), that it's for a single port (80) and that I'm using the HTTP_GET check. I'm also using FWM instead of the IPv6 address for the virtual server, but I don't think that's relevant. Here's my ipvsadm -L -n output : FWM 2 IPv6 wrr persistent 4 -> [fdcd:24cd:315e:13::201]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::202]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::203]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::204]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::205]:80 Route 100 0 0 Here's my VRRP configuration : vrrp_instance vlb1 { state MASTER priority 100 virtual_router_id 245 interface eth1 advert_int 2 authentication { auth_type PASS auth_pass foo } virtual_ipaddress { x.x.229.245/26 dev eth0 label eth0:245 x:x:4020:b010::245/64 dev eth0 } } And the start of the LVS configuration : ! Firewall mark 2 LVS (IPv6) virtual_server fwmark 2 { delay_loop 3 lb_algo wrr lb_kind DR protocol TCP persistence_timeout 4 real_server fdcd:24cd:315e:13::201 80 { weight 100 ! inhibit_on_failure HTTP_GET { url { path /my/path/to/info.php status_code 200 } connect_timeout 3 nb_get_retry 2 delay_before_retry 1 } } [...] } If I were you, I'd start tcpdump'ing traffic to check what's going on with that port 21 check. Also, I don't think the check will be done with a source address set to the virtual_server address, but with the main IPv6 address (at least by default, I think). Why do you want the checks to be done with the virtual_server address as the source to begin with? I can only think of possible issues with that, with no real gain. And FWIW, this is the version I'm currently running : keepalived-1.2.7-3.el6.x86_64 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 gianluca.cecchi at gmail.com Wed Jun 26 12:46:55 2013 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 26 Jun 2013 14:46:55 +0200 Subject: [rhelv6-list] rdblacklist during install persists into installed system Message-ID: Hello, during install of rh el 6.3 I want to blacklist my san devices. So I use the new option in 6.x anaconda rdblacklist=qla2xxx that works ok. But I see that it understands I want to blacklist it forever, also on the installed system. In fact the qla2xxx module is not automatically loaded, even if I have multipathd enabled. I can manually load the module after boot and then see my san disks correctly assembled by multipath daemon. It seems no particular option is in neither grub.conf or modprobe.conf or modprobe.d directory. Any file to modify to re-enable this automatic loading before re-creating initramfs file (if necessary at all, as I see the qla2xxx is indeed in initramfs file)? Thanks in advance, Gianluca From bsawyers at vt.edu Wed Jun 26 12:52:27 2013 From: bsawyers at vt.edu (Brandon Sawyers) Date: Wed, 26 Jun 2013 08:52:27 -0400 Subject: [rhelv6-list] rdblacklist during install persists into installed system In-Reply-To: References: Message-ID: I'm not sure about rdblacklist, but I use blacklist=qla2xxx and it adds a line in /etc/modprobe.d/anaconda.conf. Double check there? Do those two options work differently? Hope this helps. On Wed, Jun 26, 2013 at 8:46 AM, Gianluca Cecchi wrote: > Hello, > during install of rh el 6.3 I want to blacklist my san devices. > So I use the new option in 6.x anaconda > > rdblacklist=qla2xxx > > that works ok. > But I see that it understands I want to blacklist it forever, also on > the installed system. > In fact the qla2xxx module is not automatically loaded, even if I have > multipathd enabled. > > I can manually load the module after boot and then see my san disks > correctly assembled by multipath daemon. > > It seems no particular option is in neither grub.conf or modprobe.conf > or modprobe.d directory. > Any file to modify to re-enable this automatic loading before > re-creating initramfs file (if necessary at all, as I see the qla2xxx > is indeed in initramfs file)? > > Thanks in advance, > Gianluca > > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > -- Brandon Sawyers Systems Engineer NIS & Systems Support bsawyers at vt.edu -------------- next part -------------- An HTML attachment was scrubbed... URL: From jburke at redhat.com Wed Jun 26 13:08:36 2013 From: jburke at redhat.com (Jeffrey Burke) Date: Wed, 26 Jun 2013 09:08:36 -0400 (EDT) Subject: [rhelv6-list] rdblacklist during install persists into installed system In-Reply-To: References: Message-ID: <882231645.91544406.1372252116871.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Gianluca Cecchi" > To: "Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list" > Sent: Wednesday, June 26, 2013 8:46:55 AM > Subject: [rhelv6-list] rdblacklist during install persists into installed system > > Hello, > during install of rh el 6.3 I want to blacklist my san devices. > So I use the new option in 6.x anaconda > > rdblacklist=qla2xxx > > that works ok. > But I see that it understands I want to blacklist it forever, also on > the installed system. > In fact the qla2xxx module is not automatically loaded, even if I have > multipathd enabled. > > I can manually load the module after boot and then see my san disks > correctly assembled by multipath daemon. > > It seems no particular option is in neither grub.conf or modprobe.conf > or modprobe.d directory. > Any file to modify to re-enable this automatic loading before > re-creating initramfs file (if necessary at all, as I see the qla2xxx > is indeed in initramfs file)? > > Thanks in advance, > Gianluca > Gianlica, Paul had done a write up on how this seemed to work in RHEL6. Here is a link. https://home.corp.redhat.com/wiki/blacklist-module Thanks, Jeff > _______________________________________________ > rhelv6-list mailing list > rhelv6-list at redhat.com > https://www.redhat.com/mailman/listinfo/rhelv6-list > From gianluca.cecchi at gmail.com Wed Jun 26 13:32:03 2013 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 26 Jun 2013 15:32:03 +0200 Subject: [rhelv6-list] rdblacklist during install persists into installed system In-Reply-To: <882231645.91544406.1372252116871.JavaMail.root@redhat.com> References: <882231645.91544406.1372252116871.JavaMail.root@redhat.com> Message-ID: On Wed, Jun 26, 2013 at 3:08 PM, Jeffrey Burke wrote: > Gianlica, > Paul had done a write up on how this seemed to work in RHEL6. Here is a > link. > https://home.corp.redhat.com/wiki/blacklist-module > > Thanks, > Jeff Hi Jeff, Unfortunately I can't access corp.redhat.com web link: possibly dedicated only to RH employees... But it was as Brandon wrote... I missed the anaconda.conf file in modprobe.d. After commenting out the entry created during install in it: # Module options and blacklists written by anaconda blacklist qla2xxx after reboot all is ok. I don't know exactly what is the difference between rdblacklist and blacklist options. I found the former inside docs so I used that. Thanks, Gianluca From jburke at redhat.com Wed Jun 26 13:52:41 2013 From: jburke at redhat.com (Jeffrey Burke) Date: Wed, 26 Jun 2013 09:52:41 -0400 (EDT) Subject: [rhelv6-list] rdblacklist during install persists into installed system In-Reply-To: References: <882231645.91544406.1372252116871.JavaMail.root@redhat.com> Message-ID: <1224677095.91669964.1372254761374.JavaMail.root@redhat.com> ----- Original Message ----- > From: "Gianluca Cecchi" > To: "Red Hat Enterprise Linux 6 (Santiago) discussion mailing-list" > Sent: Wednesday, June 26, 2013 9:32:03 AM > Subject: Re: [rhelv6-list] rdblacklist during install persists into installed system > > On Wed, Jun 26, 2013 at 3:08 PM, Jeffrey Burke wrote: > > > Gianlica, > > Paul had done a write up on how this seemed to work in RHEL6. Here is a > > link. > > https://home.corp.redhat.com/wiki/blacklist-module > > > > Thanks, > > Jeff > > Hi Jeff, > Unfortunately I can't access corp.redhat.com web link: possibly > dedicated only to RH employees... > But it was as Brandon wrote... I missed the anaconda.conf file in modprobe.d. > After commenting out the entry created during install in it: > > # Module options and blacklists written by anaconda > blacklist qla2xxx > > after reboot all is ok. > > I don't know exactly what is the difference between rdblacklist and > blacklist options. > I found the former inside docs so I used that. > Thanks, > Gianluca > My apologies. I got my lists mixed up. I did not mean to send an internal link to an external list. -------------- next part -------------- A non-text attachment was scrubbed... Name: bl.odt Type: application/vnd.oasis.opendocument.text Size: 14663 bytes Desc: not available URL: From patrik.martinsson at smhi.se Thu Jun 27 10:52:35 2013 From: patrik.martinsson at smhi.se (Martinsson Patrik) Date: Thu, 27 Jun 2013 10:52:35 +0000 Subject: [rhelv6-list] Red Hat 6.4, keepalived and ipv6 In-Reply-To: <20130625123107.52d405e0@r2d2.marmotte.net> References: , <20130625123107.52d405e0@r2d2.marmotte.net> Message-ID: Hi Matthias, Thanks for getting back to me regarding keepalived and ipv6, and sharing your configuration. >> If I were you, I'd start tcpdump'ing traffic to check what's going on with that port 21 check. Also, I don't think the check will be done with a source address set to the virtual_server-address, but with the main IPv6 address (at least by default, I think). Well, that's just the thing, I've already done that. And those dumps are showing me that the source address *is* set to the virtual-server-address, not the "main"-address. And from what I understand, there is a simple and logical explanation to this, which is basically that the source-address of the outgoing traffic is going to be the address of the "last added address", and that is the virtual-server-address brought up by keepalived. There is from what I understand rules about the source-address-selection on ipv6, you can read about it here http://www.davidc.net/networking/ipv6-source-address-selection-linux . And as you can see, if none of the criterias are fulfilled the source-address is going to be the last one added (which then again, is the virtual-server-address brought up by keepalived). So, the way I see it (and please correct me if I'm wrong), keepalived should set 'preferred_lft' to 0 (or at least provide an option to do it if you want) on all ipv6-virtual-addresses it brings up. This will mark the address as deprecated and thus it wont be used as a source address (you'll still be able to receive packets on that address of course). And, there is a patch for this posted at http://marc.info/?l=keepalived-devel&m=130200733315039 but for some reason it never got accepted. >> Why do you want the checks to be done with the virtual_server address as the source to begin with? I can only think of possible issues with that, with no real gain. That's exactly what I *NOT* want. But that's currently what's happening if you use the configuration I posted (have you used tcp-dump to check what the source-address of the packets are on the http-check you are using, if you have not manually set the preferred_lft to 0 on the virtual-server-address, and that interface is the one brought up last, the source-address should be the virtual-server-address.) So, what's happening in my case is that the check never returns, since the source-address of the check_tcp is the virtual-address brought up by keepalived (and that src-address is also on loopback-interface on the real-server). Here is picture of how it is today, and how it's suppose to work (at least to my understanding), http://i.imgur.com/cIGr4wI.png Best regards, Patrik Martinsson ITi SMHI Telefon 011 - 495 84 17 Fax 011 - 495 83 50 Mobil 011 - 495 84 17 Epost Patrik.Martinsson at smhi.se 601 76 Norrk?ping Bes?ksadress Folkborgsv?gen 1 www.smhi.se ________________________________________ From: rhelv6-list-bounces at redhat.com [rhelv6-list-bounces at redhat.com] on behalf of Matthias Saou [matthias at saou.eu] Sent: Tuesday, June 25, 2013 12:31 To: rhelv6-list at redhat.com Subject: Re: [rhelv6-list] Red Hat 6.4, keepalived and ipv6 On Mon, 24 Jun 2013 20:45:12 +0000 Martinsson Patrik wrote: > Hello, > > This is not a specific Red Hat 6 question, but there seems to be a > lot of people with general knowledge here so I'm going to take my > chances. Already tried keepalived-mailinglist but no answer. > > > I'm really trying to understand how keepalived handles ipv6 VIP's and > what's the general idea and best practise is, however I seem to miss > something. I don't understand why you wouldn't want to have > keepalived to set the preferred_lft to zero when bringing up the > VIP's, or actually what I don't understand is how to make various > checks work with the source-address beeing the VIP and not the > "iron-address". > > So, here's the simple configuration, > > # keepalived.conf, > global_defs { > notification_email_from foo at bar.com > smtp_server bar.com > smtp_connect_timeout 30 > lvs_id ER-TST-LD-MASTER > } > > vrrp_instance VI_1 { > state MASTER > interface eth0 > lvs_sync_daemon_interface eth0 > virtual_router_id 56 > priority 150 > advert_int 1 > smtp_alert > authentication { > auth_type PASS > auth_pass example > } > virtual_ipaddress { > XXXX:XXX:XXX:XXXX::46 > } > } > > virtual_server XXXX:XXX:XXX:XXXX::46 0 { > delay_loop 10 > lb_algo rr > lb_kind DR > persistence_timeout 900 > protocol TCP > real_server XXXX:XXX:XXX:XXXX::17 0 { > weight 1 > inhibit_on_failure > MISC_CHECK { > misc_path "/etc/keepalived/check_tcp -H > XXXX:XXX:XXX:XXXX::17 -p 21" misc_timeout 30 > } > } > } > # end keepalived.conf > > > So, this would mean that when keepalived performs the check to see if > the realserver (XX:17 on port 21) is alive, the source-address of > that packet is the VIP (XX:46), which of course also is up on the > realserver, which in turns would mean that the packet never returns > to keepalived. And thus making keepalived to mark the realserver as > down (since it doesnt get any reply). > > So, what I'm I missing here, how is this suppose to work ? > > I've been trying to read the following discussions, they seem to have > the same problem, > http://www.ietf.org/mail-archive/web/v6ops/current/msg15266.html > http://marc.info/?l=keepalived-devel&m=130200733315039 (there's a > patch that would make sense to me, but never got accepted if I'm not > mistaken) I'm using keepalived on RHEL6 with IPv6 just fine, for both VRRP and LVS. The main differences I see with your setup is that I'm using RFC4193 addresses on my private LAN (eth1), that it's for a single port (80) and that I'm using the HTTP_GET check. I'm also using FWM instead of the IPv6 address for the virtual server, but I don't think that's relevant. Here's my ipvsadm -L -n output : FWM 2 IPv6 wrr persistent 4 -> [fdcd:24cd:315e:13::201]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::202]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::203]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::204]:80 Route 100 0 0 -> [fdcd:24cd:315e:13::205]:80 Route 100 0 0 Here's my VRRP configuration : vrrp_instance vlb1 { state MASTER priority 100 virtual_router_id 245 interface eth1 advert_int 2 authentication { auth_type PASS auth_pass foo } virtual_ipaddress { x.x.229.245/26 dev eth0 label eth0:245 x:x:4020:b010::245/64 dev eth0 } } And the start of the LVS configuration : ! Firewall mark 2 LVS (IPv6) virtual_server fwmark 2 { delay_loop 3 lb_algo wrr lb_kind DR protocol TCP persistence_timeout 4 real_server fdcd:24cd:315e:13::201 80 { weight 100 ! inhibit_on_failure HTTP_GET { url { path /my/path/to/info.php status_code 200If I were you, I'd start tcpdump'ing traffic to check what's going on with that port 21 check. Also, I don't think the check will be done with a source address set to the virtual_server address, but with the main IPv6 address (at least by default, I think). Why do you want the checks to be done with the virtual_server address as the source to begin with? I can only think of possible issues with that, with no real gain. And FWIW, this is the version I'm currently running : keepalived-1.2.7-3.el6.x86_64 } connect_timeout 3 nb_get_retry 2 delay_before_retry 1 } } [...] } If I were you, I'd start tcpdump'ing traffic to check what's going on with that port 21 check. Also, I don't think the check will be done with a source address set to the virtual_server address, but with the main IPv6 address (at least by default, I think). Why do you want the checks to be done with the virtual_server address as the source to begin with? I can only think of possible issues with that, with no real gain. And FWIW, this is the version I'm currently running : keepalived-1.2.7-3.el6.x86_64 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 ???? ???? _______________________________________________ rhelv6-list mailing list rhelv6-list at redhat.com https://www.redhat.com/mailman/listinfo/rhelv6-list From matthias at saou.eu Thu Jun 27 14:07:09 2013 From: matthias at saou.eu (Matthias Saou) Date: Thu, 27 Jun 2013 16:07:09 +0200 Subject: [rhelv6-list] Red Hat 6.4, keepalived and ipv6 In-Reply-To: References: <20130625123107.52d405e0@r2d2.marmotte.net> Message-ID: <20130627160709.7a59e01b@r2d2.marmotte.net> On Thu, 27 Jun 2013 10:52:35 +0000 Martinsson Patrik wrote: > Hi Matthias, > > Thanks for getting back to me regarding keepalived and ipv6, and > sharing your configuration. > > >> If I were you, I'd start tcpdump'ing traffic to check what's going > >> on with that port 21 check. Also, I don't think the check will be > >> done with a source address set to the virtual_server-address, but > >> with the main IPv6 address (at least by default, I think). > Well, that's just the thing, I've already done that. And those dumps > are showing me that the source address *is* set to the > virtual-server-address, not the "main"-address. And from what I > understand, there is a simple and logical explanation to this, which > is basically that the source-address of the outgoing traffic is going > to be the address of the "last added address", and that is the > virtual-server-address brought up by keepalived. There is from what I > understand rules about the source-address-selection on ipv6, you can > read about it here > http://www.davidc.net/networking/ipv6-source-address-selection-linux . > And as you can see, if none of the criterias are fulfilled the > source-address is going to be the last one added (which then again, > is the virtual-server-address brought up by keepalived). > > So, the way I see it (and please correct me if I'm wrong), keepalived > should set 'preferred_lft' to 0 (or at least provide an option to do > it if you want) on all ipv6-virtual-addresses it brings up. This will > mark the address as deprecated and thus it wont be used as a source > address (you'll still be able to receive packets on that address of > course). And, there is a patch for this posted at > http://marc.info/?l=keepalived-devel&m=130200733315039 but for some > reason it never got accepted. > > >> Why do you want the checks to be done with the virtual_server > >> address as the source to begin with? I can only think of possible > >> issues with that, with no real gain. > That's exactly what I *NOT* want. But that's currently what's > happening if you use the configuration I posted (have you used > tcp-dump to check what the source-address of the packets are on the > http-check you are using, if you have not manually set the > preferred_lft to 0 on the virtual-server-address, and that interface > is the one brought up last, the source-address should be the > virtual-server-address.) > > So, what's happening in my case is that the check never returns, > since the source-address of the check_tcp is the virtual-address > brought up by keepalived (and that src-address is also on > loopback-interface on the real-server). Here is picture of how it is > today, and how it's suppose to work (at least to my understanding), > http://i.imgur.com/cIGr4wI.png All this makes sense, and it's easy to understand why my setup works : My checks are being made using the RFC4193 IPv6 addresss of the IPv6 network I use on my private LAN. My LVS real servers are referenced in the configuration with these addresses and all my servers have addresses on that network. The address which is managed by keepalived and used for LVS is only on the LVS server's public interface and on the real servers' loopback. Check the configuration I posted again. The fdcd:24cd:315e:13::/64 network is really the one I use locally for IPv6, in addition to 192.168.13.0/24 for IPv4 on the same "private LAN" segment. I did run into the same issues as you at some point, but didn't remember them at first. It's mostly coming back to me now, and I think it's exactly why I switched to using a "proper" local-only IPv6 addressing for LVS-DR. That same behavior also affects puppet's facter, where the main IPv6 address reported for a server is the keepalived-managed one (the last one added). I hope this clears things up, and by using RFC4193 addresses, you should be able to get something working! 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 ???? ????