I gave a presentation on the Solaris iSCSI stack at the Atlanta opensolaris users group meeting this evening. If your curious what was discussed, you can look through the slides that were used for the presentation. I would like to thank everyone for coming out, and for being such a great audience. It was a pleasure talking about this super cool topic with everyone!!!
I use Solaris IPMP (IP multipathing) on several of my servers to allow them to keep operating in the event that a network interface or switch were to fail. Periodically I need to take IPMP managed interfaces offline, but I need to keep the IP addresses attached to those interface up and operational. Solaris comes with the if_mpadm utility, which provides a simple and straight forward way to take IPMP managed interfaces online and offline.
Prior to using the if_mpadm utility, it is useful to check the status of the interface you want to take online or offline. This can be done by running the ifconfig utility, and checking the status of the interface you are interested in taking online or offline (in this case ni0):
$ ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ni0: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 2 inet 192.168.1.5 netmask ffffff00 broadcast 192.168.1.255 groupname ipmp0 ether 0:45:e8:33:3c:97 ni1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 3 inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255 groupname ipmp0 ether 0:72:b6:d3:ee:35 lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128
To take the interface ni0 offline for maintenance, the if_mpadm utility can be run with the “-d” option (take interface offline), and the name of the interface to take offline:
$ if_mpadm -d ni0
Once if_mpadm does it’s job, the interface will be in the OFFLINE state, and the IP addresses attached to that interface will have migrated to another device in the IPMP group:
$ ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ni0: flags=289000842<BROADCAST,RUNNING,MULTICAST,IPv4,NOFAILOVER,OFFLINE,CoS> mtu 0 index 2 inet 0.0.0.0 netmask 0 groupname ipmp0 ether 0:45:e8:33:3c:97 ni1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 3 inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255 groupname ipmp0 ether 0:72:b6:d3:ee:35 ni1:1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 3 inet 192.168.1.5 netmask ffffff00 broadcast 192.168.1.255 lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128
After you finish your maintenance, you can use the if_mpadm “-r” option (bring interface online) to bring the interface online:
$ if_mpadm -r ni0
Once if_mpadm completes, you can use the ifconfig utility to verify the interface is back up, and the IP addresses have migrated back to the original adaptor (you can disable automatic failback by setting FAILBACK to no in /etc/default/mpathd):
$ ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1 inet 127.0.0.1 netmask ff000000 ni0: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 2 inet 192.168.1.5 netmask ffffff00 broadcast 192.168.1.255 groupname ipmp0 ether 0:45:e8:33:3c:97 ni1: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS> mtu 1500 index 3 inet 0.0.0.0 netmask ff000000 broadcast 0.255.255.255 groupname ipmp0 ether 0:72:b6:d3:ee:35 lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL> mtu 8252 index 1 inet6 ::1/128
IPMP is pretty neat, and the next major release has some impressive features (I especially dig ipmpstat)!
While reading through the mount(8) manual page on one of my RHEL4 servers this week, I came across the “–bind” option. This nifty option allows you to mount a directory in the file system namespace to a second location. The following example shows how to use this option to mount the directory /home/data to a second location, /opt/data:
$ mount --bind /home/data /opt/data
Once the bind mount is created, /opt/data will look and feel just like /home/data, and will show as a mounted file system when the mount utility is run:
$ mount | egrep '(bind|ext3)'
/dev/sda1 on / type ext3 (rw)
/dev/sda3 on /home type ext3 (rw)
/home on /opt/data type none (rw,bind)
This is a nifty option, and saved me having to recreate a file system on one of my servers. :)
I manage a fair number of Linux hosts, and have recently been looking for ways to securely mount remote directories on my servers for administrative purposes. NFS and Samba don’t have a terribly good security track record, so I don’t like to use either of these solutions unless truly warranted. Rsync over SSH is pretty sweet, but it’s not quite as transparent as I would like it to be. Since all of my hosts support SSH, I started to wonder if someone had developed a solution to transparently move files between two systems using SSH. After a bit of digging, I came across the super cool sshfs fuse module, which does just that!
Sshfs allows you to “mount” a remote directory over the SSH protocol, and it provides transparent access to files stored on a remote server. To use this nifty module with Fedora, you first need to install the fuse-sshfs package:
$ yum install fuse-sshfs
Once the fuse kernel modules and userland utilities are installed, the sshfs utility can be used to mount a remote directory on a local mount point. In the following example, the sshfs utility is used to mount the directory $HOME/backup on the server giddieup on the local directory /home/matty/backup:
$ sshfs -C -o reconnect,idmap=user giddieup:backup/ /home/matty/backup
Once the sshfs command completes, you can add and remove files to the locally mounted directory (/home/matty/backup in this case), and these changes will be automatically propogated to the remote server. The first time I ran sshfs I received the error “Operation not permitted.” After digging into this further, I noticed that the fusermount and sshfs utilities were not setuid root out of the box. To address this problem, I changed the group ownership of both utilities to fuse, put myself in the fuse group, added the setuid bit and changed the mode of both executables to 0750. The opensolaris community is currently porting FUSE to Solaris, and I am looking forward to eventually being able to use SSHFS on my Solaris hosts!
While messing around with Sun Cluster 3.2, I came across hatimerun. This nifty program can be used to run a program in a fixed amount of time, and kill the program if it runs longer that the time alloted to it. If hatimerun kills a program, it will return a status code of 99. If the program runs in it’s alloted time, hatimerun will return a status code of 0. To use hatimerun, you need to pass a time interval to the “-t” option, as well as a program to run in that time interval:
$ hatimerun -t 10 /bin/sleep 8
$ echo ?
0
$ hatimerun -t 10 /bin/sleep 12
$ echo ?
99
If anyone knows of a general purpose tool for doing this (preferably something that ships with Solaris or Redhat Enterprise Linux), I would appreciate it if you could leave a comment with further details.