I made a yum update to 4.2 yesterday. The first "major" update I did on CentOS, I'm only using it for a few weeks now, starting with 4.1. Mainly for evaluation for a prospected migration from Suse to CentOS. Basically the update went very well, fast (only 180 MB needed to be installed) and smooth. But there were two small issues where I don't know why they happened:
1. There was a (actually two) spamassassin.rpm of SA 3.1.0 installed, the rpm was built from the tar.gz sources for SA with the specs file provided with it. It produces two files for installation: perl-Mail-SpamAssassin and spamassassin. The update wiped them and installed SA 3.0.4 with this message: Obsoleting: perl-Mail-SpamAssassin.i386 0:3.1.0-1 with spamassassin.i386 0:3.0.4-1.el4
Shouldn't this update get skipped because the version information is higher than the CentOS package? I found several mentions that I can exclude packages from yum updating. How can I do this? I don't want to update only specific packages, I only want to exclude a very few packages.
2. sshd seems to start twice or so since that update. No problems with ssh, though.
from boot.log: Oct 24 14:00:16 nx05 sshd: succeeded
from warn log: Oct 24 14:00:16 nx05 sshd[1737]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Same thing happens when I restart sshd and even when I reload it. There was a new sshd_config installed, I think I read something about removing ssh 1 protocol from it. This can't be the cause. There's only one instance of sshd running apart from the children for actual logins. Why is this happening, how to fix it?
There is another question that arises in this context: will a yum update always overwrite with new configuration files, if that file got changed from the originally installed one? I'm used from Suse that new configuration files get saved with another extension if the original file got changed or in some cases it overwrites the file but copies the old file to a backup. I can also expressly exclude some config files from overwriting via sysconfig (if I remember correctly), can I do similar with CentOS?
Thanks,
Kai
On Mon, 2005-10-24 at 14:40 +0200, Kai Schaetzl wrote:
- There was a (actually two) spamassassin.rpm of SA 3.1.0 installed, the
rpm was built from the tar.gz sources for SA with the specs file provided with it. It produces two files for installation: perl-Mail-SpamAssassin and spamassassin. The update wiped them and installed SA 3.0.4 with this message: Obsoleting: perl-Mail-SpamAssassin.i386 0:3.1.0-1 with spamassassin.i386 0:3.0.4-1.el4
Shouldn't this update get skipped because the version information is higher than the CentOS package? I found several mentions that I can exclude packages from yum updating. How can I do this? I don't want to update only specific packages, I only want to exclude a very few packages.
The name is different and the new package may have an unversioned Obsoletes entry so the version will be ignored. The best thing to do is to grab the SRPM, update the sources, change the version, and rebuild.
Ignacio Vazquez-Abrams wrote on Mon, 24 Oct 2005 09:21:24 -0400:
The name is different and the new package may have an unversioned Obsoletes entry so the version will be ignored.
I see, thanks, going to check the specs file of the new rpm.
The best thing to do is
to grab the SRPM, update the sources, change the version, and rebuild.
Hm, I'm not too familiar with building rpms. Building the spamassassin rpm from the source with the provided specs file was easy, but mangling with an existing SRPM, well ...
Anyway, is it possible to omit some packages from yum update? I read man yum but it doesn't mention this.
Kai
On Mon, 2005-10-24 at 22:13 +0200, Kai Schaetzl wrote:
Anyway, is it possible to omit some packages from yum update? I read man yum but it doesn't mention this.
You can use the --exclude command line argument or the exclude yum config key.
Ignacio Vazquez-Abrams wrote on Mon, 24 Oct 2005 17:00:52 -0400:
Anyway, is it possible to omit some packages from yum update? I read man yum but it doesn't mention this.
You can use the --exclude command line argument or the exclude yum config key.
Actually, after jumping over "man yum" a second time it's mentioned there, I overlooked it the first time. Using it in the yum.conf should just be perfect. Thanks!
Kai
On Mon, 2005-10-24 at 08:40, Kai Schaetzl wrote:
I made a yum update to 4.2 yesterday. The first "major" update I did on CentOS, I'm only using it for a few weeks now, starting with 4.1. Mainly for evaluation for a prospected migration from Suse to CentOS. Basically the update went very well, fast (only 180 MB needed to be installed) and smooth. But there were two small issues where I don't know why they happened:
- sshd seems to start twice or so since that update. No problems with
ssh, though.
from boot.log: Oct 24 14:00:16 nx05 sshd: succeeded
from warn log: Oct 24 14:00:16 nx05 sshd[1737]: error: Bind to port 22 on 0.0.0.0 failed: Address already in use.
Same thing happens when I restart sshd and even when I reload it. There was a new sshd_config installed, I think I read something about removing ssh 1 protocol from it. This can't be the cause. There's only one instance of sshd running apart from the children for actual logins. Why is this happening, how to fix it?
Most of the times I have seen this it is caused due to having IPv6 enabled. ssh binds to the port on IPv4 address or IPv6 then tries to bind a second time to the same port.
Personally I usually disable IPv6 and the zero conf stuff on systems. Have not had a use for either of these on systems and I suspect the zero conf stuff could lead to security issues if/when someone studies it a little more. :)
There is another question that arises in this context: will a yum update always overwrite with new configuration files, if that file got changed from the originally installed one? I'm used from Suse that new configuration files get saved with another extension if the original file got changed or in some cases it overwrites the file but copies the old file to a backup. I can also expressly exclude some config files from overwriting via sysconfig (if I remember correctly), can I do similar with CentOS?
Many rpm packages will typically not over write configuration files that have been modified. They will create a .rpmnew file for the config file. But don't count on that action. Backups are good to have of any configuration files you have changed.
Scot L. Harris wrote on Mon, 24 Oct 2005 09:40:29 -0400:
Most of the times I have seen this it is caused due to having IPv6 enabled. ssh binds to the port on IPv4 address or IPv6 then tries to bind a second time to the same port.
This makes sense, thanks! I wonder, why it doesn't happen on Suse, though. ipv6 is also running there, but no such error message.
Personally I usually disable IPv6 and the zero conf stuff on systems.
Add "alias net-pf-10 off" to modprobe.conf and reboot? Do I need to do anything else? What do you mean with "zero conf stuff"? That is obviously something I'm not aware of.
But don't count on that action. Backups are good to have of any configuration files you have changed.
Actually, I edit all my config files on my workstation and then transfer the file to the server machine it belongs to. I maintain a mirrored directory structure of all our machines with the most relevant config files and all changed files locally and also carry them around on my laptop. It's so much easier for comparing configuration and in case you need a fast backup, yes :-)
Kai
On Mon, 2005-10-24 at 16:13, Kai Schaetzl wrote:
Scot L. Harris wrote on Mon, 24 Oct 2005 09:40:29 -0400:
Most of the times I have seen this it is caused due to having IPv6 enabled. ssh binds to the port on IPv4 address or IPv6 then tries to bind a second time to the same port.
This makes sense, thanks! I wonder, why it doesn't happen on Suse, though. ipv6 is also running there, but no such error message.
I don't know the answer to that. I ran Suse a while back for only a short period of time on a test box. Did not get to deep into that system.
Personally I usually disable IPv6 and the zero conf stuff on systems.
Add "alias net-pf-10 off" to modprobe.conf and reboot? Do I need to do anything else? What do you mean with "zero conf stuff"? That is obviously something I'm not aware of.
Actually you should be able to disable IPv6 in the /etc/sysconfig/network file:
networking_ipv6 = no
(that may be in all caps)
zeroconf is what puts the 169.254.0.0 route in your routing table. Look at netstat -rn to see it.
Suppose to allow you to turn on a system without setting up any networking and the system is suppose to find other systems and self configure themselves into a network. You can disable zeroconf by modifying /etc/sysconfig/network by setting the following:
nozeroconf = yes
(again that may be in all caps, check the file)
Have never seen this used for anything. And don't expect to see it used any time soon.
But don't count on that action. Backups are good to have of any configuration files you have changed.
Actually, I edit all my config files on my workstation and then transfer the file to the server machine it belongs to. I maintain a mirrored directory structure of all our machines with the most relevant config files and all changed files locally and also carry them around on my laptop. It's so much easier for comparing configuration and in case you need a fast backup, yes :-)
Good plan!
"Scot L. Harris" webid@cfl.rr.com wrote:
zeroconf is what puts the 169.254.0.0 route in your routing table. Look at netstat -rn to see it. Suppose to allow you to turn on a system without setting up any networking and the system is suppose to find other systems and self configure themselves into a network. You can disable zeroconf by modifying /etc/sysconfig/network by setting the following: nozeroconf = yes (again that may be in all caps, check the file) Have never seen this used for anything. And don't expect to see it used any time soon.
Actually, the 169.254./16 network is IPv4 LINKLOCAL. It is the IPv4 equivalent to FE80::/10, IPv6 LINKLOCAL.
I haven't kept up with various standardizations, it's not only perfect normal to have both a 169.254./16 and another IPv4 address on an interface, but it is encouraged for some scenarios. In other words, do not be bothered by the existance of a 169.254./16 address on a IPv4 dynamically assigned interface.
This will be such the case with IPv6. All IPv6 nodes have a LINKLOCAL address of FE80::/10, as well as another. The initial IPv6 design was to allow up to 3 -- LINKLOCAL (FE80::/10), SITELOCAL (FEC0::/10) and then a public, but SITELOCAL has been recently deprecated (even if not official).
The lower half/16-bit (two 8-bit octets) of the IPv4 LINKLOCAL are generated from the 48-bit MAC address of the interface. In IPv6 LINKLOCAL, it is the lower half/64-bit (four 16-bit words), which easily handles the full 48-bit MAC address.
On Mon, 2005-10-24 at 17:14, Bryan J. Smith wrote:
"Scot L. Harris" webid@cfl.rr.com wrote:
zeroconf is what puts the 169.254.0.0 route in your routing table. Look at netstat -rn to see it. Suppose to allow you to turn on a system without setting up any networking and the system is suppose to find other systems and self configure themselves into a network. You can disable zeroconf by modifying /etc/sysconfig/network by setting the following: nozeroconf = yes (again that may be in all caps, check the file) Have never seen this used for anything. And don't expect to see it used any time soon.
Actually, the 169.254./16 network is IPv4 LINKLOCAL. It is the IPv4 equivalent to FE80::/10, IPv6 LINKLOCAL.
I haven't kept up with various standardizations, it's not only perfect normal to have both a 169.254./16 and another IPv4 address on an interface, but it is encouraged for some scenarios. In other words, do not be bothered by the existance of a 169.254./16 address on a IPv4 dynamically assigned interface.
This will be such the case with IPv6. All IPv6 nodes have a LINKLOCAL address of FE80::/10, as well as another. The initial IPv6 design was to allow up to 3 -- LINKLOCAL (FE80::/10), SITELOCAL (FEC0::/10) and then a public, but SITELOCAL has been recently deprecated (even if not official).
The lower half/16-bit (two 8-bit octets) of the IPv4 LINKLOCAL are generated from the 48-bit MAC address of the interface. In IPv6 LINKLOCAL, it is the lower half/64-bit (four 16-bit words), which easily handles the full 48-bit MAC address.
If you disable zeroconf the 169.254 entry is dropped. What use is it? Nothing I have found explains what it is used for or why I need it on my systems. Waving your hands and saying don't be bothered by the existence of such entries does not explain what it is used for. Getting rid of it does not impact the systems either. Kind of like an appendix. :)
On Mon, 2005-10-24 at 16:55, Scot L. Harris wrote:
If you disable zeroconf the 169.254 entry is dropped. What use is it? Nothing I have found explains what it is used for or why I need it on my systems. Waving your hands and saying don't be bothered by the existence of such entries does not explain what it is used for. Getting rid of it does not impact the systems either. Kind of like an appendix. :)
The idea is that you can plug machines into a local network and have them talk to each other with no setup and no preconfigured DHCP service. Each picks some more-or-less random and hopefully unique address in this subnet. Windows boxes will do it if a DHCP request times out. Machines can find and access each other by name with broadcast based naming like netbios or dns over multicast like rendezvous.
On Mon, 2005-10-24 at 18:11, Les Mikesell wrote:
On Mon, 2005-10-24 at 16:55, Scot L. Harris wrote:
If you disable zeroconf the 169.254 entry is dropped. What use is it? Nothing I have found explains what it is used for or why I need it on my systems. Waving your hands and saying don't be bothered by the existence of such entries does not explain what it is used for. Getting rid of it does not impact the systems either. Kind of like an appendix. :)
The idea is that you can plug machines into a local network and have them talk to each other with no setup and no preconfigured DHCP service. Each picks some more-or-less random and hopefully unique address in this subnet. Windows boxes will do it if a DHCP request times out. Machines can find and access each other by name with broadcast based naming like netbios or dns over multicast like rendezvous.
I understand what it is suppose to do. But as far as I can tell it has never been used. Has anyone actually used zeroconf for this? Other than to test it to see if it actually works?
On Mon, 24 Oct 2005, Scot L. Harris wrote:
The idea is that you can plug machines into a local network and have them talk to each other with no setup and no preconfigured DHCP service. Each picks some more-or-less random and hopefully unique address in this subnet. Windows boxes will do it if a DHCP request times out. Machines can find and access each other by name with broadcast based naming like netbios or dns over multicast like rendezvous.
I understand what it is suppose to do. But as far as I can tell it has never been used. Has anyone actually used zeroconf for this? Other than to test it to see if it actually works?
We use it for advertising and finding printers. HP JetDirect cards seem to work well with both Linux and OS X hosts. (I haven't gotten around to installing a rendezvous client on the Windows boxen yet.)
On Mon, 2005-10-24 at 19:03, Paul Heinlein wrote:
We use it for advertising and finding printers. HP JetDirect cards seem to work well with both Linux and OS X hosts. (I haven't gotten around to installing a rendezvous client on the Windows boxen yet.)
So what are the other packages needed to utilize this functionality? You mention a rendezvous client? And does this work in addition to the static or DHCP assigned addressing?
On Mon, 2005-10-24 at 17:53, Scot L. Harris wrote:
The idea is that you can plug machines into a local network and have them talk to each other with no setup and no preconfigured DHCP service. Each picks some more-or-less random and hopefully unique address in this subnet. Windows boxes will do it if a DHCP request times out. Machines can find and access each other by name with broadcast based naming like netbios or dns over multicast like rendezvous.
I understand what it is suppose to do. But as far as I can tell it has never been used. Has anyone actually used zeroconf for this? Other than to test it to see if it actually works?
My networks all have either carefully designed IP addressing schemes or a NAT router with DHCP. Since home NAT routers are so cheap, I'd guess that everyone who has a small network has one, but I don't have any reason to doubt that this address would work with samba and windows clients on an isolated network with no DHCP.
Scot L. Harris wrote on Mon, 24 Oct 2005 16:56:41 -0400:
Actually you should be able to disable IPv6 in the /etc/sysconfig/network file:
networking_ipv6 = no
Ah, thanks. Most of the sysconfig files are commented and have several default settings specified, unfortunately the network file doesn't belong to these. I did it with modprobe.conf and that works, I'm going to change it to this method.
(that may be in all caps)
zeroconf is what puts the 169.254.0.0 route in your routing table. Look at netstat -rn to see it.
Oh, I see, I know the concept but I wasn't aware that it's activated by default and called "zeroconf". I assume this is new with 2.6 kernels, I've never worked with 2.6 kernels before installing CentOS. I don't need that, gonna remove it.
Kai
-
Bryan J. Smith -
Ignacio Vazquez-Abrams -
Kai Schaetzl -
Les Mikesell -
Paul Heinlein -
Scot L. Harris