LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Networking
User Name
Password
Linux - Networking This forum is for any issue related to networks or networking.
Routing, network cards, OSI, etc. Anything is fair game.

Notices


Reply
  Search this Thread
Old 05-15-2017, 09:31 AM   #31
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3

If I may say one last thing - actually two. THANK YOU. This should be a straight install. I've installed the OS on all of the servers from CentOS 3 through 7.3. Only two have done this and they are both Super Micro H8DAR-i mobo's with dual Operton 278's. They aren't heavily loaded and have Virtouzzo on top AFTER the OS is successfully loaded. It acts as a buffer between the booting OS and the containers for added security. This also saves on power supplies. Instead of rebooting the hardware we reboot a container either through SSH or KVM/IP. We have remote APC's in the event that we have no other choice.

We are a non-profit 501(c)(3) organization. Legitimately. I don't earn a living at all from this. I built this network and know it well! It has a Cisco switch for the external IP's and another for the private IP network. This has worked since 2007. All is well with CentOS 5.9 but we know that it is EOL. I can't install 5.9 because I can't find a repo for the 64-bit version or I would install it. That's what was on there before the RAID went unrecoverable. The Virtuozzo (the commercial version of OpenVZ) backups need to go to the same server. The folks at CentOS ridiculed me for trying backwards from 6.9 trying to get a version to load.

The enterprise grade hardware firewall blocks damn near everything to the hardware node so as long as we keep the container OS and Plesk current we're somewhat secure. Nothing is foolproof and I know that. I have given you what I can partly to show that I am not a complete bozo. Please don't go there...
 
Old 05-15-2017, 01:12 PM   #32
wpeckham
LQ Guru
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, VSIDO, tinycore, Q4OS,Manjaro
Posts: 5,435

Rep: Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638
I have run 200 web server containers, one ftp/sftp server, and one DNS server all on OpenVZ containers using the kernel for RHEL 6 from the OpenVZ site. The containers were CentOS 6 and CentOS 7. They all worked just fine, and the containers are compatible with your virtuozzo commercial product.

My understanding right along is that this problem is at the host (CTID=0) level and expresses BEFORE you replace the kernel.

On hardware available to me I am not able to replicate the issue, but I do not have hardware like yours. Your ifup command appears to be failing, this that message, because the interface it is trying to raise is already up. Yet sshd can communicate on that port AFTER than failure but not BEFORE.
If I have anything incorrect here, please let me know.

If this interfaces al come up on boot, and the services come up on boot, and the routing does not change when you run that command and get the error, this issue should not happen.

If I still had hair, this might make me lose some. I will watch for someone else to weigh in and see what else can be checked.

I wish you were local to me, I would love to come look at this box. (Not that it would do any good, but any hardware more stubborn than my cat deserves to be recognized.)
 
Old 05-15-2017, 02:16 PM   #33
michaelk
Moderator
 
Registered: Aug 2002
Posts: 25,481

Rep: Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838Reputation: 5838
It would be interesting to see the output of netstat -rn before running ifup.
You never posted the ifcfg-eth1 file.

The pid for ssh is different before and after you run the ifup command. Although the boot messages showed everything started ok have you looked at the logs?

If you can not ping the host then your problem appears to be more of a networking issue then sshd specific.
 
Old 05-16-2017, 02:06 AM   #34
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by michaelk View Post
It would be interesting to see the output of netstat -rn before running ifup.
You never posted the ifcfg-eth1 file.

The pid for ssh is different before and after you run the ifup command. Although the boot messages showed everything started ok have you looked at the logs?

If you can not ping the host then your problem appears to be more of a networking issue then sshd specific.
Code:
[root@hw001 ~]# cat netstat-rn.txt 
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
65.44.220.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         192.168.220.1   0.0.0.0         UG        0 0          0 eth1
Code:
It was...

[root@hw001 ~]# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
65.44.220.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         65.44.220.1     0.0.0.0         UG        0 0          0 eth0
[root@hw001 ~]#

Last edited by krazybob; 05-16-2017 at 02:09 AM.
 
Old 05-16-2017, 08:51 PM   #35
wpeckham
LQ Guru
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, VSIDO, tinycore, Q4OS,Manjaro
Posts: 5,435

Rep: Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638
Fascinating! Do you see? Your default route CHANGES! Your default route should only be set ONCE and on the proper interface to reach the default router. There is your smoking gun.
 
Old 05-16-2017, 11:58 PM   #36
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by wpeckham View Post
Fascinating! Do you see? Your default route CHANGES! Your default route should only be set ONCE and on the proper interface to reach the default router. There is your smoking gun.
That's great!!! But I'm not doing anything to cause it. And I don't see a route change. 169.254.0.0 is ICANN. More importantly how do I correct it? I'm ready to reload the server. I've pulled all of my hair out.
 
Old 05-17-2017, 12:07 AM   #37
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
Here iis the routing from a working server. The same.

Code:
[root@hw004 ~]# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
65.44.220.59    0.0.0.0         255.255.255.255 UH        0 0          0 venet0
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
65.44.220.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         65.44.220.1     0.0.0.0         UG        0 0          0 eth0
 
Old 05-17-2017, 09:34 AM   #38
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
BTW, the reason you see an added IP and "venet0" is because the server that is fully functional has Virtuozzo loaded and running. As you know Virtuozzo like KVM and other applications create a virtual ethernet port.
 
Old 05-17-2017, 11:49 AM   #39
wpeckham
LQ Guru
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, VSIDO, tinycore, Q4OS,Manjaro
Posts: 5,435

Rep: Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638
Yes. I have used OpenVZ for years and it has that same characteristic as it is the free version form the same development team.

Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
65.44.220.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         192.168.220.1   0.0.0.0         UG        0 0          0 eth1
explains this problem perfectly. When your networking is NOT working the default route is to the wrong address and the wrong interface.
Make sure that the correct default gateway is set in the eth0 configuration.
Remove the default gateway setting from eth1 so that this WRONG information does not get picked up and eth0 sets the default gateway and port.
This and a network restart and your issue should be resolved.

Do you know how?

Last edited by wpeckham; 05-17-2017 at 11:51 AM.
 
Old 05-17-2017, 12:30 PM   #40
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
Quote:
Originally Posted by wpeckham View Post
Yes. I have used OpenVZ for years and it has that same characteristic as it is the free version form the same development team.

Code:
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
65.44.220.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         192.168.220.1   0.0.0.0         UG        0 0          0 eth1
explains this problem perfectly. When your networking is NOT working the default route is to the wrong address and the wrong interface.
Make sure that the correct default gateway is set in the eth0 configuration.
Remove the default gateway setting from eth1 so that this WRONG information does not get picked up and eth0 sets the default gateway and port.
This and a network restart and your issue should be resolved.

Do you know how?
I took the "wrong" gateway out and still no CLI. The default gateway is and has always been 65.44.220.1. I have entered it the same way on all servers. I have used Setup as well. Please explain why I have 24 other servers functioning properly. My IP range is 65.44.220.0-65.44.221.255 - a /23. The netmask is 255.255.254.0. I can use my subnet calculator and arrive at the same IP. Please explain why this is wrong. The default gateway is the first IP + one. Here is another fully functional server:

Code:
[root@hw004 ~]# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.220.0   0.0.0.0         255.255.255.0   U         0 0          0 eth1
65.44.220.0     0.0.0.0         255.255.254.0   U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U         0 0          0 eth1
0.0.0.0         65.44.220.1     0.0.0.0         UG        0 0          0 eth0
http://controlservers.net/images/netstat-11.jpg

http://controlservers.net/images/netstat-14.jpg

Please understand that I'm not trying to be argumentative but inquisitive. I've setup all of these servers and the gateway has always been what you see. If it is wrong what is right?
 
Old 05-17-2017, 12:39 PM   #41
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
Subnet calculator output

http://controlservers.net/images/ipcalc.jpg
 
Old 05-17-2017, 02:49 PM   #42
wpeckham
LQ Guru
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, VSIDO, tinycore, Q4OS,Manjaro
Posts: 5,435

Rep: Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638
+1 for Krazybob for the online subnet calculator link. I provided links earlier, but perhaps less effective.

If you look at what you provided, and what I quoted, when the box boots it is picking up the wrong routing. The default route is to gateway 192.168.220.1 on eth1. THIS is what must be removed.

After you run your ifup command, the gateway is 65.44.220.1 on eth0, and this is clearly the correct value.

I cannot say how this was arrived at, but generally when you set up the second interface and specify things that should be left at default is likely. How it got this way matters less than fixing it.

We now know what to do: find where the BED default gate is being set, and get rid of it. It may be specified in more than one place. (It should not be, but you have a problem that should not be, so expect the unexpected.) Make sure that the RIGHT default gate should be set, and verify that it is set correctly.

Last edited by wpeckham; 05-17-2017 at 02:51 PM.
 
1 members found this post helpful.
Old 05-17-2017, 10:46 PM   #43
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
Finally we have spoken the same dialect of geek! I didn't realize that I had set the gateway on eth1. Now I see it. Now I see it and feel completely stupid. Dueling gateways. I was so certain I hadn't made a mistake that I didn't see it. I simply edited

Code:
cat /etc/sysconfig/network-scripts/ifcfg-eth1
and removed the GATEWAY line and eth0 came right up after restarting the network. God bless KVM's!

Code:
[root@hw001 ~]# cat /etc/sysconfig/network-scripts/ifcfg-eth1
DEVICE=eth1
HWADDR=00:30:48:5b:32:17
NM_CONTROLLED=no
ONBOOT=yes
IPADDR=192.168.220.101
BOOTPROTO=static
NETMASK=255.255.255.0
TYPE=Ethernet
DNS1=8.8.4.4
DNS2=8.8.8.8
IPV6INIT=no
USERCTL=no
Tell me where to seend the beer or ale.
 
Old 05-18-2017, 12:53 AM   #44
krazybob
Member
 
Registered: Oct 2009
Location: Los Angeles, CA
Distribution: Centos 5.x
Posts: 133

Original Poster
Rep: Reputation: 3
OK. I should probably open a new thread by I'll try asking here first.

My data center is 2 hours away. I'm in Los Angeles and traffic is terrible. I tried a yum -u upgrade and it fails. So does an update. I get file not found errors. Now that I know why 6.9 failed I can drive to the DC and install 6.9 (I can't get to 7.3 yet as I migrate containers) and thought I'd upgrade via KVM.

Code:
Error: Package: matahari-host-0.4.4-11.el6.x86_64 (@anaconda-CentOS-201112091719.x86_64/6.2)
           Requires: libqpidclient.so.5()(64bit)
           Removing: qpid-cpp-client-0.12-6.el6.x86_64 (@anaconda-CentOS-201112091719.x86_64/6.2)
               libqpidclient.so.5()(64bit)
           Updated By: qpid-cpp-client-0.14-22.el6_3.x86_64 (base)
               Not found
Multiple errors. I know that I can try using --skip-broken to work around the problem but I don't like to kludge the OS.
 
Old 05-18-2017, 10:31 AM   #45
wpeckham
LQ Guru
 
Registered: Apr 2010
Location: Continental USA
Distribution: Debian, Ubuntu, RedHat, DSL, Puppy, CentOS, Knoppix, Mint-DE, Sparky, VSIDO, tinycore, Q4OS,Manjaro
Posts: 5,435

Rep: Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638Reputation: 2638
Technically it does deserve a new thread and this one should be marked SOLVED.
Until then:
It looks like a mismatch and the repo records. In case it is on your end AND you have not modified the repos on that machine out of sync, try this:
Code:
yum clean all
and then try the update again. This will clear all cache and local records, forcing a reload of the lists from the repos.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Cant connect to Centos via Putty using ssh. Error name unable to resolve Uva18 Linux - Newbie 7 08-10-2013 12:06 PM
Unable to get NIC to initialize in CentOS 5 zer0signal Linux - Hardware 4 07-04-2011 05:49 AM
Unable to Start X in Centos - VPS - SSH mselvaprakash Linux - General 1 10-19-2010 08:40 AM
Error: Unable to initialize punkbuster Bong-Master Linux - Server 3 12-03-2007 06:11 AM
su: unable to initialize groups bertolez Red Hat 3 04-12-2007 03:53 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Networking

All times are GMT -5. The time now is 09:24 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration