If you have network interfaces that no longer counts from 0 or 1 because you’ve added and removed a network card, you may force Linux to renumber the interfaces by modifying the udev rules and network configs.

The simplest solution would be to:

1. Delete (or edit out old entries in) /etc/udev/rules.d/70-persistent-net.rules
2. Edit the network scripts in /etc/sysconfig/network-scripts/ifcfg-* and delete any extraneous configs.
3. Reboot

Ensure that your network configs match the interfaces when the system comes back up.

The UUID is a 128-bit universally unique identifier which is burned on the motherboard on a system. It’s typically represented as a 32 character string separated into groups  of 8, 4, 4, 4, 12 characters by a dash.

An example of a UUID is:

5178962d-2fcf-df50-536d-000423d9985a

This can be assumed to be unique to a computer. The only time I encountered collisions were when two Dell servers did not have the asset tag set which suggests that the UUID is a function of certain parameters on these servers.

To get the UUID on Windows, the simplest way is to use PowerShell:

get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID

To get the UUID on Linux or FreeBSD, use dmidecode which can be installed through mots package managers (yum, apt-get, pacman, etc) or through ports at /usr/ports/sysutils/dmidecode.

dmidecode | grep -i uuid

To get the UUID on VMWare ESXi or vSphere, login via SSH and run:

esxcfg-info | grep -i uuid

You will see a bunch of UUIDs, most of which pertain to disks/volumes. What you are looking for is:

|----System UUID..............................................5178962d-2fcf-df50-536d-000423d9985a

If you encounter an error like:

extracting debug info from /home/leo/rpmbuild/BUILDROOT/processing-1-5.1.x86_64o
*** ERROR: No build ID note found in /home/leo/rpmbuild/BUILDROOT/processing-1-o
error: Bad exit status from /var/tmp/rpm-tmp.WmvEiC (%install)

Add the following to your .spec file:

%define debug_package %{nil}

If your configuration files under /etc/sudoers.d/ is not being loaded… ensure that you have the following line in /etc/sudoers

  #includedir /etc/sudoers.d

Even though it is commented out… the existence of the line is required for things under /etc/sudoers.d/ to be loaded. At least, this is what happened to me under Scientific Linux 6.1.

Whether this is a feature or a bug, I have absolutely no idea. Hope this saves someone some hair pulling and time.

The /var/log/messages file has grown to well over 7.1GB which isn’t very good especially when you want to read through it. In order to make this more manageable, you should probably rotate the file.

One tool for rotating logs is logrotate. The following is the configuration file in charge of /var/log/messages.

cat /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
    sharedscripts
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

In order to have logrotate rotate the logs weekly, ensure your configuration is similar to:

cat /etc/logrotate.d/syslog
/var/log/messages /var/log/secure /var/log/maillog /var/log/spooler /var/log/boot.log /var/log/cron {
    # Run the pre/post rotate commands only once for all the logs
    # that are being rotated.
    sharedscripts

    # rotate weekly
    weekly

    # keep 2 years of logs
    rotate 104

    # send HUP to syslogd
    postrotate
        /bin/kill -HUP `cat /var/run/syslogd.pid 2> /dev/null` 2> /dev/null || true
    endscript
}

You may also want to do other things such as email notifications or compression, which is available as well. You will want to refer to RedHat’s Deployment Guide for more information.

You may also want to have logrotate run automatically via cronjobs.

crontab -l
@daily /usr/sbin/logrotate /etc/logrotate.conf > /dev/null 2>&1

I’ve been banging my head against my desk since I couldn’t get clonezilla to boot anymore after migrating my tftpserver from CentOS to FreeBSD (9.0-RELEASE). Everything seems to boot fine until it tries to fetch the root filesystem. Below is what is seen on the console during the boot process:

IP-Config: eth0 complete (dhcp from 10.1.1.9)
 address: 10.1.1.55   broadcast: 10.1.1.255   netmask: 255.255.255.0
 gateway: 10.1.1.1    dns0     : 10.1.1.9     dns1   : 0.0.0.0
 domain : home.steamr.com
 rootserver: 10.1.1.9 rootpath:
 filename  : /pxelinux.0
Creating /etc/resolv.conf
Begin: Trying tftp -g -b 10240 -r /images/clonezilla/live/filesystem.squashfs -l /images/clonezilla/live/filesystem.squashfs 10.1.1.9 ... ^M /images/clonezilla/l   0% |
tftp: timeout

 .''`.
: :'  :   BOOT FAILED!
`. `'`
  `-      This Debian Live image failed to boot.

Please file a bug against the 'live-boot' package or email the Debian
Live mailing list at <debian-live@lists.debian.org>, m aking sure to note
the exact version, name and distribution of the image you were attempting to boot.

< snip >

BusyBox v1.20.1 (Debian 1:1.20.0-4) built-in shell (ash)
Enter 'help' for a list of built-in commands.

/bin/sh: can't access tty; job control turned off
(initramfs) _

The tftpboot pxelinux.cfg/default configuration file contains:

label 3
        menu label ^3. Clonezilla Live CD (x86)
        kernel images/clonezilla/live/vmlinuz
        append initrd=images/clonezilla/live/initrd.img boot=live config noswap nolocales edd=on nomodeset ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="" ocs_live_batch="no" ocs_lang="" vga=788 nosplash noprompt fetch=tftp://10.1.1.9/images/clonezilla/live/filesystem.squashfs

Obviously, tftp works. This is evident by the fact that clonezilla managed to boot and the fact that I was greeted by the pxe boot menu. Furthermore, if I typed in `tftp -g -r /images/clonezilla/live/filesystem.squashfs 10.1.1.9`, I am able to retrieve the filesystem.squashfs file without issue.

Checking the logs on the FreeBSD machine, I see the following:

Oct  3 04:42:34 nas tftpd[38727]: send_packet: Message too long
Oct  3 04:42:34 nas tftpd[38727]: Cannot send DATA packet #1, trying again
Oct  3 04:42:34 nas tftpd[38727]: DATA block 1, attempt 0 failed (Error 40: Message too long)
Oct  3 04:42:35 nas tftpd[38727]: DATA block 1, attempt 1 failed (Error 40: Message too long)
Oct  3 04:42:37 nas tftpd[38727]: DATA block 1, attempt 2 failed (Error 40: Message too long)
Oct  3 04:42:38 nas tftpd[38783]: DATA block 1, attempt 4 failed (Error 40: Message too long)
Oct  3 04:42:41 nas tftpd[38727]: DATA block 1, attempt 3 failed (Error 40: Message too long)

So, obviously, the transfer block size is causing some sort of issue. I spent easily over an hour trying to get it to work using different parameters and different tftpd servers to avail.

My solution is to just use nfs. It’s easier to just use NFS and save yourself the trouble of trying to get it to work. Change the configuration to match the following:

/etc/exports

/tftpboot/images/clonezilla  -network 10.1.1 -mask 255.255.255.0    # or whatever network address you're on. I'm on 10.1.1.0/24

/tftpboot/pxelinux.cfg/default

label 3
        menu label ^3. Clonezilla Live CD (x86)
        kernel images/clonezilla/live/vmlinuz
        append initrd=images/clonezilla/live/initrd.img boot=live live-config noswap <strong>union=aufs netboot=nfs nfsroot=10.1.1.9:/tftpboot/images/clonezilla</strong> ocs_live_run="ocs-live-general" ocs_live_extra_param="" ocs_live_keymap="" ocs_live_batch="no" ocs_lang="" vga=788

Then, either start nfs or reload it:

 kill -HUP `cat /var/run/mountd.pid `

Then, try booting clonezilla. If everything’s good, you should be able to boot into it.

I am currently using a cyborg R.A.T. 7 on my desktop which, after less than a year, has started exhibiting signs of wear. This is evident from the fact that a simple click of the wheel will at around 60% of the time send a double click instead. This is due to the membranes (ie: the switches) wearing away causing it to be faulty. Naturally, this is driving me completely nuts since opening a hyperlink using the mouse wheel will, most likely, open the hyperlink twice.

Aside from fixing the problem by sending it back to the manufacturer, it’s possible to just ‘patch’ up the problem using AutoHotKey (http://autohotkey.com/). The program allows you to programatically control actions sent by your mouse or keyboard. In order to fix the problem described above, run the following ahs script:

MButton::   
   If (A_TimeSincePriorHotkey < 150)
      Return
   Send {MButton}
Return

The above will simply check whether the double click is below 150ms. If it is below 150ms, the double click is effectively ignored as it's improbable that any human can click that fast. You may raise or lower this depending non your requirements, though a higher number for the middle button wouldn't hurt since it's rare to ever need to double click the wheel anyway.

You may want to replace MButton with LButton or RButton as well in case your mouse is defective on the left or right button. For more information on different keys, see http://www.autohotkey.com/docs/KeyList.htm

Oh, and I do not recommend the Cyborg mouse at all. Aside from its modern appearance, it is not a very good mouse. It's a little uncomfortable to use despite the fact that it is 'customizable', and I miss the free scrolling mode which my logitech G500 has. My G500 after 3 years of use still seems to work flawlessly.

If you ever boot into maintenance mode, you’ll notice that the root directory is mounted as read only. In order to remount / as read-write, run:

mount -n -o remount /

I was frustrated for over an hour trying to get into single user mode on a mac which was running under vmware. Supposedly, you’re suppose to hit ⌘-S while it is booting in order to get into the rescue mode. However, this doesn’t seem to work, at least on my PC keyboard (I tried hitting Win-S and Alt-S) through VMware Workstation 8.

Instead, try:
1. Restarting the VM
2. hitting F8 while booting Darwin/x86.
3. At the boot menu, select the hard disk option (h)
4. Specify the boot parameter ‘-s’ for single user (just like linux)

That should boot you into single user mode, allowing you to reset your password amongst other things.

To reset a password:
1. umount -uw /
2. launchctl load /System/Library/LaunchDaemons/com.apple.DirectoryServices.plist
3. dscl . -passwd /Users/username password – You may see an error, but it should be fine.
4. reboot

If you ever need to look at the DNS queries sent to your server, there are two ways: Logging or looking at DNS traffic on port 53.

Logging queries in Bind

Logging is definitely more reliable and can be turned on (if you’re using bind) using rndc

To check if logging is enabled:

# rndc status |grep query
query logging is OFF

To turn logging on:

# rndc querylog on
# rndc status |grep query
query logging is ON

Once logging is enabled, the requests are by default logged to /var/log/messages:

# cat /var/log/messages |grep named |grep query
Jul 15 13:44:36 nas named[1858]: client 10.1.1.3#64896: query: steamr.com IN A + (10.1.1.9)
Jul 15 13:44:36 nas named[1858]: client 10.1.1.3#64897: query: steamr.com IN AAAA + (10.1.1.9)

DNS Traffic

To look at the actual DNS traffic (either directly to your server or sniffing on a network), use tcpdump. Here is an example of me looking up ‘steamr.com’ while tcpdump was running.

# tcpdump -n -s 1500 -i eth1 port 53
13:44:43.398635 IP 10.1.1.3.64903 > 10.1.1.9.domain: 6+ A? steamr.com. (28)
13:44:43.399434 IP 10.1.1.9.domain > 10.1.1.3.64903: 6 1/13/13 A 209.217.226.237 (463)
13:44:43.400415 IP 10.1.1.3.64904 > 10.1.1.9.domain: 7+ AAAA? steamr.com. (28)
13:44:43.401365 IP 10.1.1.9.20821 > 64.59.135.135.domain: 4278+ [1au] AAAA? steamr.com. (39)
13:44:43.412659 IP 64.59.135.135.domain > 10.1.1.9.20821: 4278 0/1/0 (74)
13:44:43.413243 IP 10.1.1.9.domain > 10.1.1.3.64904: 7 0/1/0 (74)

You can see the queries which are denoted with a question mark (?), and the responses to the queries.