Archive for the ‘Red Hat and CentOS’ Category
Sunday, June 26th, 2011
NSD is a fantastic authoritative nameserver from NLnet Labs which was developed in conjunction with the RIPE NCC to be a highly scalable, secure authoritative nameserver which has no recursive features by design. In fact, it is such as good nameserver that it is used on three of the root namesevers (k.root-servers.net, h.root-servers.net and l.root-servers.net).
Thanks to the EPEL project run by the Fedora guys, you can quickly and easily install an up to date copy of NSD on CentOS/RHEL systems. The only problem that I have found so far is that the RPM doesn’t seem to create directory for the PID file specified in the /etc/nsd/nsd.conf and so the daemon won’t start out of the box.
Obviously it is easy enough to create the /var/run/nsd directory with mkdir, but remember to chown/chgrp this directory to the nsd user and group, otherwise and “nsdc restart” will fail with errors in /var/log/messages along the lines of “failed to unlink pidfile /var/run/nsd/nsd.pid: Permission denied“
Tags: CentOS, EPEL, Extra Packages for Enterprise Linux, Fedora, Name Server Daemon, NLnet Labs, NSD, RedHat, RedHat Enterprise Linux, RIPE, RIPE NCC
Posted in Red Hat and CentOS | No Comments »
Tuesday, November 9th, 2010
How long has that dd process been running for now? Is it even doing anything? How long is it going to take?
If you want dd to give you a progress update, then find out the process ID (PID) and then send the USR1 signal to it with
kill -USR1
And dd will then print out the same records in/out, bytes copied, time taken and overall speed to STDERR as it would when it finishes.
It doesn’t matter if you are re-directing STDOUT (such as to pipe the data stream to another machine via netcat or even compressing it with gzip) but make sure that you aren’t sending STDERR anywhere such as /dev/null
Make sure you specify the “-USR1” argument to kill as you don’t want to send SIGTERM to dd by mistake!
By default, kill will send SIGTERM (or SIGKILL if you use kill -9) to the specified process, but using “-USR1” you are telling kill to send a different signal, in this case one that causes dd to print the progress summary and so you aren’t actually going to “kill” the process.
You can even use have the progress refresh every few seconds with a command such as
watch -n 10 kill -USR1 $PID
Just replace $PID with the PID of the running dd process (or set the PID environment variable to the process ID).
If dd was the last command you ran, then you can get the PID with the special $! variable, otherwise you’ll have to use ps to find the PID.
Tags: /dev/null, dd, gzip, kill, nc, netcat, PID, process ID, progress, progress bar, SIGKILL, signal, SIGTERM, Standard Error, Standard Output, STDERR, STDOUT
Posted in Red Hat and CentOS | No Comments »
Thursday, September 16th, 2010
Rebooting a server is always stressful, particularly when you don’t have immediate physical access to it. Of course, when the server inevitably doesn’t come back up you need to either get directly on the local console or connect in via KVMoIP and one of the worst things you can see is “GRUB GRUB GRUB” scrolling past endlessly.
This is a sign that stage 1 of the GRUB bootloader which is stored in the Master Boot Record (MBR) has somehow become corrupted and do GRUB can’t start. There is no way to even get into the GRUB command line and boot the system manually or even troubleshoot further as the problem is with stage 1 and not stage 2.
As I ran into this on a CentOS machine, I used a netinstall CD with the virtual media feature on an IP KVM attached to the server to boot into rescue mode and chroot into the operating system installed on the drive in question. I could then identify the /boot hard drive number and partition from /boot/grub/menu.lst ready to re-install GRUB and point it at the stage 2 files.
Simply run /sbin/grub to get to a version of the GRUB command prompt and then (assuming /boot/grub/menu.lst references root {hd0,0) for each of the menu options) just run:
root (hd0,0)
setup (hd0)
You should see a series of messages about looking for stage 1.5 and 2 files and then that it has successfully embedded. Congratulations, GRUB has now been re-installed and simply rebooting your machine should take you straight into your operating system as normal.
Tags: GRUB, KVMoIP
Posted in Red Hat and CentOS | No Comments »
Sunday, September 12th, 2010
If you run into the below error when using setuptools (setup.py), then it’s quite possible that you’re using an outdated version of Python’s setuptools. In particular, the python-setuptools package in the CentOS yum repository is too old.
Traceback (most recent call last):
File “setup.py”, line 19, in ?
setup(**metadata)
File “/usr/lib64/python2.4/distutils/core.py”, line 149, in setup
dist.run_commands()
File “/usr/lib64/python2.4/distutils/dist.py”, line 946, in run_commands
self.run_command(cmd)
File “/usr/lib64/python2.4/distutils/dist.py”, line 966, in run_command
cmd_obj.run()
File “/usr/lib/python2.4/site-packages/setuptools/command/bdist_rpm.py”, line 28, in run
_bdist_rpm.run(self)
File “/usr/lib64/python2.4/distutils/command/bdist_rpm.py”, line 377, in run
self.move_file(rpm, self.dist_dir)
File “/usr/lib/python2.4/site-packages/setuptools/command/bdist_rpm.py”, line 20, in move_file
getattr(self.distribution,’dist_files’,[]).append(
NameError: global name ‘get_python_version’ is not defined
Luckily, this is quite easy to fix; simply remove the RPM and download the latest version from http://pypi.python.org/pypi/setuptools then just run it with “sh” as if it was a normal shell script.
Tags: get_python_version, python, RPM, setuptools, yum
Posted in Red Hat and CentOS | No Comments »
Monday, August 16th, 2010
If you are using the ifcfg scripts in /etc/sysconfig/network-scripts to bring up VLAN sub-interfaces on a NIC and you are getting messages such as:
Bringing up interface eth0.200: Device eth0.200 does not seem to be present, delaying initialization.
instead of
Bringing up interface eth0.200: Added VLAN with VID == 200 to IF -:eth0:-
as you would expect, then make sure that you have the vconfig RPM installed.
Tags: CentOS, ifcfg, ifconfig, sysconfig, VLAN
Posted in Red Hat and CentOS | No Comments »
Monday, August 16th, 2010
If you’re having file conflict problems when running “yum update” on servers with the lxlabsupdate repository for HyperVM (or Kloxo) installed then there’s a simple resolution:
cd /var/cache/yum/lxlabsupdate/packages/
rpm -Uvh *.rpm –replacefiles –replacepkgs
This should fix errors such as:
file /usr/share/man/man1/pcregrep.1.gz from install of pcre-8.02-1.el5_5.1.x86_64 conflicts with file from package pcre-6.6-2.el5_1.7.i386
file /usr/share/man/man1/pcretest.1.gz from install of pcre-8.02-1.el5_5.1.x86_64 conflicts with file from package pcre-6.6-2.el5_1.7.i386
Tags: CentOS, HyperVM, RPM, yum
Posted in Red Hat and CentOS | No Comments »
Sunday, July 18th, 2010
Have you ever deleted everything out of /dev by accident (or even on purpose)? Although it may seem that all is lost or that you have a lot of work ahead of you, it’s actually quite easy to restore on a modern Linux system such as CentOS 5 (or the RHEL equivalent).
The first thing you need to know is that CentOS and Red Hat use udevd, which means that the entries in /dev are dynamically created by the udev daemon and restarting this daemon will force it to re-create everything in /dev, just as it would when you start your computer up. This daemon isn’t controller in the normal way through the /etc/init.d scripts though, all you need to run is:
/sbin/start_udev
This will kill any copies of udev running and then start it back up, re-creating the /dev entries in the process. This seems to be quite safe to do on a production system, but it might be wise to only do this if you really have to, as if you haven’t damaged the contents of /dev, then some of your applications may not take kindly to the contents disappearing.
This will have re-created most of your device nodes in /dev, but there are still a couple of important ones missing, namely those used by device-mapper and LVM. You can get these back with the following two commands:
dmsetup mknodes
vgmknodes
The first of which will re-create entries under /dev/mapper and the second of which will re-create LVM volume group entries under /dev/ such as /dev/VolGroup00/ by default on CentOS or Red Hat.
Helpfully this will save someone a real headache or even rebuilding/restoring from backup unnecessarily. Just be more careful with rm next time! 
Tags: /dev, device nodes, device-mapper, LVM, udev, udevd, volume group
Posted in Red Hat and CentOS | No Comments »
Saturday, June 19th, 2010
Somewhat annoyingly, Dell seem to like to disable Intel’s VT (Virtualisation Technology, sometimes called VMX) in the BIOS on their Dell PowerEdge servers, which means that you can’t use the Xen hypervisor to virtualise Microsoft Windows Server without changing this setting, which requires a reboot of the server to take effect.
You can use omreport from the Dell OpenManage Server Administrator software to check whether or not you have Intel Virtualisation Technology enabled.
If you haven’t got OpenManaged Server Administrator installed, then you can enable the Dell yum repository for CentOS/Red Hat systems and install it with:
wget -q -O – http://linux.dell.com/repo/hardware/latest/bootstrap.cgi | bash
yum -y install srvadmin-base
/opt/dell/srvadmin/sbin/srvadmin-services.sh start
Once you’ve got the Dell OpenManage Server Administrator services running, you can take a look at what processor is installed in your system and what the current BIOS settings are with:
omreport chassis processors
omreport chassis biossetup
The two attributes that you’re looking for are Processor Virtualization Technology (which needs to be enabled) and Demand-Based Power Management (which needs to be disabled).
If you need to change them, then you can do this with:
omconfig chassis biossetup attribute=cpuvt setting=enabled
omconfig chassis biossetup attribute=dbs setting=disabled
Once that's done, then verify the new settings by running omreport chassis biossetup again and then once you’ve rebooted the server you can start taking advantage of the hardware virtualisation provided by Intel’s Virtualisation Technology.
Tags: BIOS, CentOS, Dell, Hypervisor, Intel Virtualisation Technology, Intel VT, OMSA, OpenManage, OpenManage Server Administrator, PowerEdge, RedHat, RedHat Enterprise Linux, RHEL, Server Administrator, Xen
Posted in Red Hat and CentOS | No Comments »
Wednesday, June 2nd, 2010
During a botched upgrade taking an old CentOS box form 5.2 to 5.5, I ended up with a system in such a state that /lib/libselinux.so.1 and /lib64/libselinux.so.1 no longer existed. This is a major problem as it basically stops pretty much every program from working, you can’t even use cp or ls any more!
With yum and RPM unusable, SFTP/SCP/SSH clients and servers out of action and unable to use FTP or wget I thought this box was toast and was going to need a reboot and a live CD to bring it back to life.
After nosying around the system for a while to see what programs I could still run, I discovered that I could still run rsync, but this turned out to be little use as I couldn’t get RSH, SSH or RSYNC network connections in or out of the server.
The last thing I could think of was good old netcat, so I fired it up on another server with a known good copy of libselinux.so.1 and piped /lib64/libselinux.so.1 into it, then with everything crossed I piped it back out on the dying server, and lo and behold it worked and I was able to use ls again!
On the server (source) machine:
cat /lib64/libselinux.so.1 | nc -l 3333
On the client (destination) machine:
nc x.x.x.x 3333 > /lib64/libselinux.so.1
Where x.x.x.x is the IP address of the server.
Tags: CentOS, nc, netcat
Posted in Red Hat and CentOS | 1 Comment »
Saturday, May 22nd, 2010
If you’ve ever aborted a yum update for any reason, you’ve probably come across messages warning of transaction errors, such as the following example during an update from CentOS 5.4 to CentOS 5.5 that got cancelled part way through:
Transaction Check Error:
file /usr/include/libdevmapper.h from install of device-mapper-1.02.39-1.el5.i386 conflicts with file from package device-mapper-1.02.32-1.el5.x86_64
file /usr/share/man/man8/dmsetup.8.gz from install of device-mapper-1.02.39-1.el5.i386 conflicts with file from package device-mapper-1.02.32-1.el5.x86_64
Error Summary
————-
At the very start of the yum output, after “Resolving Dependencies” you should also see message saying
There are unfinished transactions remaining. You might consider running yum-complete-transaction first to finish them.
The program yum-complete-transaction is found in the yum-utils package..
This is nice and easy to resolve thankfully, you just need to use the suggested yum-complete-transaction utilit, which as the message suggests, can be found in the yum-utils package package.
This works just like the main yum program, except you don’t need to give it any arguments like install or update, you just run it and it will finish any incomplete transactions. hopefully this will fix any broken or cyclic dependancies where an update has been cancelled part way through.
I did find it somewhat ironic when I ran “yum install yum-utils” to gain access to the yum-complete-transaction command, I received the same message to install yum-complete-transaction via the yum-utils package, as that is exactly what I was trying to do!
Luckily, you can still install the yum-utils package from the normal system yum repositories whilst you have an outstanding transaction so you don’t have to mess around with downloading the RPM and installing it yourself.
Tags: CentOS, yum
Posted in Red Hat and CentOS | No Comments »