Linux


I know it’s probably an unusual situation, but in the lab we have Jumbo frames turned on for all the servers and test boxes. It makes a huge difference copying ISOs between hosts, and doing network backups. However, my Kubuntu laptop isn’t always in the lab network. This means that I almost never remember to change the MTU when I’m back in the office, OR I remember in the middle of a transfer, when it’s already too late to gain the benefits.

So I wrote a little script, and put it in /etc/network/if-up.d/ named “jumbo-frames.sh”. The if-*.d/ structure is designed for exactly this purpose: run a script when an interface comes up. The basic premise is: If I’m plugged into a wired network (eth0) in the lab (domain or IP address match certain parameters), then set the MTU to 9000 (jumbo frame support), otherwise assume the network has a normal MTU (1500). This allows the system to reconfigure on the fly if I put it to sleep and go visit a customer.

Here’s the code:

#!/bin/sh
# Set support for jumbo frames when at home on wired network, else do not.
# Determine home network based on IP address and DNS-determined name.
# $IFACE should be set by the caller.

PATH=/sbin:/bin:/usr/sbin:/usr/bin

IFC=/sbin/ifconfig
INT="eth0"
MTU=9000
DEFMTU=1500
#name of the DNS domain to assume as "home"
HOMED="totalnetsolutions.net"
#IP Subnet to assume as "home" if DNS test fails
HOMEN="10.0.0."

test -x $IFC || exit 0

# Don't make changes to the wireless (wlan) or loopback (lo) interfaces
if [ "$IFACE" != "$INT" ]; then
exit 0
fi

# if dhcpd is still working on writing our resolv.conf, just wait a while (it's a hack, but it works).
test -f /etc/resolv.conf || sleep 15

DOM=`awk '/search/ { print $2 }' /etc/resolv.conf`
NET=`ip addr show dev $IFACE | awk '/inet / { print $2 }' | awk -F. '{ print $1 "." $2 "." $3 "." }'`

if [ "$DOM" = "$HOMED" ]; then
$IFC $IFACE mtu $MTU
elif [ "$NET" = "$HOMEN" ]; then
$IFC $IFACE mtu $MTU
else
$IFC $IFACE mtu $DEFMTU
fi

We had an issue recently where we needed a dummy krb5.keytab file for an operation prior to creating the real keytab:
echo -e "\0005\0002\c" >/etc/krb5.keytab

We ran into this bit of fun while setting up a NIS domain for testing in the lab today:
rob@rob-kubuntu3:~$ ypcat -d nisdom -h rhel5-64-2 passwd.byname
No such map passwd.byname. Reason: No such map in server's domain

It turns out this was a problem with the /var/yp/securenets file, but I’m still not sure what is wrong. The man page for ypserv shows:

A sample securenets file might look like this:

# allow connections from local host — necessary
host 127.0.0.1
# same as 255.255.255.255 127.0.0.1
#
# allow connections from any host
# on the 131.234.223.0 network
255.255.255.0 131.234.223.0

So we set up our securenets to look like this:

host 127.0.0.1
255.255.255.0 10.10.10.0

And tried to connect to the server:
rob@rob-kubuntu3:~$ ip addr show dev wlan0 |grep "inet "
inet 10.10.10.210/24 brd 10.10.10.255 scope global wlan0
rob@rob-kubuntu3:~$ ypcat -d nisdom -h rhel5-64-2 passwd.byname
No such map passwd.byname. Reason: No such map in server's domain
rob@rob-kubuntu3:~$ ping -c1 rhel5-64-2
PING rhel5-64-2 (10.10.10.213) 56(84) bytes of data.
64 bytes from rhel5-64-2 (10.10.10.213): icmp_req=1 ttl=64 time=0.823 ms

--- rhel5-64-2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.823/0.823/0.823/0.000 ms

Removing the /var/yp/securenets file allowed us access, so it wasn’t firewall or rpc or portmap issues, to the best I can determine. Adding “host 10.10.10.210″ also worked and allowed the client access. So what’s wrong with the format / man page?

I had a Bourne Shell (sh) script I needed to capture the exit status of, but it was being run through “tee” to capture a log file, so “$?” always returned the exit status of “tee”, not the script. In a nutshell, it went something like this:
#!/bin/sh
DO_LOG=$1
LOGNAME="`hostname`.out"
if [ "$DO_LOG" -eq "1" ]; then
# Logging is turned on, so relaunch ourself with logging disabled, and tee the output to the logfile
sh $0 0 | tee $LOGNAME
exit $?
fi
#... Do lots of things in the script
exit $ERRORCODE

Now, the important thing here is that the script sets very specific error codes (we have 16 defined) based on different error states, so that a tool like HP Opsware can give us different reports based on the exit status. When run with “0″ for no logging, this works great, but it requires the controlling tool to capture logs, and not all do (especially cheap “for” loops in a shell script.)

But when run with logging enabled, all of the fancy error code handling (45 lines of subroutines’ worth) gets lost, because “$!” is equal to the status code of the “tee” command. Bash scripters out there will say “but what about $PIPESTATUS ?” If we could use bash, the code would be:
#!/bin/sh
DO_LOG=$1
LOGNAME="`hostname`.out"
if [ "$DO_LOG" -eq "1" ]; then
# Logging is turned on, so relaunch ourself with logging disabled, and tee the output to the logfile
sh $0 0 | tee $LOGNAME
exit ${PIPESTATUS[0]}
fi
#... Do lots of things in the script
exit $ERRORCODE

(Note the single line change in the conditional exit.)

But, I don’t have the luxury of bash (thanks AIX and FreeBSD and Solaris 8), so we needed to get fancy…
#!/bin/sh
DO_LOG=$1
LOGNAME="`hostname`.out"
if [ "$DO_LOG" -eq "1" ]; then
# Logging is turned on, so relaunch ourself with logging disabled, and tee the output to the logfile
cp /dev/null $LOGNAME
tail -f $LOGNAME &
TAILPID=$!
sh $0 0 >> $LOGNAME 2>&1
RETURNCODE=$?
kill TAILPID
exit $RETURNCODE
fi
#... Do lots of things in the script
exit $ERRORCODE

In this last example, we’re creating the empty logfile by copying /dev/null to the logname, then starting a backgrounded “tail” command on the empty file. Because we haven’t disconnected STDOUT in the backgrounding, we will still get the screen output we desire from “tail”. The script now only writes *its* output, with redirected STDOUT and STDERR, to the log file, which is already being tailed to the actual screen. At the end of the script, we capture the true exit code, clean up the tail ugliness, and exit with the desired status code.

This does have a serious downside that if the script encounters and error and exits, the “tail” is left running indefinitely on Linux and Solaris, since the kernel there will simply scavenge the process to be owned by init. So, if you take this method, be very careful to capture all errors you may possibly encounter. Or, just use a better scripting tool. :)

It used to be that you could edit /etc/modprobe.d/blacklist and add “blacklist pcspkr” to turn off the console beeps entirely on Ubuntu / Kubuntu.  As of 9.04, the module is now called “snd_pcsp”.

So, to turn off console (not X terminal, but tty) beeps, you can do one of the following:
1) (This is my preference)

echo blacklist snd_pcsp >> /etc/modprobe.d/blacklist.conf

2) (I’ve done this, but it doesn’t affect all software)

for i in 1 2 3 4 5 6
do
setterm -blength 0 > /dev/tty$i
done

3) (Only works per shell if ~/.inputrc is included)

echo set bell-style visible >> ~/.inputrc

Enjoy more-sane editing from ttyX in the future!

Next Page »