Blacklist udev from yum, prevent PTY errors

[Pierre_@_VPSLink]

OpenVZ and udev are not compatible. Udev is apparently not able to populate /dev properly during the boot sequence under openvz. The OS templates provided by VPSLink have udev disabled and the devices created statically.
If you install/update udev by accident on your server (e.g. with yum) it will be re-enabled again and /dev will be corrupted, locking you out your VPS.
Once this happens your only options are to open a trouble ticket, or to reinstall your server from the control panel.

You can prevent this by adding the following lines to /etc/rc.local:

/bin/rm -rf /dev/null
/bin/rm -rf /dev/random
/bin/rm -rf /dev/tty*
/bin/rm -rf /dev/pty*
/bin/mknod /dev/null c 1 3
/bin/mknod /dev/random c 1 8
/sbin/MAKEDEV tty
/sbin/MAKEDEV pty

It will force all the devices needed for a ssh connection to be created each time your VPS boots.

[bfp]

Another good option would be for VPSLink to include these tweaks into their OpenVZ templates for CentOS, so the problem won't occur at all - at least on new installs (or re-installs).

[vpslinkdotcom]

It's a very very slippery slope when we start making those changes inside an OS template. Other programs that may depend on udev may not be available for install via yum..and then we're supporting a whole different issue.

[bfp]

Well, maybe point taken re udev.

But you should certainly consider putting something like the following into yum.conf in the OpenVZ template for CentOS, since it doesn't make sense for it not to be there:

exclude= kernel*

It causes users known problems if yum goes and tries to upgrade the kernel under OpenVZ

[Marcusone]

If you want to help determine what is causing null to be deleted/overwritten, and a more controlled replacement script use this:

#!/bin/sh
/sbin/MAKEDEV tty
/sbin/MAKEDEV pty

#if random devices/files do not exists as character-special file
if [ ! -c /dev/random ]
then
        rm -f /dev/random
        mknod -m 644 /dev/random c 1 8
fi
if [ ! -c /dev/urandom ]
then
        rm -f /dev/urandom
        mknod -m 644 /dev/urandom c 1 9
fi

#check to ensure null device is correct as well
if [ ! -c /dev/null ]
then
        FNAME=`date --date "today" +"null-%Y-%m-%d_%H.%M.old"`
        cp -f /dev/null /root/$FNAME
        rm -f /dev/null
        mknod -m 666 /dev/null c 1 3
fi

Then add this to rc.local or some other script that runs on startup.

[someoneoutthere]

I realize that this sticky is fairly old, but it is a sticky and I've been wondering if it is still applicable with CentOS 5.x (or even other versions)....

Since it doesn't look like there was a clear-cut decision made either way -- and I don't know nearly enough about Linux to make an educated decision about it whatsoever -- I was wondering if someone could clarify this a bit more?

It appears to be a very severe issue (at least in theory, maybe I've been lucky so far with YUM updates, as I haven't had a problem...yet). And again, just since it is a sticky posted (and debated) by VPSlink admins, it would be very helpful to hear if this is still something that we need to be worried about and/or take appropriate steps to prevent a potentially severe outcome if we accidentally update.

...or if it (hopefully) isn't an issue anymore -- maybe it could be "demoted" from the magic-Sticky-status, just so it doesn't keep us newbies awake at night
Thanks yet again for everyone's help.

[Lyle@VPSlink]

Hello,

Yes, this is still applicable. Our template developers have modified yum.conf in our published templates (RPM based distributions) and have taken some proactive measures to try to ensure the /dev entries are created when a VPS boots up, but since we give full root access, you are still able to remove our customization of yum.conf and hit this problem. (The most common result of this problem is inability to log in via SSH, "Server refused to allocate a pty" or "Connection refused.")

To clarify/simplify:
1) Don't install udev unless you know you really need it.
2) If you do install it, add the lines Pierre_@_VPSLink recommended at beginning of this thread to /etc/rc.local (or some other script that runs on startup) to ensure those device files exist.

[someoneoutthere]

Lyle,

Ok, thanks a ton for the advice. Glad I didn't run into this before (luck I guess?), because I'd have had no idea of how to fix it

I just checked my rc.local file, and the only thing it currently has in it is:

touch /var/lock/subsys/local

And, when I do a "yum update", it does show an UPDATE for udev [so I guess I already have it installed? I'm using the CentOS/Hib/Lxadmin template...

So before I actually do the yum update, should I for sure add all of those lines to my rc.local file as mentioned in the 1st post? Just because I was lucky before, doesn't mean I will be after the update from yum I'm guessing....I think you answered this in your last reply, but if you don't mind and have time, I just wanted to double-confirm

Thanks again.

[someoneoutthere]

I didn't receive the double-scary-nerve-settling reply
So I went ahead and did it...and it's all working fine

As mentioned in this thread, I added the said lines to the file at "/etc/rc.local"
Actually on mine, that was a symbolic link --> "/etc/rc.d/rc.local" [I think that was it, going from memory here, but something like that].
So if anyone tries, I would say to make sure you're not overwriting the alias to the real file and/or just make sure it's the correct spot...as I don't know enough to know why that alias is there instead of the real file -- but at least that's how mine is setup.

Anyways, yes it works so far. I'm pretty sure udev got updated when I did the "yum update", and things still seem to work as before here...so either I'm lucky once again, or this trick worked and saved weeks of my life stressing over trying to fix it after accidentally updating udev

So thanks again everyone in this thread, I appreciate all of the help and direct, simple instructions on how to fix it.

[DavidOrser]

Looks like this is still required should udev slip into your setup.

As appears in Marcusone's post you have to make sure to setup /dev/null as user writable or you'll get some chaff.

/bin/rm -rf /dev/null
/bin/rm -rf /dev/random
/bin/rm -rf /dev/tty*
/bin/rm -rf /dev/pty*
/bin/mknod -m 666 /dev/null c 1 3
/bin/mknod /dev/random c 1 8
/sbin/MAKEDEV tty
/sbin/MAKEDEV pty

My VPS was re-setup this Feb/March with the latest CentOS image. As my VPS is shared with several admins, I can't be 100% positive. However, looking through my yum.conf file I don't see any excludes. In yum.log, I also see kernel and udev packages getting updated in the very first "yum update".

Are these exclusions in the base image at all? Should they be?