I was pleased to read this link on the excellent MySQL Performance Blog.
Posts tagged ‘linux’
Here are two ways to update the firmware on Dell iDRAC6 remote access cards.
Both methods require downloading the BIOS from Dell and extracting it from the bundle. For example, this is the 1.70.21 firmware:
mkdir /tmp/dell
cd /tmp/dell
wget http://ftp.dell.com/esm/IDRAC6_FRMW_LX_R299265.BIN
Grab this and extract like this:
cd /tmp/dell
sh IDRAC6_FRMW_LX_R299265.BIN --extract ./idrac6-1.70.21
The firmware image is now in /tmp/dell/idrac6-1.70.21/payload/firmimg.d6
If you are just updating one machine, then the simplest way to perform the update is to use the Dell bmcfwul tool locally. This is supplied in the dell_ie_nitrogen package, and is installed to /usr/libexec/dell_dup/dell_ie_nitrogen/bmcfwul.
Install the new firmware like this:
/usr/libexec/dell_dup/dell_ie_nitrogen/bmcfwul -input=/tmp/dell/idrac6-1.70.21/payload/firmimg.d6
If you have several machines to update, the most convenient way to perform the update is with tftp.
First, copy the firmware image to the tftp server, and put it in /tftproot, or wherever the root of your tftp server is located:
scp /tmp/dell/idrac6-1.70.21/payload/firmimg.d6 $ip_of_tftp_server:/tftproot
Then, trigger a firmware upgrade on the machines remotely using either racadm or ssh:
racadm -r host.to.update -u root -p calvin fwupdate -g -u -a $ip_of_tftp_server
or
ssh host.to.update racadm fwupdate -g -u -a $ip_of_tftp_server
I ran into an odd issue today – my firewall build script was failing on our account master node.
It turns out that I was trying to use a chain name in iptables that exceeded the maximum length allowed. I wanted to use "REMOTE_ACCOUNT_SLAV ES_ASHEVILLE" (31 chars) and the limit is 30 chars.
You can see this in /usr/include/linux/netfilter_ipv4/ip_tables.h and /usr/include/linux/netfilter/x_tables.h:
/usr/include/linux/netfilter_ipv4/ip_tables.h
22:#define IPT_FUNCTION_MAXNAMELEN XT_FUNCTION_MAXNAMELEN
/usr/include/linux/netfilter/x_tables.h
4:#define XT_FUNCTION_MAXNAMELEN 30
This was on CentOS 5.6.
I wanted to install a Fedora 13 machine as a paravirtual domu guest on our CentOS 5.5, xen 3.4.2 host. I also wanted to provision it using koan/cobbler. I ran into a few problems along the way, but I got there in the end!
Continue reading ‘Fedora 13 as a domu guest with xen 3.4.2 on CentOS 5.5’ »
I use the toggl time-tracking service to keep track of the hours I work for my various clients.
toggl make available desktop clients for Windows, Mac, & Linux, but the Linux packages are in .deb format for Ubuntu and, until recently, they did not provide x86_64 packages.
toggl recently released the desktop client as open source so I grabbed it and have built an RPM.
SRPM: TogglDesktop-2.5.1-1.fc12.src.rpm
RPM (Fedora 12, x86_64): TogglDesktop-2.5.1-1.fc12.x86_64.rpm
It seems that several people have been having problems getting Dell OMSA 6.2 to work correctly on CentOS 5.4 x86_64. Specifically, the software does not detect any storage controllers, and therefore also doesn't find any disks. eg.
[root@b034 ~]# omreport storage pdisk controller=0 Invalid controller value. Read, controller=0 No controllers found.
After a little investigation, I found the source of the problem.
Continue reading ‘Dell OMSA on CentOS 5.4 x86_64 – No Controllers found error’ »
As I mentioned in a previous post, the MySQL RPMs provided for RHEL/CentOS by percona are not actually compatible with RHEL/CentOS. They use the same package layout as the MySQL-provided RPMs.
Here's how I create my own RPMs having the same package layout as the RHEL/CentOS packages but with the percona highperf patchset applied.
Continue reading ‘RHEL/CentOS-compatible MySQL RPMs with percona highperf patchset’ »
ourdelta provide MySQL packages for various platforms, built with assorted performance/feature patchsets.
Sadly, like the percona builds, the RPM packages for RHEL/CentOS are not upstream-compatible, ie. they package MySQL differently.
I was planning to re-build the ourdelta packages to use the upstream RPM package layout but I've decided to stick with re-building the percona packages as I've already done the work for that.
Anyway, in case it helps someone, here's how to rebuild the ourdelta packages from the SRPM:
rpmbuild --rebuild \
MySQL-OurDelta-5.0.87.d10-65.el5.src.rpm \
--define 'ourdelta 1' \
--define 'mysqlversion 5.0.87' \
--define 'elversion 5' \
--define 'patchset d10'
I wanted to install racadm on my local (non-Dell) workstation running Fedora 11. I tried installing via the repos as per the instructions, but without success. I eventually managed by downloading manually:
wget http://linux.dell.com/repo/hardware/OMSA_6.1/platform_independent/rh50_64/racadm/mgmtst-racadm-6.1.0-648.i386.rpm yum localinstall mgmtst-racadm-6.1.0-648.i386.rpm
The next problem was that racadm wouldn't run – it failed with the error:
ERROR: Failed to initialize transport
Running under strace showed that it seemed to be having problems finding a suitable ssl library – probably because racadm is i686 and I'm running it on x86_64. Using yum provides I determined that a suitable ssl lib was shipped with Adobe Reader, installed in /opt/Adobe/ on my workstation.
The following couple of symlinks fixed it:
ln -s ../../opt/Adobe/Reader9/Reader/intellinux/lib/libssl.so.0.9.8 /lib/i686/ ln -s ../../opt/Adobe/Reader9/Reader/intellinux/lib/libcrypto.so.0.9.8 /lib/i686/
I needed to check the integrity of the file systems on several xen domU guests while the guests were shutdown, ie. I needed to do it from the dom0.
I use LVM logical volumes for the block devices for the guests disks named $host-disk0. These are stored in a volume group named vg_guests. I use kpartx to access the partitions on the block device.
Each guest disk has a small physical partition for /boot; the rest of the disk is allocated to a 2nd partition which is used as an LVM volume group named vg_$host.
Here's a script I knocked up to do the job:
for host in host1 host2 host3 ; do # create devices from the LVs kpartx -av /dev/mapper/vg_guests-$host--disk* # Activate the VGs for the host for vg in $(vgs --noheadings | grep $host | awk '{print $1}' ) ; do echo Activating $vg vgchange -ay $vg done # check the file systems for p in $(/dev/mapper/vg_$host* | grep -v swap); do e2fsck -p $p done # Deactivate the VGs for vg in $(vgs --noheadings | grep $host | awk '{print $1}' ) ; do echo De-activating $vg vgchange -an $vg done # Remove the devices kpartx -dv /dev/mapper/vg_guests-$host--disk0 done
