Re: SL vs. CentOS vs. RH EL qualification testing
On 07/23/2011 05:54 PM, Alec T. Habig wrote: Yasha Karant writes: Although the future is unclear for Fermilab with the imminent decommissioning of the Fermilab accelerator, this professional status currently is correct. Correction - one beamline (the tevatron) and associated experiments are ending. The rest of the accelerator complex and associated experiments (not to mention the non-accelerator based stuff) are humming right along, new experiments coming online, etc. I believe there is some danger of what the lists term a "flame war" from this discussion -- that is not the point nor my intention. With no disrespect (and not being a Troll -- the decision of which Linux operating environment and distribution to use is one that requires data or, lacking that, anecdotal experience), Wikipedia states the following: http://en.wikipedia.org/wiki/Fermilab Current developments [edit] The end of the Tevatron Run On January 10, 2011 it was announced that the Tevatron Accelerator had failed to find additional funding to continue operation beyond the close of fiscal year 2011 (October 2011).[10] [edit] Financial situation The Fermilab budget has been continuously below inflation over the last several years, and Fermilab failed to attract more funding sources and this resulted in reducing staff levels (by 100 in 2005).[11] The new director of the lab and the new management are working hard to bring the International Linear Collider (ILC) to Fermilab. However, the decision by Congress to fund the ILC at only a quarter of the requested $60 million significantly reduces the chances that Fermilab or any other U.S. research facility will host the ILC. Due to Fermilab's financial situation, on December 20, 2007, director Piermaria Oddone announced the planned layoffs of 10% of Fermilab's staff. End quote. Although the experimental facilities you mention are ongoing, the issue of long term funding of fundamental physics (or fundamental science without immediate practical application -- the genetic science and engineering fields are fundamental biology and medicine, but are also have immediate practical application -- going beyond/fixing the Standard Model lacks such applications) is highly unresolved in the USA under the Republican Tea Party model -- and has been declining for a number of years. This issue is not a SL or Linux issue, but merely a comment on the longer term stability of SL as being developed by paid professionals (from Wikipedia: this resulted in reducing staff levels (by 100 in 2005)). The situation at CERN is less bleak, even given the financial problems of the EU and Euro/Eurozone, from colleagues I know in various EU nations, some of whom are in CERN collaborations. This list is not the appropriate place to attempt to convince Tea Party Republicans and Social Program Democrats to maintain public funding (investment) in fundamental physics. However, the practical ramifications of such de-funding may have implications for the Fermilab portion of SL support. I am not trying to be grim, negative, derogatory, Troll, or anything else -- merely discussing the present facts and a possible several year future. I certainly hope that Fermilab/CERN will continue to assign / allow to work with pay professionals to redistribute RHEL and to support both enhancements and bug fixes to RHEL, rebadged as SL.
Re: SL vs. CentOS vs. RH EL qualification testing
Use what works, ignore all of the stuff and rumors that surround the distro's. That's the FreeSWITCH mantra - use what works. On Sat, Jul 23, 2011 at 5:54 PM, Alec T. Habig wrote: > Yasha Karant writes: >> Although the future is unclear for Fermilab with the imminent >> decommissioning of the Fermilab accelerator, this professional status >> currently is correct. > > Correction - one beamline (the tevatron) and associated experiments are > ending. The rest of the accelerator complex and associated experiments > (not to mention the non-accelerator based stuff) are humming right > along, new experiments coming online, etc. > > -- > Alec Habig, University of Minnesota Duluth Physics Dept. > ha...@neutrino.d.umn.edu > http://neutrino.d.umn.edu/~habig/ >
Re: SL vs. CentOS vs. RH EL qualification testing
Yasha Karant writes: > Although the future is unclear for Fermilab with the imminent > decommissioning of the Fermilab accelerator, this professional status > currently is correct. Correction - one beamline (the tevatron) and associated experiments are ending. The rest of the accelerator complex and associated experiments (not to mention the non-accelerator based stuff) are humming right along, new experiments coming online, etc. -- Alec Habig, University of Minnesota Duluth Physics Dept. ha...@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/
Re: bind error: none:0: open: /etc/named.conf: permission denied
On 07/23/2011 08:25 AM, Nico Kadel-Garcia wrote: On Sat, Jul 23, 2011 at 2:14 AM, Todd And Margo Chester wrote: On 07/22/2011 10:41 PM, Nico Kadel-Garcia wrote: Youve got named running in the chrooted environment in /var/named/chroot. Yank out the bind-chroot package for now, restorie it when you've had a chance to read and review the documentaiton. Hi Nico, When I had originally ported, I copied the computer directory tree /var/named/chroot This looks like part of your problem. When you "copied" it, did your copying preserve ownership of all the files? Did you use tar, rsync, scp, or what? tar over from the old computer. I did not have bind-chroot installed, so of course, bind could not find anything. Then I remembered chroot, so I yum'ed bind-chroot. But you'd already copied over the material, and probably tried to merge /etc/named contents on top of your already written material. Chaos ensued. I got stuck on /usr/sbin/named-checkconf -z -t /var/named/chroot /etc/named.conf working from the command line, but not from /etc/rc.d/init.d/named I do believe my next step will be what you and William suggested: start without bind-chroot and everything in its normal location. Then upgrade to bind-chroot Thank you for the help. I will let everyone know what happens. Do take a look at what the bind-chroot package does. It's mostly a bunch of '%post" scripts in the RPM installation. Thank you, -T
Re: need modprobe.d syntax help
On 07/23/2011 10:09 AM, Tom H wrote: It's interesting that ip_nat_ftp cannot be loaded through "/etc/sysconfig/iptables-config" because it can be modprobe'd. I guess that whatever mechanism's used to load a module alias isn't available yet. Hi Tom, Once I figured out my quote mistake, I never retried ip_nat_ftp: I stuck with nf_nat_ftp. So, my guess, is that ip_nat_ftp would have loaded properly too. I believe lsmod shows nf instead of ip, so that is what I was missing in my analysis. Thank you for help! -T
Re: SL vs. CentOS vs. RH EL qualification testing
On Sat, Jul 23, 2011 at 2:28 PM, John H. Outlan CPA wrote: > Sent from T-Mobile G2, please excuse any typos > On Jul 23, 2011 1:15 PM, "Yasha Karant" wrote: >> >> A vendor professional systems person whom I know has been requested to >> install SL 6 on a system that is being configured for us. In a discussion >> with him, he gave me the opinion that his (vendor's) experience with SL is >> that it is "buggier" than CentOS, and CentOS often "fixes" RHEL bugs. I did >> not understand this in that the base distribution without extensions of both >> CentOS and SL is RHEL with only the artwork being changed in the sense that >> all RedHat logos or use of RedHat licensed-for-fee binary distribution >> repositories have been removed, replaced by the appropriate entities for the >> distribution in question. Red Hat is required to release full source from >> which the entire distribution can be built for personal use -- but not >> redistributed without removal of the RedHat copyrighted logos, etc. -- under >> the GPL, Linux licenses, etc. >> >> Nonetheless, he is of the opinion that CentOS does the best job of testing >> the distribution in pre-CentOS release -- although both start from the RHEL >> sources. I commented that SL is professionally supported by a joint >> Fermilab-CERN effort with paid professionals doing the work, not the more or >> less volunteer organization of CentOS, just as the Red Hat source is >> developed by paid professionals. Although the future is unclear for >> Fermilab with the imminent decommissioning of the Fermilab accelerator, this >> professional status currently is correct. >> >> I fully understand that individuals may disagree with the opinion, and >> that specific organizations may have official statements that disagree with >> the opinion -- I only am interested in the "facts". For anyone on this list >> who is familiar with the post-RH release handling and qualification/testing >> procedures of RHEL source by either or both organizations, or by the >> Princeton University distribution of RHEL, direct comments would be >> appreciated. Is there any factual data, including procedural differences, >> to support the opinion that I have been given? >> >> Yasha Karant > > My opinion basically is that CentOS has proved itself slow to update in the > last year but if I may ask: > > Who told you FNAL was being "decommsioned". There are at least three FNAL > employees on this list who can respond to that :) I've heard no such thing. > Maybe you are confusing it with the Space Shuttle :) > > Oh. SL is not "buggier" than CentOS. In fact someone on the CentOS forum > stated they had problems with ver 6.0 and wouldn't install until 6.1 was > released. I don't have the details of that statement or don't know if its > purely oparator errors > > Others here I'm sure can shine more light on your concerns. Yasha's just being a troll...
Re: SL vs. CentOS vs. RH EL qualification testing
On 07/24/2011 02:14 AM, Yasha Karant wrote: A vendor professional systems person whom I know has been requested to install SL 6 on a system that is being configured for us. In a discussion with him, he gave me the opinion that his (vendor's) experience with SL is that it is "buggier" than CentOS, and CentOS often "fixes" RHEL bugs. They both fix bugs when found and both communities are fairly good at pushing those fixes upstream. I find the documentation of bugs in SL more concise and helpful than in CentOS (seems the ones submitting bugs are less prone to freaking out at their computers or submitting SWAGs to bug trackers). There is definitely less hand-holding within the community -- and a lot fewer requests for hand-holding from what I've observed. For anyone on this list who is familiar with the post-RH release handling and qualification/testing procedures of RHEL source by either or both organizations, or by the Princeton University distribution of RHEL, direct comments would be appreciated. Is there any factual data, including procedural differences, to support the opinion that I have been given? I am not aware of any actual test data that compares the various RHEL derived distros under any stress in a meaningful way (are you volunteering?). I have deployed RHEL6, SL6 and just recently toyed with CentOS6 test deployments, and found not enough difference to warrant including CentOS in my thinking for now (for non-technical types with deadlines RHEL is worth the money, though). Anyway, CentOS 6 was just released the other day -- it hasn't been out long enough to compare or for deep, weird problems to be uncovered yet; SL6 is fairly well understood at this point. But, name recognition alone goes a long way to framing most people's interpretation of software (and other things), so bear that in mind when listening to people. From a non-technical perspective, however, there is a huge difference. The SL6 community has far fewer knotheads than the CentOS community, and accordingly less drama. It also feels easier to find things, though I'm not quite sure why (fewer meaningless articles laying about?). In fact, I've never had to ask a question on list before. SL is therefore considerably less buggy as a community. The frustration index is a lot lower with SL6 in other than social ways. The development and release process is a lot less mysterious than CentOS, for example, and this makes planning a little easier. tl;dr: No hard data to support your friend's claim. SL6 is lower on the stress & drama scale. -Iwao
Re: SL vs. CentOS vs. RH EL qualification testing
Sent from T-Mobile G2, please excuse any typos On Jul 23, 2011 1:15 PM, "Yasha Karant" wrote: > > A vendor professional systems person whom I know has been requested to install SL 6 on a system that is being configured for us. In a discussion with him, he gave me the opinion that his (vendor's) experience with SL is that it is "buggier" than CentOS, and CentOS often "fixes" RHEL bugs. I did not understand this in that the base distribution without extensions of both CentOS and SL is RHEL with only the artwork being changed in the sense that all RedHat logos or use of RedHat licensed-for-fee binary distribution repositories have been removed, replaced by the appropriate entities for the distribution in question. Red Hat is required to release full source from which the entire distribution can be built for personal use -- but not redistributed without removal of the RedHat copyrighted logos, etc. -- under the GPL, Linux licenses, etc. > > Nonetheless, he is of the opinion that CentOS does the best job of testing the distribution in pre-CentOS release -- although both start from the RHEL sources. I commented that SL is professionally supported by a joint Fermilab-CERN effort with paid professionals doing the work, not the more or less volunteer organization of CentOS, just as the Red Hat source is developed by paid professionals. Although the future is unclear for Fermilab with the imminent decommissioning of the Fermilab accelerator, this professional status currently is correct. > > I fully understand that individuals may disagree with the opinion, and that specific organizations may have official statements that disagree with the opinion -- I only am interested in the "facts". For anyone on this list who is familiar with the post-RH release handling and qualification/testing procedures of RHEL source by either or both organizations, or by the Princeton University distribution of RHEL, direct comments would be appreciated. Is there any factual data, including procedural differences, to support the opinion that I have been given? > > Yasha Karant My opinion basically is that CentOS has proved itself slow to update in the last year but if I may ask: Who told you FNAL was being "decommsioned". There are at least three FNAL employees on this list who can respond to that :) I've heard no such thing. Maybe you are confusing it with the Space Shuttle :) Oh. SL is not "buggier" than CentOS. In fact someone on the CentOS forum stated they had problems with ver 6.0 and wouldn't install until 6.1 was released. I don't have the details of that statement or don't know if its purely oparator errors Others here I'm sure can shine more light on your concerns.
SL vs. CentOS vs. RH EL qualification testing
A vendor professional systems person whom I know has been requested to install SL 6 on a system that is being configured for us. In a discussion with him, he gave me the opinion that his (vendor's) experience with SL is that it is "buggier" than CentOS, and CentOS often "fixes" RHEL bugs. I did not understand this in that the base distribution without extensions of both CentOS and SL is RHEL with only the artwork being changed in the sense that all RedHat logos or use of RedHat licensed-for-fee binary distribution repositories have been removed, replaced by the appropriate entities for the distribution in question. Red Hat is required to release full source from which the entire distribution can be built for personal use -- but not redistributed without removal of the RedHat copyrighted logos, etc. -- under the GPL, Linux licenses, etc. Nonetheless, he is of the opinion that CentOS does the best job of testing the distribution in pre-CentOS release -- although both start from the RHEL sources. I commented that SL is professionally supported by a joint Fermilab-CERN effort with paid professionals doing the work, not the more or less volunteer organization of CentOS, just as the Red Hat source is developed by paid professionals. Although the future is unclear for Fermilab with the imminent decommissioning of the Fermilab accelerator, this professional status currently is correct. I fully understand that individuals may disagree with the opinion, and that specific organizations may have official statements that disagree with the opinion -- I only am interested in the "facts". For anyone on this list who is familiar with the post-RH release handling and qualification/testing procedures of RHEL source by either or both organizations, or by the Princeton University distribution of RHEL, direct comments would be appreciated. Is there any factual data, including procedural differences, to support the opinion that I have been given? Yasha Karant
Re: need modprobe.d syntax help
On Fri, Jul 22, 2011 at 8:32 PM, Todd And Margo Chester wrote: > On 07/15/2011 08:14 PM, Katherine Lim wrote: > > On Sat, Jul 16, 2011 at 1:09 PM, Todd And Margo Chester > wrote: >> >> On 07/15/2011 07:31 PM, William Scott wrote: >>> >>> On 16 July 2011 11:50, Todd And Margo Chester >>> wrote: Hi All, Not having a good time researching this in Google, unless I want to do it in Ubuntu. I am trying to make the following command permanent: modprobe ip_nat_ftp >>> >>> Have a look in /etc/sysconfig/iptables-config >>> >> I should have said I am running SL6 x64. >> >> It is there. But, running /etc/rc.d/init.d/iptables throws an >> error on ip_nat_ftp if I do not previously load ip_nat_ftp >> with modprobe. >> >> What I am after is to load ip_nat_ftp at boot time with >> modprobe.d. >> >> A tape and gum approach would be to load ip_nat_ftp >> in /etc/rc.d/init.d/iptables before it did anything with >> /etc/sysconfig/iptables-config, but I really would like >> to learn the right way to do it in modprobe.d. >> >> -T > > > Did you get any errors after editing the IPTABLES_MODULES line in > /etc/sysconfig/iptables-config to: > IPTABLES_MODULES="ip_nat_ftp" > > On 07/15/2011 10:13 PM, Tom H wrote: > > >From a colleague working on our RHEL 6 deployment (similar to F14/F15): > > root # vi /etc/sysconfig/modules/ip_nat_ftp.modules > #!/bin/sh > exec /sbin/modprobe ip_nat_ftp > root # chmod +x /etc/sysconfig/modules/ip_nat_ftp.modules > > Perhaps you should also start using the new name, nf_nat_ftp (although > its alias, ip_nat_ftp, the previous name, still works). > > Hi Guys, > > Okay. I probably need to come clean on this. > > 1) ip_nat_ftp was not loaded at boot, but nf_nat_ftp was. > > 2) Tom's method of loading a module at boot time worked perfectly. > > 3) the error when running /etc/rc.d/init.d/iptables on both > ip & nf_nat_ftp not loading was my fault. I forgot the quotes > in /etc/sysconfig/iptables-config: > > Bad: IPTABLES_MODULES=ip_conntrack_netbios ns nf_nat_ftp > Good: IPTABLES_MODULES="ip_conntrack_netbios ns nf_nat_ftp" > > When ..init.d/iptables ran its "include" on iptables-config, it > saw nf_nat_ftp as a separate command and not a variable > assignment. > > On the bright side, I did learn how to load a module at > boot time. > > Thank you all for the help (and your patience), You're welcome. I'm glad that loading nf_nat_ftp through "/etc/sysconfig/iptables-config" is working for you. It's the "right" way for loading it; "my" method was just a workaround. It's interesting that ip_nat_ftp cannot be loaded through "/etc/sysconfig/iptables-config" because it can be modprobe'd. I guess that whatever mechanism's used to load a module alias isn't available yet.
Re: Kernel update broke microphone
On Sat, Jul 23, 2011 at 8:40 AM, Phil Perry wrote: > On 23/07/11 16:13, Phil Lembo wrote: >> >> Thanks Phil! >> >> I just tested both alsa kernel mods in epel-testing and found the newer >> one >> (1.0.24-1) didn't fix the problem for me (my hardware uses the even older >> N10/ICH7 chipset), kmod-alsa-1.0.23-1.el6.elrepo did. Given the advantages >> of kAPI-tracking kmods, I'll be sticking with that for now. >> > > Great. > > Yes, newer is not always better for some packages, especially when they > provide multiple kernel modules (e.g, kmod-alsa and kmod-video4linux), hence > why we like to keep a few versions available. Just a note to say that you want to exclude the one to keep in yum.conf so that it does not get updated accidentally. Akemi
Re: Kernel update broke microphone
On 23/07/11 16:13, Phil Lembo wrote: Thanks Phil! I just tested both alsa kernel mods in epel-testing and found the newer one (1.0.24-1) didn't fix the problem for me (my hardware uses the even older N10/ICH7 chipset), kmod-alsa-1.0.23-1.el6.elrepo did. Given the advantages of kAPI-tracking kmods, I'll be sticking with that for now. Great. Yes, newer is not always better for some packages, especially when they provide multiple kernel modules (e.g, kmod-alsa and kmod-video4linux), hence why we like to keep a few versions available.
Re: bind error: none:0: open: /etc/named.conf: permission denied
On Sat, Jul 23, 2011 at 2:14 AM, Todd And Margo Chester wrote: > On 07/22/2011 10:41 PM, Nico Kadel-Garcia wrote: >> Youve got named running in the chrooted environment in >> /var/named/chroot. Yank out the bind-chroot package for now, restorie >> it when you've had a chance to read and review the documentaiton. > > Hi Nico, > > When I had originally ported, I copied the computer directory tree > > /var/named/chroot This looks like part of your problem. When you "copied" it, did your copying preserve ownership of all the files? Did you use tar, rsync, scp, or what? > over from the old computer. I did not have bind-chroot installed, > so of course, bind could not find anything. Then I remembered > chroot, so I yum'ed bind-chroot. But you'd already copied over the material, and probably tried to merge /etc/named contents on top of your already written material. Chaos ensued. > > I got stuck on > > /usr/sbin/named-checkconf -z -t /var/named/chroot /etc/named.conf > > working from the command line, but not from > > /etc/rc.d/init.d/named > > I do believe my next step will be what you and William suggested: > start without bind-chroot and everything in its normal location. Then > upgrade to bind-chroot > > Thank you for the help. I will let everyone know what happens. Do take a look at what the bind-chroot package does. It's mostly a bunch of '%post" scripts in the RPM installation.
Re: Kernel update broke microphone
Thanks Phil! I just tested both alsa kernel mods in epel-testing and found the newer one (1.0.24-1) didn't fix the problem for me (my hardware uses the even older N10/ICH7 chipset), kmod-alsa-1.0.23-1.el6.elrepo did. Given the advantages of kAPI-tracking kmods, I'll be sticking with that for now.
Re: Kernel update broke microphone
You're welcome. On 23/07/11 15:14, Phil Lembo wrote: Excellent! I missed those. Actually a much better solution going forward. On Sat, Jul 23, 2011 at 5:38 AM, Phil Perry wrote: On 22/07/11 23:24, Phil Lembo wrote: I had the very same problem and backed out to kernel-2.6.32-71.29.1 while looking around for a solution. I found an ALSA kernel module on atrpms.net and decided to give it a try. First I updated to kernel-2.6.32-131.6.1.el6.x86_64 (I'm running 64-bit). which once again killed my mic. Then I went up to atrpms.net and grabbed alsa-kmdl-2.6.32-131.6.1.el6.x86_64-1.0.23-86.el6.x86_64 (look in http://packages.atrpms.net/dist/el6/alsa-driver-1.0.23/). After another reboot I found my mic worked again. Phil Lembo http://eldapo.lembobrothers.com Just a note that elrepo.org also has kmod packages for alsa (kmod-alsa) for both el5 and el6. These are kABI tracking packages so will work seamlessly across kernel updates meaning you won't need to update them every time you update your kernel. Hope that helps. Phil
Re: Kernel update broke microphone
On 22/07/11 23:24, Phil Lembo wrote: I had the very same problem and backed out to kernel-2.6.32-71.29.1 while looking around for a solution. I found an ALSA kernel module on atrpms.net and decided to give it a try. First I updated to kernel-2.6.32-131.6.1.el6.x86_64 (I'm running 64-bit). which once again killed my mic. Then I went up to atrpms.net and grabbed alsa-kmdl-2.6.32-131.6.1.el6.x86_64-1.0.23-86.el6.x86_64 (look in http://packages.atrpms.net/dist/el6/alsa-driver-1.0.23/). After another reboot I found my mic worked again. Phil Lembo http://eldapo.lembobrothers.com Just a note that elrepo.org also has kmod packages for alsa (kmod-alsa) for both el5 and el6. These are kABI tracking packages so will work seamlessly across kernel updates meaning you won't need to update them every time you update your kernel. Hope that helps. Phil
