Archive for the ‘Linux’ Category

SuperMicro ipmicfg utility on Linux

Sunday, December 15th, 2013

SuperMicro have a nice little utility called ipmicfg, which can be used to interact with the IPMI BMC from within your operating system. This can do all sorts of things with the IPMI BMC, however it’s really useful if you want to change the IP address details on the IPMI card without rebooting your system and going into the BIOS setup.

To get started, download the latest version of ipmicfg from the SuperMicro FTP site (currently it’s ftp://ftp.supermicro.com/utility/IPMICFG/ipmicfg_1.14.3_20130725.zip).

Unzip this and you will find DOS, Linux and Windows versions of the ipmicfg tool, as well as a bit of documentation. I’m only really interested in the Linux version, so lets go into that folder, where you will find 32-bit and 64-bit versions.

There are two binary files included – “ipmicfg-linux.x86_64” which is dynamically linked and “ipmicfg-linux.x86_64.static” which is statically linked. The dynamically linked version normally works fine for me.

As a quick example of how to use ipmicfg, lets change the IPMI BMC IP address from being assigned via DHCP to being statically configured to 192.168.1.2 with a subnet mask of 255.255.255.0 and the default gateway set to 192.168.1.1:

./ipmicfg-linux.x86_64 -dhcp off
./ipmicfg-linux.x86_64 -m 192.168.1.2
./ipmicfg-linux.x86_64 -k 255.255.255.0
./ipmicfg-linux.x86_64 -g 192.168.1.1

When you run ipmicfg, you may see errors along the lines of:

[kcs] kcs_error_exit:

[kcs] kcs_error_exit:

[kcs] kcs_error:

[kcs] kcs_error_exit:

This essentially means that ipmicfg is having problems communicating with the IPMI BMC, and can normally be resolved by installing the IPMI drivers and loading into the kernel. On CentOS you can do this with the following commands:

yum -y install OpenIPMI
service ipmi start
chkconfig ipmi on

Building httpd 2.4.6

Sunday, July 28th, 2013

When trying to build an RPM from the Apache source tarball, rpmbuild bails with:

RPM build errors:
Installed (but unpackaged) file(s) found:
/usr/lib64/httpd/modules/mod_proxy_wstunnel.so

The problem is that the mod_proxy_wstunnel.so file has been omitted from the httpd.spec file used to build the RPM.

Extract the tarball, open up httpd.spec in your favourite text editor and scroll down until you find a section that looks like:

%dir %{_libdir}/httpd
%dir %{_libdir}/httpd/modules
%{_libdir}/httpd/modules/mod_access_compat.so
%{_libdir}/httpd/modules/mod_actions.so

%{_libdir}/httpd/modules/mod_vhost_alias.so
%{_libdir}/httpd/modules/mod_watchdog.so

%dir %{contentdir}

This should start at line 308. Add in the following line:

%{_libdir}/httpd/modules/mod_proxy_wstunnel.so

You can now run rpmbuild again. You will either need to rebuild the tarball or change to using “rpmbuild -bb httpd.spec” instead of “rpmbuild -tb httpd-2.4.6.tar.bz2”.

Regenerate statistics in Parallels Plesk for Linux

Monday, February 6th, 2012

Every night Parallels Plesk for Linux servers run a cron job to process various log files and generate statistics. This includes generating the HTML for the AWStats or Webalizer log analysis packages used for the Plesk “web statistics” features as well as updating the disk usage and bandwidth usage for each domain.

Sometimes you need to re-run this task, such as if it failed or if you need to process a particular domain name again. One common reason for this is to correct the disk and/or bandwidth usage figures for a domain.

You can either regenerate the statistics for all domain names (the equivalent of the daily cron job) using:

/usr/local/psa/admin/sbin/statistics –calculate-all

Or you can re-generate the statistics for a single domain name (“example.com” in this case) using:

/usr/local/psa/admin/sbin/statistics –calculate-one –domain-name=example.com

There is a similar tool in Parallels Plesk for Windows under C:\Program Files (x86)\Parallels\Plesk\admin\bin\statistics.exe, however this requires different arguments.

EPEL NSD RPM and the missing PID file directory

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

Recovering Logical Volumes deleted with lvremove

Sunday, March 20th, 2011

Need to recover an LVM Logical Volume that you deleted by mistake? No problem, luckily LVM archives all of the old Logical Volume and Volume Group metadata in /etc/lvm/archive/ whenever you use something like lvremove to make adjustments to the Logical Volumes.

Before you start, remember that any kind of operation like this is potentially dangerous and so backup anything of importance on the intact Logical Volumes. Also, as a safety net, backup the contents of /etc/lvm just in case and then run “vgcfgbackup” to put an up to date copy of the metadata in /etc/lvm/backup.

Now look for the appropriate file in /etc/lvm/archive. Each LVM operation will create a file in here with the name of the affected Volume Group and an incrementing number. By default on RHEL/CentOS this will be “VolGroup00”, so you will be looking for /etc/lvm/archive/VolGroup00_xxx.vg where xxx is the appropriate increment.

If you open up your chosen file in your favourite text editor you should see a line that starts “description” and has something like “Created *before* executing ‘lvremove -f /dev/VolGroup00/xxx'” on it. You can use this to verify that you have the right file.

The next thing that you need to do is verify that this file has valid metadata and thus will be useable. To do this, you can use the vgcfgrestore command in a test mode that will perform a dry run. Assuming you are trying to restore Volume Group VolGroup00 from VolGroup00_00161.vg, this would look like:

vgcfgrestore VolGroup00 –test -f /etc/lvm/archive/VolGroup00_00161.vg

Which will return something along the lines of:

Test mode: Metadata will NOT be updated.
Restored volume group VolGroup00

Assuming this all went well, you can now re-run the same command but without the “–test” option:

# vgcfgrestore VolGroup00 –test -f /etc/lvm/archive/VolGroup00_00161.vg
Restored volume group VolGroup00

Now run an “lvscan” and you should see your missing Logical Volume(s) have returned, but are inactive. Re-activate them with “lvchange” and you are back in business, just be more careful next time 😉

lvchange -a y /dev/VolGroup00/xxx

Using kill to display dd progress

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.

The dreaded scrolling GRUB GRUB GRUB on startup

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.

Python setuptools and get_python_version is not defined

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.

Sysconfig ifcfg scripts and VLAN sub-interfaces

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.

HyperVM and yum update Transaction Check Errors

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