Cover V12, I01

Article

jan2003.tar

Questions and Answers

Amy Rich

I'm trying to install Bind 9.2.1 into a chrooted jail environment on a Solaris 8 machine. I've done the following so far:

Create directories for the Bind stuff:

mkdir /var/bindjail
cd /var/bindjail
mkdir -p dev usr var etc
cd var
mkdir -p run log named
cd ../usr
mkdir -p lib local/etc local/lib share/lib/zoneinfo platform/SUNW,UltraSPARC-IIi-Engine/lib
Create a password and group entry for the Bind user:

groupadd bind
useradd -d /var/bindjail -s /bin/false -g bind -c "bind user" -m bind
I've installed Bind with the root directory of /var/bindjail, and copied in a bunch of system files:

cd /etc
cp syslog.conf netconfig nsswitch.conf resolv.conf TIMEZONE \
  /var/bindjail/etc cd /usr/local/lib
cp liblwres.so.1 libdns.so.5 libcrypto.so.0.9.6 libisccfg.so.0 \
  libisccc.so.0 libisc.so.4 /var/bindjail/usr/local/lib cd /usr/lib
cp libnsl.so.1 libsocket.so.1 libpthread.so.1 libpthread.so.1 \
  libc.so.1 libdl.so.1 libmp.so.2 /var/bindjail/usr/lib cp \
  /usr/platform/SUNW,UltraSPARC-IIi-Engine/lib/libc_psr.so.1
Then I set up my named.conf in /var/bindjail/etc and zone files in /var/bindjail/var/named. I also created the empty log files:

touch var/log/bindlog var/run/named.pid
I set up all the permissions in the jail:

chown -R root.bind /var/bindjail
chgrp -R go-w /var/bindjail
cd /var/bindjail
chmod 770 var/named var/run var/log
chown bind var/log/bindlog var/run/named.pid
chmod -R o-rwx usr var/run var/log
After getting everything set up, I try to run named, and I get the following error:

/var/bindjail/usr/local/sbin/named -t /var/bindjail -u bind
named: user 'bind' unknown.
I obviously missed a step somewhere. Any help would be appreciated.

A You seem to have missed creating the group, shadow, and password files in /var/bindjail/etc. However, you may also be missing other things required to set up a full jail, and it may not be overly necessary since BIND 9 doesn't fork for zone transfers like BIND 8 did. Instead of setting up a jail under Solaris, the easier route might be just to run named with the -t flag so that it does its own chroot after reading in all of the necessary libraries. This way you only have to copy in the files that BIND actually needs while it's running.

Q I have a file full of lines that need to be folded onto one single line. I was going to use sed to splice all of the lines together with the following:

sed -e :1 -e 'N;$!b1' -e 's/\n/ /g'
Unfortunately, this is slow, and sed has a pattern length limitation that becomes a problem when I'm working with really large files. Is there a way to get around the pattern match issue with sed, and maybe speed this up some?

A This wheel has already been invented in C, so you won't have to worry about shell globbing from the command line. Take a look on your system for a program called paste. By default, paste will join lines with a tab character, but you can modify that with the -d switch. The syntax you'll want is:

paste -sd' ' infile > outfile
Q I'm trying to take a look at SMTP transactions by using snoop on my Ultra 30 running Solaris 8. As root, I've run the following command:

snoop -ta -V | grep SMTP
I can see all of the packets just fine. I want to leave this running for a while, so I redirected the output to a log file by doing the following:

snoop -ta -V | grep SMTP > /tmp/maillog
I don't seem to be getting any output to the log file when I send myself a test message. Can I not redirect the output from snoop in this manner?

A The output of grep is buffered when you redirect it to a file or a pipe. Until you have enough data to flush the buffer (matched lines from your snoop output), you won't see any entries in your log file. If you want to force immediate output, then set up a loop to send yourself a few dozen messages. This should be enough to flush the I/O buffer to the log file.

Q We just purchased a brand new Ultra 280R with two 900-MHz CPUs. I've noticed that I'm logging the following errors via syslog, and I'm rather concerned:

SUNW,UltraSPARC-III+: [ID 471235 kern.notice] [AFT1] errID \
  0x000005d7.e5cba350 Two Bits were in error
SUNW,UltraSPARC-III+: [ID 697273 kern.info] [AFT2] errID \
  0x000005d7.e5cba350 PA=0x00000000.24000f80
E$tag 0x00000000.90124924 E$state_6 Modified
Do you know what the cause of these errors might be? They're only listed as notice and info, but they sound ominous.

A I've seen other people report similar errors, and it turned out to be a bad DIMM. You might want to run your machine through extended diagnostics during POST and see if all the memory looks okay physically.

Q I am writing a Perl script to some processing on two files, but one file matches and the other doesn't. The difference between the two files is an extra newline at the beginning of the second file.

file1 contains:
 a
 z
   
file2 contains:
 <blank line>
 a
 z
The relevant bits of the script are:

#!/usr/bin/perl -n

undef $/;
if (m/(a.*z)/s)
 {
  print "$1\n";
 }
When I run the script on the file1, there is no output. For some reason the match isn't happening correctly. When I run the script on file2, the output is, as expected:

a
z
A Your problem is that the undef line is only being executed after the Perl script reads the first line. This means that file1 will never match because the undef happens after "a" is read. In the second file, the blank line is read first, then the undef happens and the "a" is read (with the subsequent "z"), giving you your match.

If you want the undef to be executed before the -n loop starts, put it in a BEGIN block:

BEGIN { undef $/; }
I think the BEGIN block is more readable, but you can also add the -0777 argument to the Perl call instead:

#!/usr/bin/perl -n -0777
Q I've just inherited a Mandrake 7.1 machine running sendmail. This is the mail gateway for a small company, and it needed a bunch of software upgrades for security purposes. After doing all of these upgrades, I've somehow broken sendmail. When I try to update the access database, I get a suspicious error:

# makemap hash /etc/mail/access < /etc/mail/access
makemap: error opening type hash map /etc/mail/access: Invalid argument
What did I break, and how do I fix it?

A Your syntax to makemap looks fine, and I'm presuming, by the hash sign, that you're running this as root. This error is commonly seen as a result of database type/version mismatches. If you've recently done a bunch of upgrading and built things from source, it's possible that you have an old copy of, for example, sleepycat's db software installed somewhere. If you can track down this old version, remove it then rebuild and reinstall sendmail. Once you have the new version of sendmail in place, try moving and recreating the hash file from the flat text file:

cd /etc/mail
mv access.db access.db.orig
makemap hash access < access
Q I'm trying to debug a DNS problem that only appears intermittently. I'd like to see a trace of all of the DNS servers that are queried when I do an nslookup, but I don't see any built-in options to nslookup that will do that. Are there other third-party programs that might help?

A Nslookup is no longer the preferred method of doing DNS lookups. Instead of using nslookup, use dig. Not only does it report information more accurately, but it also has a load of other very verbose features, including the one that you want, trace. To look up the a record for host www.foo.bar and get a recursive listing of servers, do the following with the dig program as shipped with Bind 9.2.1:

dig +trace www.foo.bar
Q Another department has set up an internal Web server on which the whole company is supposed to keep their documentation. Because the machine is behind a firewall, they decided to leave telnet open. This seems foolish to me, even if the machine is behind a firewall. I don't want my password going over the wire in clear text, so I requested that they install OpenSSH on this machine as well. They complied, but I haven't been able to successfully log in yet. When trying to use ssh or slogin, I get the following error:

ssh_exchange_identification: Connect closed by remote host.
Sadly, I don't have access to the box at all, so I can't debug from that side. The other department sent me the sshd_config file, and everything looks fine as far as I can tell. Any hints on what may be broken or missing on that machine?

A This indicates that you got a TCP connection to the server on port 22, but the server immediately closed it before ssh could initiate a handshake. This is a common error message if OpenSSH was compiled with libwrap support and the appropriate allow entries are not in /etc/hosts.allow or /etc/hosts.deny. If the people in the other department look in their logs (presuming that they're logging failed connection attempts), then they should see that tcp wrappers or libwrap is denying the connection. If they explicitly allow your host (or your range of hosts inside the firewall), then you should be able to get things to work. If you're still having problems, see if you can convince the other department to start sshd with the -d flag and send you the output.

Q I've set up a password-protected directory using a .htaccess file under Apache 1.3.27. My users want to be able to access multiple accounts during the same session, and they're finding this to be a problem. Once they're logged in as User A, they can't change and log in as User B. Is there some way to log out User A and let the person log in as User B?

A There is no good way to enable logging in and out with basic authentication (use of the .htaccess file). There are a couple hacks you could try, but they're not elegant and rely on features of specific browsers. Instead of using basic authentication, use your favorite scripting language to manage cookies for your directory. Then you can provide a logout link and have the cookie removed from the client browser. To get started, take a look at some of the Perl cookie modules:

http://search.cpan.org/search?mode=all&query=cookie
Or take a look at the PHP documentation for setcookie():

http://www.php.net/manual/en/function.setcookie.php
Q I have a FreeBSD 4.7-STABLE machine with a very odd disk space problem. According to df, / is over 100% full. When I do a du of everything on the root partition, though, it shows up as only being about 50% full. Do you know where my missing space could have gone?

A I can think of two possibilities off the top of my head. The first is that you have a file somewhere on the root partition that was deleted while it was still open, thereby continuing to take up space. If they are on the root filesystem, try using fstat to look in places like /var/log, /var/run, /tmp, /var/tmp, etc. For example:

fstat -m -f /tmp
The other possibility is that, at some point, your machine booted without mounting all of its partitions correctly. While the machine was booted in this state, things got written to their "normal" places, which wound up being on the root partition since the proper partition wasn't mounted. Now that the problem is fixed, you have mounted over the directories where the space is being taken up, so you can't see the files that are consuming the space. To fix this, boot from a rescue floppy and mount the root partition on its own. Look for files in any directory that should just be an empty mount point.

Q I have a Sun Ultra 60 running Solaris 8 with DiskSuite 4.2.1 installed. I have four partitions on the disk -- /, /var, /usr, and /local. I have two identical disks that are identically formatted to be mirrored for the above four filesystems and swap. I ran metaroot on d0 so that it should be able to boot from either side of the mirror. I've also enabled UFS logging on all four metadevices so that recover time for a crash is minimal.

Here are my /etc/vfstab entries:

fd      -       /dev/fd fd      -       no    -
/proc   -       /proc   proc    -       no    -
/dev/md/dsk/d0  /dev/md/rdsk/d0 /       ufs   1    no   logging
/dev/md/dsk/d1  -    -          swap    -     no   -
/dev/md/dsk/d3  /dev/md/rdsk/d3 /usr    ufs   1    no   logging
/dev/md/dsk/d4  /dev/md/rdsk/d4 /var    ufs   1    no   logging
/dev/md/dsk/d5  /dev/md/rdsk/d5 /local  ufs   2    yes  logging
swap    -       /tmp    tmpfs   -       yes   -
When I went to do testing, I powered off the machine without doing a shutdown. Now, every time the machine boots, I get the following message:

The / file system (/dev/rdsk/c0t0d0s0) is being checked.
Can't roll the log for /dev/rdsk/c0t0d0s0.
/dev/rdsk/c0t0d0s0: FREE BLK COUNT(S) WRONG IN SUPERBLK (SALVAGED)
/dev/rdsk/c0t0d0s0: 4336 files, 75857 used, 880412 free
/dev/rdsk/c0t0d0s0: (365 frags, 1017307 blocks, 0.0% fragmentation)
Why can't the root filesystem be rolled back? Did I set something up incorrectly?

A Looking at the device that's being fscked, I would guess that you have a corrupted /etc/mnttab file. If the file were correct, you'd be trying to fsck /dev/md/rdsk/d0, not /dev/rdsk/c0t0d0s0. /etc/mnttab is probably an actual file as opposed to information generated by the kernel table. To fix this, you can boot off of a CD-ROM and remove the offending file. After shutting down the machine, start from the ok prompt:

boot cdrom -s
fsck /dev/dsk/c0t0d0s0
mount /dev/dsk/c0t0d0s0 /a
rm /a/etc/mnttab
Now reboot your machine from the disk. If you try testing the machine by pulling the plug now, the UFS logging should work correctly.

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.