Observations, Musings & Gadgets

...things I find interesting

Articles tagged with centos

Installing alternate versions of Python in CentOS

The downside of running CentOS is that, for a lot of packages, the versions are far from bleeding edge.

Python is used by serveral critical system utilities (such as yum) which will break if you replace the system version of python. If you want a version of python other than the supported version, here's how.

This will work for versions in both the 2.x and 3.x branches, with some minor differences.

Compiling python is not difficult, but we will need some prerequisites first. It's really important to have all the devel packages otherwise python will be missing support for various things (like if you don't have openssl-devel installed, none of the python libraries will know how to handle https).

yum groupinstall "Development tools"
yum install zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libcap-devel xz-devel

You should consider the following...

Unicode

Python 3.2 and earlier should have UTF-32 support configured (otherwise you may run into problems). From Python 3.3 and upward Unicode support has been completely overhauled and strings are automatically stored in the most efficient encoding.

For Python 2.x use the --enable-unicode=ucs4 flag to the configure command. In Python 3.x use --with-wide-unicode.

Shared Library

You should probably compile Python as a shared library. All modern linux distros ship with Python compiled as a shared library, and there are third party tools that won't work without it. If you compile Python as a shared library you must also tell it how to find the library. There are two options.

  • Compile the path into the executable by adding this to the configure command: LDFLAGS="-Wl,-rpath /usr/local/lib"
  • Add the library's path to /etc/ld.so.conf
    include ld.so.conf.d/*.conf
    /usr/local/lib
    

Use "make altinstall" to prevent issues

It is vitally important that you use make altinstall when you install your custom version of python.

Download, Compile, Install

I'm installing Python 3.4.1 as a shared library, with it's path compiled into the executable, so am including the LDFLAGS as discussed. If you are not you can omit this, but don't forget to edit /etc/ld.so.conf and you will need to run /sbin/ldconfig to pick up the changes. Your mileage may vary.

wget http://python.org/ftp/python/3.4.1/Python-3.4.1.tar.xz
tar xf Python-3.4.1.tar.xz
cd Python-3.4.1
./configure --prefix=/usr/local --enable-shared LDFLAGS="-Wl,-rpath /usr/local/lib"
make && make altinstall

Once that has completed you will have a shiny new Python 3.4.1 available as /usr/local/bin/python3.4 which (on our systems which are using 2.6.6 as the system python) I symlink to /usr/local/python3. It's up to you if you want to do that.

Setuptools and pip

In our case these are probably not needed as we dont want end users using them, but here's how.

wget https://bitbucket.org/pypa/setuptools/raw/bootstrap/ez_setup.py

python3.4 ez_setup.py

easy_install-3.4 pip

Packages installed using pip3.4 install [packagename] will end up in /usr/local/lib/python3.4/site-packages/.

Virtualenv

If you are using different versions of python on a single machine, you should really be using virtualenv. Python 3.3 has this built in, for lower versions you will need to install it. For example if you have installed Python 2.7, pip2.7 install virtualenv.

Then using virtualenv create a sandbox for each project.

vertualenv-2.7 myProject

# The builtin version is pyvenv
pyvenv-3.4 my34project

# Use like this
source my34project/bin/activate
python --version
# this will show Python 3.4.1
deactivate

# source myProject/bin/activate
python --version
# this will show Python 2.7.6, for example
deactivate

Don't forget, virtualenv will automagically install setuptools and pip for you inside the sandbox. If you are using pyvenv, that's up to you, I'm afraid. ez_setup.py is your friend, here.

tagged as python, centos

Setting the Dell Service Tag after Motherboard replacement

When the service tech replaced the motherboard in one of our Dell Poweredge servers, he neglected to set the service tag.

The BIOS and all of our management tools were reporting an empty string for the service tag.

Turns out it's actually pretty easy to set, using smbios-sys-info.

Make sure you have the smbios utilities installed.

yum install smbios-utils-python

The following command will set the service tag. Setting the service tag will also set the express service code (they are essentially different representations of the same data).

smbios-sys-info --service-tag --set=XXXXXX

If your company uses the asset tag in the BIOS, you can set that too.

smbios-sys-info --asset-tag --set=XXXXXX
tagged as motherboard, service tag, smbios, centos

Kernel 2.6.32-358 breaks Dell Openmange IPMI support

We've recently been setting up a proper management network for our infrastructure servers.

As they are all Dell servers, we are using Dell's Openmanage tools to setup the DRAC cards and administer the hardware.

After a recent kernel update (due to a vulnerability) the ipmi driver failed to load. Upon closer inspection, it seemed that the impi_si kernel module was not being loaded.

That's actually not surprising, given that the functionality of the ipmi_si module now resides in the kernel and there is no ipmi_si kernel module.

Luckily, there is a simple fix.

Just install the OpenIPMI package.

# yum instal OpenIPMI

Note that you do not need to start the service or have it configured to start at boot.

# service ipmi status
ipmi_msghandler module in kernel.  
ipmi_si module in kernel.  
ipmi_devintf module loaded.  
/dev/ipmi0 exists.  

Thanks to Greg at /sys/net Adventures for the solution.

tagged as kernel, ipmi, centos

Fixing ethernet issues after Motherboard replacement

Recently we had one of our Dell poweredge servers repaired under warranty (the server couldn't talk to the DRAC card).

After the motherboard replacement, we couldn't get networking running (this is CentOS 6.3 BTW). The network service would fail, saying it couldn't find eth0 or eth1, etc.

We updated the MAC addresses of the new hardware in /etc/sysconfig/network-scripts/ifcfg-ethx, but the devices were not being found.

Looking at dmesg we could see that that udev was changing the names of the devices (from eth0-eth3 to em1-em4).

Well, it turns out that CentOS writes persistent udev rules about it's network interfaces. Examining /etc/udev/rules.d/70-persistent-net.rules revealed the four interfaces listed twice, with the old hardware addresses and the new hardware addresses.

# This file was automatically generated by the /lib/udev/write_net_rules
# program, run by the persistent-net-generator.rules rules file.
#
# You can modify it, as long as you keep each rule on a single
# line, and change only the value of the NAME= key.

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:9b", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:9f", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:99", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:9d", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:ff", ATTR{type}=="1", KERNEL=="eth*", NAME="eth0"

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:05", ATTR{type}=="1", KERNEL=="eth*", NAME="eth3"

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:03", ATTR{type}=="1", KERNEL=="eth*", NAME="eth2"

# PCI device 0x14e4:0x1639 (bnx2) (custom name provided by external tool)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:00:00:00:00:01", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"

I've changed the MAC addresses, to make things a little clearer to see. Here you can see the double entries.

Criticaly, though, both old and new instances were using NAME=ethx. Udev is definitely not cool with two devices having the same name, so the second set of udev entries (ie the correct hardwaare addresses) were being renamed.

Simple soultion, comment out or remove the old entries and restart.

tagged as udev, motherboard, centos