Article

apr2002.tar

Questions and Answers

Amy Rich

Q I want to set up IP Multipathing on my Netra T1. I've heard it's now possible with Solaris 8, but it doesn't seem to be well covered in the docs. Any pointers?

A First, be sure that you have have media dated 10/00 or later; that's when multipathing was introduced. There are several reference documents that will be of use to you.

An article on the blueprints site: http://www.sun.com/blueprints/0801/Multipathing-updt1.pdf
The IP Network Multipathing Administration Guide: http://docs.sun.com/ab2/coll.780.2/IPNETMPADMIN/
A Sys Admin article written by Peter Baer Galvin: http://www.samag.com/documents/s=1441/sam0111i/0111i.htm
A short HOW-TO style document, by Doug Hughes: http://www.eng.auburn.edu/~doug/howtos/multipathing.html

The basic steps are:

1. Make sure you have two working NICs in your machine (the Netra T1 comes with two already, so you should be fine there).

2. Configure the machine to use actual Ethernet addresses by doing:

eeprom 'local-mac-address?=true'

3. Obtain four IP addresses (two floating public addresses, one for each NIC, and two fixed private addresses, one for each NIC).

4. Create /etc/host entries for all four IPs, tying the actual machine name to one of the public IPs.

5. Set up the secondary interface to use a different MAC address.

6. Create /etc/hostname.<interface> files according to the hostnames you defined in /etc/hosts.

7. Tweak failover parameters in /etc/default/mpathd.

If you're using more than two NICs, be sure to take that into account for the above numbers (two IPs per NIC). I suggest reading Doug's document for some tips and examples to help you along.

Q I want to automatically sync a few directories from one AIX server to a bunch of FreeBSD clients. The transfer will take place over the public network and the data is somewhat sensitive, so both the authentication and data transfer have to be encrypted. I've taken a look at things like scp and sftp, but I don't want to transfer all of the files every night if nothing has changed. There also doesn't seem to be any good way to automate things since I don't want to have to use expect. Any suggestions?

A There are a few programs that are well suited for just this sort of application, and you can do them securely if you already have ssh. For starters, take a look at rsync (http://rsync.samba.org/). This is probably the best tool for what you're trying to accomplish, since you mentioned that you only want to sync a few directories. If you're looking for something more flexible and powerful, try cfengine (http://www.cfengine.org/).

You can also combine the two and have cfengine use rsync over ssh for its file transfers. Take a look at the following page to get you started if you're interested in combining the two:

http://www.cs.arizona.edu/people/jdavis/cfengine.html

I also suggest doing ssh DSA key authentication (with no passphrase) if you're setting up a simple automated job via ssh. Using DSA auth allows you to limit the action that ssh can take when the key is used. This example is for using rsync over OpenSSH and would exist as $HOME/.ssh/authorized_keys2 on the machine from which you're trying to pull down (MachineA):

command="/usr/local/bin/rsync --server --sender -vur . /Directory/To/Sync/"  <key>

<key> would be the $HOME/.ssh/id_dsa.pub from the machine on which you're calling rsync (MachineB) and would be of the form:

ssh-dss <a long string of characters> remoteuser@remotehost

So, to copy MachineA:/Directory/To/Sync to MachineB:/Local/Directory, execute the following command from MachineB:

/usr/local/bin/rsync -vure "/usr/local/bin/ssh -c blowfish" machineA:/Directory/To/Sync /Local/Directory

The user executing this command must be able to read all of the files in MachineA:/Directory/To/Sync and be able to write to MachineB:/Local/Directory, of course.

Q Our environment here is completely Solaris (Ultra SPARCs). I've advocated getting KVM switches for our machine room since I've found them to be invaluable in the past. When I proposed this idea in a meeting, however, the developers declared that KVM switches are unnecessary because everything can be done via the network. The developers have been here longer than I have, so they have more sway with the president of the company (we're fairly small). I'm looking for suggestions to help me convince the president that we should purchase KVMs because they'll make my job as a sysadmin easier. Any tips on how I can sway him to my point of view?

A I'm afraid that I'll have to side with your developers on this issue. If you're doing PC administration, then KVMs are pretty much the only way to go. They're primarily designed to get around the BIOS bootstrapping issue. Since you have all Suns at your workplace, though, you have the OBP, making the KVMs unnecessary and, in some cases, a hindrance. As your developers stated, most things can indeed be done over the network (all X applications, for example, if you actually have X installed on your servers), and those things that can't be, usually need to be done at the prom (OBP) level.

What you really want to push for is a terminal server, and I'm betting that you can probably sway both the developers and the president to your cause on that account. It would be optimal if you get a modem card and a terminal to attach to the terminal server for instances where the network is completely down. If you have the budget, also get an IP addressable power switch so you can remotely power-cycle machines.

Here are a few points you can bring up in your crusade to get a terminal server. Upper management especially wants to know what it will save them on the bottom line, so be sure to emphasize monetary savings when possible:

Multiple people can use the terminal server to connect to multiple machine consoles at the same time (this is many-to-many, unlike a KVM, which is one-to-many).
The terminal server can be set up for encrypted logins if you purchase a terminal server that supports ssh.
The terminal server can be set up on a restricted network to further protect console access.
The terminal server will occupy less space in the machine room (fewer cables and no monitors, keyboards, or mice).
Sys admins do not have to work in the unpleasant conditions (cold, not ergonomic, etc.) of the machine room. There also will be less waste of energy in the machine room and less chance that someone will accidentally trip over a network cable or power cord.
Many terminal servers have some sort of capture buffer so that quickly scrolling errors or boot sequences can be logged and reviewed for speedier debugging.
Hardware costs are lower. For example, many terminal servers can be had for less money than most KVMs that support Suns.
No need to purchase frame buffers, mice, and keyboards for all systems.
KVM cables are more costly than serial cables (which you can make in-house fairly easily if you have to).
You can also hook up your network equipment and other non-PC hardware to the terminal server.
Some Sun machines (e.g., the Netra X1s and T1s) do not have a slot for a frame buffer and the console MUST be accessed via the serial port. Extra hardware would have to be purchased for these machines anyway.
Remote administration via a terminal server allows separation of administrative power and physical access. This can be especially important if you have customers at remote sites or machines co-located in cages.
Remote administration allows the sys admin to respond more quickly to off-hour incidents, which can save big bucks in downtime and overtime/comptime costs.

Good luck getting your new hardware!

Q I'm ssh'ing from a Windows box to a UNIX box and running screen. I've tried putty, ttssh, and SecureCRT, and they all exhibit the following problem. When I hit Control-\ (which, preceded by the screen hotkey, should be mapped to quit in screen), everything dies, not just the window I'm in. According to the screen man page, I'm doing this right, but I'm seeing really unsuspected results. Is the man page incorrect, or have I done something wrong?

A Most likely Control-\ is set in to quit in your shell session. If you do:

stty -a | grep quit

and you see:

quit = ^\

you've found your culprit. To disable this in the shell, you can do the following in the shell from which you start screen:

stty quit undef

You can also use the screen hotkey and then type in :quit instead of Control-\ if you don't want to change your shell settings.

Q We've made a bunch of custom Solaris 8 packages for our customers to install on their machines. When we find the occasional bug, we want to make patches available to them for download, instead of making them install the whole package again (this also makes it easier to track which version they really have installed with showrev -p). I know how to make the packages, but I've never seen documentation on how to make patch files. Looking at the patches from Sun, they should be somewhat similar, but I'm not sure what the actual differences are. Will I need to use pkgadd to add my patches, or is there some way I can create patch files that can be applied with patchadd?

A You're correct in assuming that patches are just like packages in many respects. A patch is what's sometimes called a "sparse" package. For those people who aren't familiar with package creation, take a look at:

http://docs.sun.com/ab2/coll.45.13/PACKINSTALL/

As part of that document, there's a section on Advanced Packaging Techniques. Under this book, they cover creating patch files, among other things:

http://docs.sun.com/ab2/coll.45.13/PACKINSTALL/%40Ab2PageView/idmatch(CH6ADVTECH-41)

The sections on patches cover the six basic parts to a patch file:

checkinstall script
preinstall script
Class Action script
postinstall script
patch_checkinstall script
post_checkinstall script

Looking at the examples they provide and dissecting some of the Solaris OS patches should give you a practical understanding of how to implement your own.

While it is possible to add the patch with the pkgadd command (it is, after all, just another package), you NEVER want to do this because it doesn't register the patch information with the database. That means it won't show up under showrev -p and you will lose the ability to back out the patch. Always add your patches with the patchadd command.

Q I have a FreeBSD 4.4-STABLE machine (800-MHz Duron) that keeps crashing when I run seti@home. I've also had it crash when I attempt to do a "make buildworld", but not when I do a simple kernel build. This machine is about two months old, and it stays up just fine unless I do one of those two things. Do I have bad hardware? Is it a FreeBSD incompatibility? Am I tickling some sort of weird bug somewhere?

A There is always some chance that you've hit a software bug or that you have bad hardware. The first place I'd look, though, is how hot your machine is running (CPU and case temperatures), verifying that it has proper cooling. Both seti@home and building the FreeBSD userland can be very CPU intensive, and some PCs do not ship with a sufficiently rated fan or heat sink for sustained intensive use. If you find that your CPU is running hot, you might want to try putting a small bit of thermal compound (just enough to fill in the irregularities on the chip surface, not so much that it's acting as an insulator) between your CPU and the existing heat sink. If that doesn't help, try replacing the fan and/or heat sink with a better one. You may have to go as far as to get a different case (or modify your existing case) if you're really tight on space.

If it's not a temperature issue, search through the FreeBSD mail archives (http://www.freebsd.org/search/search.html#mailinglists) for your chipset and OS revision. It could also be some other piece of hardware you have in the machine, too, so you may want to search for other pieces of hardware you have in or attached to the machine.

Q I want to add a CDRW drive to my Sun to pump out a large number of data CDs to be shipped to our branch offices overseas (doing the data transfer via network isn't an option). I know that Suns can be picky about the kind of devices that it will support (driver wise), so I was wondering if there was a blessed list of third party vendors/products from Sun. Also, what software should I be using to write the discs?

A Sun has a list of their supported third party I/O devices at:

http://www.sun.com/io_technologies/storagesolutions.html

Plextor has the most number of supported CDRW drives out, so that's probably your best bet. As to software, if you're using Solaris 8 10/00 or later, there is a tool called cdrw on your supplemental CD. If you have a pre-Solaris 8 OS, there's also Jörg Schilling's cdrecord; check out:

http://www.fokus.gmd.de/research/cc/glone/employees/jörg.schilling/private/cdrecord.html

Jörg's page also contains some good CD/CDR/CDRW links.

Q I've installed TCP wrappers and am using it to allow/disallow IMAP access to a machine to allow some people to pick up their mail while giving the host some minimal protection. My /etc/hosts.deny file (tcp wrappers is compiled with -DPROCESS_OPTIONS to handle both allow and deny statements in the same file) looks similar to the following (the names and IPs have been replaced):

imapd : LOCAL foo.bar.com 10.2.2. : ALLOW
ALL : ALL : banners /usr/local/etc/banners : DENY

Some of the allows seem to be working:

Feb 22 9:47:16 server imapd[11753]: connect from 10.2.2.5

But some seem to be failing:

Feb 22 10:19:13 server imapd[11753]: warning: can't verify hostname:  gethostbyname(external.machine.com) failed
Feb 22 10:19:13 imapd[11753]: refused connect from 192.168.2.12

192.168.2.12 is the IP address of external.machine.com in this case. So, why does tcp wrappers allow the first connection through, but not the latter? They're both checking IPs and not hostnames. Why does gethostbyname even come into the picture?

A It sounds like you've compiled tcp wrappers with -DPARANOID. If the forward and reverse resolutions don't match, then tcp wrappers won't even look at your ALLOW and DENY rules. The correct way to solve your problem is to fix your DNS. If you disable PARANOID when you compile, though, this should also allow these people to pick up their mail. You are, of course, sacrificing security when you do that. If you want to take a middle approach to security, compile without -DPARANOID but have the following lines:

imapd : 192.168.2. : ALLOW
imapd : PARANOID : banners /usr/local/etc/banners : DENY
imapd : LOCAL foo.bar.com 192.168.2. 10.2.2. : ALLOW
ALL : ALL : banners /usr/local/etc/banners : DENY

This way the machines with the bogus DNS entries can pick up their mail, but you then check for mismatched forward and reverse name resolution before you allow anything else.

Q I have a quick and, hopefully, easy Perl question. I'm writing a script to do reporting for a number of clustered Web servers. All of these servers are named webNN, where the N's are digits. The problem I'm having is that I'm trying to do a foreach loop like the following:

foreach $servernum (01, 02, 11, 12) {
  print "web$servernum\n";
}

I wind up with web10 and greater printed out correctly, but web01 coming out as web1. Obviously, this isn't going to work since I later need to do pattern matching based on the name. Is there a way to get the machine names to print out correctly?

A As long as you don't have machine names greater then 99 (i.e., you will ALWAYS have two digits), you can do the following:

foreach $servernum (1, 2, 11, 12) {
  printf ("web%02d\n", $servernum);
}

A leading 0 on a number will indicate to Perl that you want to use octal numbers, so make sure to leave out the leading 0 for 1-9. If you use 01 instead of 1, Perl will error, complaining that you're using an illegal octal digit in your print statement.

Amy Rich, president of the Boston-based Oceanwave Consulting, Inc. (http://www.oceanwave.com), has been a UNIX systems administrator for more than five years. She received a BSCS at Worcester Polytechnic Institute, and can be reached at: qna@oceanwave.com.