Questions and
Answers
Amy Rich
Q We're installing a number of Solaris 8 boxes on our LAN, and we want to verify that the speed and duplex on the switch match that of the Sun network interfaces during auto-negotiation. If we have to, we'll explicitly set both sides and turn off auto-negotiation. These machines have ce0 interfaces, but ndd doesn't seem to be useful here. I tried:
ndd /dev/ce link_status ndd /dev/ce link_mode ndd /dev/ce link_speedThe link_speed shows up as 0. That doesn't seem to be meaningful, since it only seems to have a value of 0 or 1, and there are more than two speeds available. Is there another variable I should be looking at with ndd, or does link_speed have more than a 0/1 setting? A The ndd command doesn't work with ce interfaces. Use the -k switch to netstat to obtain the information you're looking for:
netstat -k ce0 | egrep 'link_speed|link_status|link_duplex'The output has the following meaning:
link_up - 0 down, 1 up link_speed - speed in Mbit/s link_duplex - 1 half duplex, 2 full duplex, 0 downQ I just tried upgrading from FreeBSD 5.1 to FreeBSD 5.2 by obtaining the source from CVS and building things from scratch. I followed the documentation at:
http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.htmlbut it crashed during make installworld. It looks like things installed ok, but obviously the crash should not have happened. Does the normal build procedure not apply to FreeBSD 5 because it's not a STABLE release yet? A When upgrading FreeBSD from source, always be sure to read /usr/src/UPDATING. The UPDATING file from 5.2 contains the following warning about the build and install process:
20031112: The statfs structure has been updated with 64-bit fields to allow accurate reporting of multi-terabyte filesystem sizes. You should build world, then build and boot the new kernel BEFORE doing a 'installworld' as the new kernel will know about binaries using the old statfs structure, but an old kernel will not know about the new system calls that support the new statfs structure. Note that the backwards compatibility is only present when the kernel is configured with the COMPAT_FREEBSD4 option. Since even /bin/sh will not run with a new kernel without said option you're pretty much dead in the water without it. Make sure you have COMPAT_FREEBSD4! Running an old kernel after a 'make world' will cause programs such as 'df' that do a statfs system call to fail with a bad system call. Marco Wertejuk <[email protected]> also reports that cfsd (ports/security/cfs) needs to be recompiled after these changes are installed. ****************************DANGER******************************* DO NOT make installworld after the buildworld w/o building and installing a new kernel FIRST. You will be unable to build a new kernel otherwise on a system with new binaries and an old kernel.Q I'm running sendmail 8.12.10 on our primary MX hosts and our backup MX hosts. Even though our primary MX machines are well connected, we're seeing a great deal of spam mail traveling through our backup MX machines. Is there some vulnerability that spammers are scanning for? I can't figure out why they're hitting both our backup and primary MX hosts. A Many spammers use the backup MX hosts because some sites that are doing spam filtering are only doing it on their primary MX hosts. Spammers especially try to circumvent hosts using DNSBL rulesets on the primary MX hosts only. If spammers inject mail through the unprotected backup MX hosts, then the primaries will see the spam as coming from the backup MX hosts and not the original blocked host. Q I'm running an ftp server that allows uploads to a central area. I have a cron job that checks this area and copies files off to a staging directory every half hour. Occasionally files get copied in the midst of uploading, and the copied file is therefore incomplete and corrupted. Is there an easy way to move only files that have been sitting around long enough to have transferred completely? I'm not sure how long that time frame would need to be, though, because uploads vary in size. A Instead of waiting a specific period of time, check whether the file is open before copying it off into your staging area. You don't say which operating system you're running, but the tool lsof runs on most Unix-like systems. You may also have a tool that comes with the OS, like fuser, that will suffice. Here's some sample output for /var/log/syslog on a Solaris 8 machine:
lsof /var/log/syslog COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME syslogd 150 root 9w VREG 85,4 0 106343 /var/log/syslog fuser /var/log/syslog /var/log/syslog: 150oHere's some output for /etc/passwd, which isn't open:
lsof /etc/passwd fuser /etc/passwd /etc/passwd:If lsof or fuser doesn't show the file as open, then it's safe to copy. If the file is open, lsof shows the process that has the file open, the PID of the process, the user, the file descriptor number and method of access, the type of node associated with the file, the device numbers of the file, the size of the file or the file offset in bytes, the node number of the file, and the file name. The contents of the FD field have the following meaning: FD is the File Descriptor number of the file or: cwd -- Current working directory
Lnn -- Library references (AIX)
ltx -- Shared library text (code and data)
Mxx -- Hex memory-mapped type number xx
m86 -- DOS Merge mapped file
mem -- Memory-mapped file
mmap -- Memory-mapped device
pd -- Parent directory
rt -- Droot directory
txt -- Program text (code and data)
v86 -- VP/ix mapped file FD is followed by one of these characters, describing the mode under which the file is open: r -- For read access
w -- For write access
u -- For read and write access
space -- If unknown and no lock character
- -- If unknown and lock character If the file is open, the fuser output displays the process ID of the program using the file followed by a letter specifying the type of access (some types are only available on certain operating systems): a -- If the process is using the file as its trace file in /proc
c -- If the process is using the file as its current directory
e -- If the process is using the file as the executable being run
f -- If the process is using the file as an open file
m -- If the process is using the file as a mmaped or shared lib
o -- If the process is using the file as an open file
p -- If the process is using the file as the parent of its current directory
r -- If the process is using the file as root directory
s -- If the process is using the file as a shared lib
t -- If the process is using the file as its text file
y -- If the process is using the file as its controlling terminal Q I'm running OpenSSH 3.7.1p2 on a Beowulf cluster of Linux machines. When a machine drops out of the cluster and jobs fail over to another node, users are no longer able to connect to the logical cluster name using ssh because the host key has changed. It's non-optimal for them to have to know the name of each cluster node (and self-defeating, because a node might be up or down at any given time), but ssh clearly needs that granularity. The sys admins also need that granularity, since we need to occasionally need to operate on specific machines instead of on the cluster as a whole. What's the best method to deal with a situation like this? A The issue, as you pointed out, is that the users who are experiencing problems have a known_hosts hostname/key pair entry for the cluster name, and not an individual machine name. When the key changes but the host name stays the same, ssh believes that an IP/hostname hijacking may have taken place and won't allow password authentication. There are a few methods to work around this depending on whether you're more concerned about security or ease of use and whether you have control over the machines from which the users are ssh'ing. The first method is to put the same host key(s) on every system. Check sshd_config for any HostKey lines and be sure to copy those and the corresponding .pub files to each machine. Now users will always see the same host key no matter which node they connect to. You can also connect to the node by name and not have any problems. The downside is that once the key is compromised, all hosts are compromised. The second method is to modify each user's known_hosts file so that each node has its own entry and is also tagged with the cluster name. This takes effort on the user's part and may be difficult to keep up with if new nodes are being added or changed continuously. If you rarely add or change nodes, this can be accomplished through a large one-time addition, supplied by the sys admins, to each user's known_hosts file. The new hostname/key pairs would change from:
hostname,IP key-type keyto:
hostname,IP,cluster-name key-type keyFor example:
node1,192.168.1.1,cluster,cluster.my.domain ssh-dsa AAAA... node2,192.168.1.2,cluster,cluster.my.domain ssh-dsa BBBB... ... nodeN,192.168.1.N,cluster,cluster.my.domain ssh-dsa ZZZZ...If all of the users are connecting from centralized Unix-like machines that the systems administrators control, add the above entries to the global ssh_known_hosts file instead of modifying the known_hosts file of each individual user. If possible, this is the best option because no effort is required on the part of the user, and the integrity of each node is not compromised when one key is cracked. Q I have a laptop that I connect to the serial ports of our machines in the datacenter to get console access. Right now I'm using Hyperterm, but it's pretty rotten and I'd like to find something better. Any suggestions for something that will handle Solaris servers and perhaps do ssh, too? A Since you list Hyperterm, I'm going to presume you're using some form of Microsoft Windows on your laptop. If you want to replace Hyperterm for serial and ssh, try using one of the following:
- The free ssh plugin to Teraterm, TTSSH, (http://www.zip.com.au/~roca/ttssh.html) only supports SSH v1.5, so it's not useful if you need to connect to SSH v2 servers, which are more secure.
- SecureCRT (http://www.vandyke.com/products/securecrt/) is a commercial product but supports both versions of the SSH protocol as well as serial, telnet, and a few other protocols.
install_type initial_install system_type standalone partitioning explicit filesys rootdisk.s0 1024 / logging filesys rootdisk.s1 1024 swap size=512m filesys rootdisk.s3 1024 /usr logging filesys rootdisk.s4 1024 /var logging filesys rootdisk.s7 20 /spare/md0 filesys rootdisk.s5 free /files logging filesys c0t1d0s0 1024 /spare/root filesys c0t1d0s1 1024 unnamed filesys c0t1d0s3 1024 /spare/usr filesys c0t1d0s4 1024 /spare/var filesys c0t1d0s7 10 /spare/md1 filesys c0t1d0s5 free /spare/filesIf you opt not to use JumpStart or need to partition a disk after the fact, you can still get the job done with one command chain instead of using format. This example assumes that your boot disk is c0t0d0 and your mirror disk is c0t3d0:
prtvtoc /dev/rdsk/c0t0d0s2 | fmthard -s - /dev/rdsk/c0t3d0s2Amy Rich, president of the Boston-based Oceanwave Consulting, Inc. (http://www.oceanwave.com), has been a UNIX systems administrator for more than 10 years. She received a BSCS at Worcester Polytechnic Institute, and can be reached at: [email protected].
