Hi there,
While I was looking "how to disable ipv6 under centos" I have found a gazzillion pages about how to do it and some of then even list things that i am not sure where they came from, so for the record I list most of them here in case someone else need them. Some of the methods involved the direct modification of system scripts, and I am against that so I wont list them here (removing the entire section of ipv6 calls in IFUP is not a good idea).
How to disable ipv6 support in Centos 4.x Pick any method, a combo or all of them
Method 1, add the line: alias net-pf-10 off to the /etc/modprobe.conf
Method 2 Add to /etc/sysconfig/network file: NOZEROCONF=yes # Bonus: Disable the ugly generation of 169.254 zeroconf networks. NETWORKING_IPV6=no
Note about method 2. I must mention the fact that I actually READ the entire ifup script and dependencies and I found that it calls at line 361: # if [ "${NETWORKING_IPV6}" = "yes" ]; then # /etc/sysconfig/network-scripts/ifup-ipv6 ${CONFIG}
However adding the NETWORKING_IPV6=NO has no effect whatsoever because even after a reboot the interfaces continue to load an ipv6 address. BTW it does the same for zeroconf and doesn`t work either.
Method 3: /etc/sysconfig/network-scripts/ifcfg-XXXXX file; IPV6INIT=no
So pick your best method or a combo and let us know which one worked for you: In my case Centos 4.3 2.6.9-34.EL i386 with a pair of 3COM 3c905CX lan boards did not responded to Method 1 and 2 and 3. So I'm still battling with this ipv6 thing.
Let me know your comments.
Cheers,
Hi there,
While I was looking "how to disable ipv6 under centos" I have found a gazzillion pages about how to do it and some of then even list things that i am not sure where they came from, so for the record I list most of them here in case someone else need them. Some of the methods involved the direct modification of system scripts, and I am against that so I wont list them here (removing the entire section of ipv6 calls in IFUP is not a good idea).
How to disable ipv6 support in Centos 4.x Pick any method, a combo or all of them
Method 1, add the line: alias net-pf-10 off to the /etc/modprobe.conf
I use method 1 successfully.
Erick Perez wrote:
Method 1, add the line: alias net-pf-10 off to the /etc/modprobe.conf
This is the right way to do it.
Method 2 Add to /etc/sysconfig/network file: NOZEROCONF=yes # Bonus: Disable the ugly generation of 169.254 zeroconf networks. NETWORKING_IPV6=no
However adding the NETWORKING_IPV6=NO has no effect whatsoever because even after a reboot the interfaces continue to load an ipv6 address. BTW it does the same for zeroconf and doesn`t work either.
It doesn't work on its own since as soon as first IPv6-capable daemon (for example sshd) attempts to bind to the ports, the ipv6 kernel module gets loaded and it will assign all interfaces default link local addresses to all interfaces.
However, do note that apart from deleting ipv6.ko from the disk, there's no good way to get rid of IPv6 for sure. Even with the both of the above, if somebody/something does "modprobe ipv6", the module gets loaded and it does its thing with link local addresses. Once it is loaded it is next to impossible to unload it from the running system.
Aleksandar, can you please explain for me what does a criptic line like "alias net-pf-10 off " means "to disable ipv6" ?
On 9/11/06, Aleksandar Milivojevic alex@milivojevic.org wrote:
Erick Perez wrote:
Method 1, add the line: alias net-pf-10 off to the /etc/modprobe.conf
This is the right way to do it.
Method 2 Add to /etc/sysconfig/network file: NOZEROCONF=yes # Bonus: Disable the ugly generation of 169.254 zeroconf networks. NETWORKING_IPV6=no
However adding the NETWORKING_IPV6=NO has no effect whatsoever because even after a reboot the interfaces continue to load an ipv6 address. BTW it does the same for zeroconf and doesn`t work either.
It doesn't work on its own since as soon as first IPv6-capable daemon (for example sshd) attempts to bind to the ports, the ipv6 kernel module gets loaded and it will assign all interfaces default link local addresses to all interfaces.
However, do note that apart from deleting ipv6.ko from the disk, there's no good way to get rid of IPv6 for sure. Even with the both of the above, if somebody/something does "modprobe ipv6", the module gets loaded and it does its thing with link local addresses. Once it is loaded it is next to impossible to unload it from the running system.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Quoting Erick Perez eaperezh@gmail.com:
Aleksandar, can you please explain for me what does a criptic line like "alias net-pf-10 off " means "to disable ipv6" ?
It disables automatic loading of ipv6 module. You can still manually load it by doint "modprobe ipv6" from command line. This was default setting up until 2.4 kernel. In 2.6 kernel default was changed to automatically load ipv6 module as needed.
If you don'thave the above line in /etc/modprobe.conf, each time an application simply attempts to perform IPv6 bind, the kernel would automatically load ipv6 kernel module. The ipv6 module will assigne link local addresses to all interfaces on the system, and it is practically impossible to get rid of the module from that point on (until you reboot machine).
While link local addresses on the interfaces are not really usable to establish communication on the network, many people prefer not to have them assigned. Especially considering the sorry state of IPv6 version of Netfilter. Not only that IPv6 Netfilter lacks many many features of its IPv4 counterpart, the userspace (iptables-ipv6) is not installed by default on CentOS4, redhat-config-security-level will not configure it, and many people run firewalls that are completely open for IPv6 traffic without even realizing it.
Thanks Alek, that clarifies a lot of things on my shorewall logs ;)
On 9/11/06, Aleksandar Milivojevic alex@milivojevic.org wrote:
Quoting Erick Perez eaperezh@gmail.com:
Aleksandar, can you please explain for me what does a criptic line like "alias net-pf-10 off " means "to disable ipv6" ?
It disables automatic loading of ipv6 module. You can still manually load it by doint "modprobe ipv6" from command line. This was default setting up until 2.4 kernel. In 2.6 kernel default was changed to automatically load ipv6 module as needed.
If you don'thave the above line in /etc/modprobe.conf, each time an application simply attempts to perform IPv6 bind, the kernel would automatically load ipv6 kernel module. The ipv6 module will assigne link local addresses to all interfaces on the system, and it is practically impossible to get rid of the module from that point on (until you reboot machine).
While link local addresses on the interfaces are not really usable to establish communication on the network, many people prefer not to have them assigned. Especially considering the sorry state of IPv6 version of Netfilter. Not only that IPv6 Netfilter lacks many many features of its IPv4 counterpart, the userspace (iptables-ipv6) is not installed by default on CentOS4, redhat-config-security-level will not configure it, and many people run firewalls that are completely open for IPv6 traffic without even realizing it.
-- NOTICE: If you are not intended recipient, you are hereby notified that by reading this message you agreed not to disturb frogs during mating season. For more info, visit http://www.8-P.ca/
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
Regards
Pete
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Sep 11, 2006 at 09:31:28PM +0100, Peter Farrow wrote:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
Just thought I would let you know that it didn't happen on any of my servers updated from 4.3 to 4.4.
Best Regards,
- -- Rodrigo Barbosa "Quid quid Latine dictum sit, altum viditur" "Be excellent to each other ..." - Bill & Ted (Wyld Stallyns)
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Sep 11, 2006 at 09:31:28PM +0100, Peter Farrow wrote:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
Just thought I would let you know that it didn't happen on any of my servers updated from 4.3 to 4.4.
It didn't happen to any of my servers either (thankfully...since some of them are serving DNS for several zones).
Cheers,
At 06:04 PM 9/11/2006, chrism@imntv.com wrote:
Rodrigo Barbosa wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Mon, Sep 11, 2006 at 09:31:28PM +0100, Peter Farrow wrote:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
Just thought I would let you know that it didn't happen on any of my servers updated from 4.3 to 4.4.
It didn't happen to any of my servers either (thankfully...since some of them are serving DNS for several zones).
To be clear, after the update on my systems, BIND still worked fine. It was only the interaction between RNDC and BIND that was a mess. A bit of editing restored functionality. In reality it was mostly just annoyance, but we do have automated scripts that rely heavily on rndc to kick named in various ways, and those all broke.
Cheers,
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
At 04:31 PM 9/11/2006, Peter Farrow wrote:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
This happened on all of my RHEL4 servers with the latest batch of updates. I was not surprised when the same happened to all of my CentOS servers.
Hi There,
yes, I wasn't blaming anybody just letting everyone know so that peeps are aware of it!
Regards
Pete
Daniel Senie wrote:
At 04:31 PM 9/11/2006, Peter Farrow wrote:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
This happened on all of my RHEL4 servers with the latest batch of updates. I was not surprised when the same happened to all of my CentOS servers.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Peter Farrow spake the following on 9/11/2006 1:31 PM:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
Regards
Pete
It only happened on one of mine, and it was the new server I hadn't put in service yet. Otherwise, I always re-generate the rndc.conf and rndc.key before a server goes live. I wonder if that has anything to do with it?
I had created my own keys, I think had I left them as default it would have been ok....
P.
Scott Silva wrote:
Peter Farrow spake the following on 9/11/2006 1:31 PM:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
Regards
Pete
It only happened on one of mine, and it was the new server I hadn't put in service yet. Otherwise, I always re-generate the rndc.conf and rndc.key before a server goes live. I wonder if that has anything to do with it?
It only happened on one of mine, and it was the new server I hadn't put in service yet. Otherwise, I always re-generate the rndc.conf and rndc.key before a server goes live. I wonder if that has anything to do with it?
It does. The spec file for the bind rpm looks at rndc.conf in this way -> %verify(not size,not md5) %config(noreplace) %attr(0640,root,named) /etc/rndc.conf
Which means that it doesn't check the size of the file or the md5sum, but it will not replace the file if it has changed. So everyone using a stock rndc.conf got smacked, those who modified the file or generated a new key should have the appropriate .rpmnew for rndc.conf.
The key in /etc/rndc.conf defined as 'key' is the same in all the rpms, so people really should be generating their own keys. I view this much like the snake oil localhost cert for apache. It's fine for testing, but make your own. The key in /etc/rndc.key is autogenerated during the %post section and should be different for every install.
1. Should rndc.conf be replaced the way it is? IMNSHO, yes. 2. Should people be using the default /etc/rndc.conf file? probably not. 3. Should this be a far more documented issue than it is? Yes. It's the configuration killing people here. If rndc.conf is included everywhere it shouldn't make a difference, restarting the offending service will reload the same .conf everything else is using and life moves on. If someone copies the key out of the file and uses that, they get smacked as has been documented here on the list.
Hi There,
I was not using a stock rndc.conf file, it had references to my own generated external key file
snip.... options { default-server localhost; default-key "farrowkey"; };
server localhost { key "farrowkey"; };
include "/etc/farrowkey"; snip....
It still blew it away on both my own nameservers....
Regards
Pete
Jim Perrin wrote:
It only happened on one of mine, and it was the new server I hadn't put in service yet. Otherwise, I always re-generate the rndc.conf and rndc.key before a server goes live. I wonder if that has anything to do with it?
It does. The spec file for the bind rpm looks at rndc.conf in this way -> %verify(not size,not md5) %config(noreplace) %attr(0640,root,named) /etc/rndc.conf
Which means that it doesn't check the size of the file or the md5sum, but it will not replace the file if it has changed. So everyone using a stock rndc.conf got smacked, those who modified the file or generated a new key should have the appropriate .rpmnew for rndc.conf.
The key in /etc/rndc.conf defined as 'key' is the same in all the rpms, so people really should be generating their own keys. I view this much like the snake oil localhost cert for apache. It's fine for testing, but make your own. The key in /etc/rndc.key is autogenerated during the %post section and should be different for every install.
- Should rndc.conf be replaced the way it is? IMNSHO, yes.
- Should people be using the default /etc/rndc.conf file? probably not.
- Should this be a far more documented issue than it is? Yes. It's
the configuration killing people here. If rndc.conf is included everywhere it shouldn't make a difference, restarting the offending service will reload the same .conf everything else is using and life moves on. If someone copies the key out of the file and uses that, they get smacked as has been documented here on the list.
On Mon, 2006-09-11 at 23:29 +0100, Peter Farrow wrote:
Hi There,
I was not using a stock rndc.conf file, it had references to my own generated external key file
snip.... options { default-server localhost; default-key "farrowkey"; };
server localhost { key "farrowkey"; };
include "/etc/farrowkey"; snip....
It still blew it away on both my own nameservers....
Do you also have caching-nameserver installed?
On Mon, 11 Sep 2006, Peter Farrow wrote:
Hi There,
Just thought I would let you know that if you yum update from 4.3 to 4.4 the file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is created.
This has happened consistently on several 32 bit servers I have recently been asked to update!
FYI, it is an upstream bug. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203070
Regards,
Tom
-> -> > Hi There, -> > -> > Just thought I would let you know that if you yum update from 4.3 to -> 4.4 the -> > file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is -> > created. -> > -> > This has happened consistently on several 32 bit servers I have -> recently been -> > asked to update! -> -> FYI, it is an upstream bug. -> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203070 -> -> Regards, -> -> Tom
The bugzilla mentions that it is easy to fix... other than the mentioned patch, what is the easiest way to deal with this problem please?
Thanks in advance!
- rh
-- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
On Tue, 12 Sep 2006, Email Lists wrote:
-> -> > Hi There, -> > -> > Just thought I would let you know that if you yum update from 4.3 to -> 4.4 the -> > file /etc/rndc.conf gets overwritten and no rndc.conf.rpmsave file is -> > created. -> > -> > This has happened consistently on several 32 bit servers I have -> recently been -> > asked to update! -> -> FYI, it is an upstream bug. -> See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=203070 -> -> Regards, -> -> Tom
The bugzilla mentions that it is easy to fix... other than the mentioned patch, what is the easiest way to deal with this problem please?
Make the key in /etc/rndc.conf and /etc/rndc.key be the same.
Regards,
Tom
-> -> Make the key in /etc/rndc.conf and /etc/rndc.key be the same. -> -> Regards, -> -> Tom
Oh sure Tom!!!
Give me the really easy *easiest* answer... hrrmmmmmmmmmmphhh
I wanted the 3 hour easiest fix!!!
;-)
- rh
-- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
Email Lists spake the following on 9/12/2006 10:31 AM:
-> -> Make the key in /etc/rndc.conf and /etc/rndc.key be the same. -> -> Regards, -> -> Tom
Oh sure Tom!!!
Give me the really easy *easiest* answer... hrrmmmmmmmmmmphhh
I wanted the 3 hour easiest fix!!!
;-)
Here is the better answer; Go get yourself a chicken. Fresh, not frozen. Dead is preferred, but not required. Swing the chicken over your servers 3 times. Make sure it is three times, because 3 is the holy number.
"Then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Chicken of Antioch towards thy foe, who, being naughty in my sight, shall snuff it."
OK... Too much Monty Python!!
-> Once the number three, being the third number, be -> reached, then lobbest thou thy Holy Chicken of Antioch towards thy foe,
Ok... after much chasing around the yard and far too much clucking baaaagokkkkk racket... I have the chicken!!!
Still alive I might add. :-)
Now, where in scripture do I find this again? :-)
- rh
-- Robert - Abba Communications Computer & Internet Services (509) 624-7159 - www.abbacomm.net
Email Lists spake the following on 9/12/2006 11:21 AM:
-> Once the number three, being the third number, be -> reached, then lobbest thou thy Holy Chicken of Antioch towards thy foe,
Ok... after much chasing around the yard and far too much clucking baaaagokkkkk racket... I have the chicken!!!
Still alive I might add. :-)
Now, where in scripture do I find this again? :-)
The Book of Armaments, chapter two, verses nine through twenty-one. Revised Sysop Version.
As for the chicken being noisy, that problem should resolve by the second twirl if you do it right!
Hi Everyone,
Synaptic gives this message: There are multiple versions of "libstdc++" in your system.
[root@localhost koffice-1.5.2]# cat /proc/16798/maps | grep libstd 00291000-00351000 r-xp 00000000 16:01 9447797 /usr/lib/libstdc++.so.6.0.3 00351000-00356000 rw-p 000c0000 16:01 9447797 /usr/lib/libstdc++.so.6.0.3
Any ideas on how to resolve to the correct libstdc++? [root@localhost koffice-1.5.2]# ls /usr/lib | grep libstdc++ libstdc++-2-libc6.1-1-2.9.0.so libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2 libstdc++-libc6.2-2.so.3 libstdc++.so.5 libstdc++.so.5.0.7 libstdc++.so.6 libstdc++.so.6.0.3
[root@localhost koffice-1.5.2]# uname -a Linux localhost.localdomain 2.6.9-22.EL #1 Sat Oct 8 17:48:27 CDT 2005 i686 athlon i386 GNU/Linux
Well, I'm trying synaptic as yum does not recognize "koffice". Maybe I need another package name? [root@localhost koffice-1.5.2]# yum install koffice warning: cannot get shared lock on /var/lib/rpm/Packages Setting up Install Process Setting up repositories kbs-CentOS-Extras 100% |=========================| 951 B 00:00 jpackage-rhel 100% |=========================| 951 B 00:00 kbs-CentOS-Misc 100% |=========================| 951 B 00:00 freshrpms 100% |=========================| 951 B 00:00 update 100% |=========================| 951 B 00:00 dag 100% |=========================| 1.1 kB 00:00 base 100% |=========================| 1.1 kB 00:00 jpackage-generic 100% |=========================| 951 B 00:00 contrib 100% |=========================| 951 B 00:00 centosplus 100% |=========================| 951 B 00:00 addons 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 569 kB 00:01 base : ################################################## 1500/1500 Added 471 new packages, deleted 420 old in 8.27 seconds primary.xml.gz 100% |=========================| 366 kB 00:02 jpackage-g: ################################################## 1597/1597 Added 0 new packages, deleted 0 old in 1.70 seconds primary.xml.gz 100% |=========================| 23 kB 00:00 centosplus: ################################################## 85/85 Added 56 new packages, deleted 177 old in 0.69 seconds primary.xml.gz 100% |=========================| 26 kB 00:00 extras : ################################################## 102/102 Added 21 new packages, deleted 127 old in 0.32 seconds Parsing package install arguments No Match for argument: koffice Nothing to do
So I tried adding another repo as explained on this page: http://kde-redhat.sourceforge.net/ that is: [root@localhost etc]# yum install kde qt arts kdelibs kdebase gtk+ gtk2 redhat-artwork warning: cannot get shared lock on /var/lib/rpm/Packages Setting up Install Process Setting up repositories http://apt.kde-redhat.org/apt/kde-redhat/4/stable/repodata/repomd.xml: [Errno 4] IOError: HTTP Error 404: Not Found Trying other mirror. Cannot open/read repomd.xml file for repository: kde-redhat-stable failure: repodata/repomd.xml from kde-redhat-stable: [Errno 256] No more mirrors to try. Error: failure: repodata/repomd.xml from kde-redhat-stable: [Errno 256] No more mirrors to try.
So does this mean I should just keep trying at off-peak times?
I'm also unable to compile KOffice 1.5.2. Has anyone compiled it? make ... then mv -f ".deps/koOpenPaneBase.Tpo" ".deps/koOpenPaneBase.Plo"; else rm -f ".deps/koOpenPaneBase.Tpo"; exit 1; fi koOpenPaneBase.cc: In constructor `KoOpenPaneBase::KoOpenPaneBase(QWidget*, const char*, uint)': koOpenPaneBase.cc:50: error: 'class KListView' has no member named 'setShadeSortColumn' make[4]: *** [koOpenPaneBase.lo] Error 1 ...
Thanks, TimJowers TimJowers@UnitedSWE.com, http://www.unitedswe.com, OpenSource Java Consulting
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Tue, 12 Sep 2006, Scott Silva wrote:
Email Lists spake the following on 9/12/2006 10:31 AM:
-> -> Make the key in /etc/rndc.conf and /etc/rndc.key be the same. -> -> Regards, -> -> Tom
Oh sure Tom!!!
Give me the really easy *easiest* answer... hrrmmmmmmmmmmphhh
I wanted the 3 hour easiest fix!!!
;-)
Here is the better answer; Go get yourself a chicken. Fresh, not frozen. Dead is preferred, but not required. Swing the chicken over your servers 3 times. Make sure it is three times, because 3 is the holy number.
"Then shalt thou count to three, no more, no less. Three shall be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Chicken of Antioch towards thy foe, who, being naughty in my sight, shall snuff it."
OK... Too much Monty Python!!
It is a good thing I was not drinking anything when I read this!! ROTFLMAO!!
Maybe it will not be such a bad day afterall. :-)
Regards,