Cover V13, i04

Article

apr2004.tar

Questions and Answers

Amy Rich

Q I'm running Solaris 9 on an Ultra 250. I was adding some groups with groupadd for a project that's taking place on this machine. A user later complained that people in other groups could see non-group readable files in his group. When I checked, I saw that all of the groups I added had the same GID! To make certain that I hadn't done something stupid when I created them initially, I added a couple more groups, and sure enough, they all had a GID of 100:

groupadd foo
groupadd bar
egrep 'foo|bar' /etc/group

  foo::100:
  bar::100:
I tried the same commands on another E250 with the same OS and patch revisions, and it worked fine. I'm rather at a loss here.

A It sounds as if you, like many other people, have removed the SUNWnisu package. Unfortunately, this package contains the /usr/bin/getent command as well as NIS-specific programs. You can specify the GID on the groupadd command line, add groups by hand, or reinstall SUNWnisu to get around this issue. In Solaris 10, /usr/bin/getent has been relocated to SUNWcsu to prevent this kind of problem.

Q We support a number of telecommuting users who want to run their own mail servers. Most of these people run FreeBSD or Linux so they can get things running, but a number of them have been exploited as open mail relays. They generally don't notice this until their provider shuts them down, and then they can't telecommute. Is there a definitive way to tell whether a machine is an open mail relay?

A There are a number of tests to check whether a machine is an open mail relay. One that I've used before is Not Just Another Bogus List (njabl.org). You can submit an IP or range of IPs to them for automatic testing every four weeks. They list open relays, proxies, open HTTP mail gateways, direct spammers, and dynamic IP pools in a set of DNSBLs that they distribute back to the community. Unlike many other sites, you can also opt out of being tested once you've opted in, assuming that the specified IP is not an open proxy already. Their policy is clearly stated at: http://njabl.org/.

Q I'm trying to run the oslevel command on an AIX machine, but I keep getting the error "unable to acquire lock". I'm not sure why this is failing or what lock it's trying to acquire. Is this a process lock, filesystem lock, license lock, or what?

A Based on what I've read, this error generally happens when /usr is full or when /usr/lib/instl/.oslevel.lock or /usr/lib/instl/.oslevel.mlinfo.cache is stale. If your /usr filesystem isn't full, try moving the abovementioned files aside if they exist. If the command still fails with the same error, try running the oslevel script with execution tracing turned on (ksh -x /usr/bin/oslevel) and running truss on /usr/bin/rm_mlcache_file (the error you saw is generated when /usr/bin/rm_mlcache_file fails) to see exactly where it dies.

Q I'm working on a project to convert a Perl script from a standalone program to a CGI program. I'd like to automate this as much as possible, so I'm -- you guessed it -- writing another Perl script to help me with the conversion. Because someone else was already working on this project, some of the work has been done, but the files are in a somewhat inconsistent state.

For example, I need to replace two newline characters with an end of paragraph marker and an <hr> tag (the beginning markers are there, but the previous person wasn't using </p>). In some places the <hr> tag is already there, and in others it's been missed entirely. In the former situation, I want to just add the </p> tag before the <hr> tag. In the latter, I need to add both tags, </p><hr>. I know there should be a way to do this in Perl, but I'm at a loss at the moment and am hoping for some advice.

A If you find a "\n\n<hr>", then you replace that with the string "\n\n</p></hr>". After the first substitution, if you find a "\n\n" that's not followed by a "<hr>" or a "</p>", you replace it with the string "\n\n</p></hr>". The first substitution is a straightforward match, but the second substitution uses a negative look ahead (?!), which makes the match succeed if the "<hr>" or "</p>" tag is missing:

while (<>) {
  $_ =~ s#\\n\\n<hr>#\\n\\n\</p><hr>#g;
  $_ =~ s#\\n\\n(?!(<hr>|</p>))#\\n\\n</p><hr>#g;
}
For more information on positive and negative look ahead and look behind assertions, run "perldoc perlre".

Q I have a daemon that runs at boot time that needs a HUP sent to it on a nightly basis. Since the process does not write a PID file, I've been trying to use pkill to restart it. My cron entry is:

0 0 * * * pkill -HUP watcher.pl
This didn't seem to be working, so I tried it from the command line. Running it from the command line also failed to restart the daemon. If I use ps and parse out the PID, though, kill works just fine. Am I misunderstanding the syntax of pkill? I thought you just gave it the name of the process instead of the PID.

A You don't specify your operating system, but I think that pkill functions the same on every OS. Your daemon is called watcher.pl, which I assume is a Perl script. Most likely if you do a ps and grep for your program, the process is called perl, and the script name is just an argument to the process. Without using any other options, pkill only works on the process name itself, not the arguments. If you use pgrep to list your process and there's no output, this is probably the case. Try pgrep -f and pkill -f to have them search the arguments as well as the program name. From the pkill man page on a Solaris 8 machine:

-f The regular expression pattern should be matched against the full process argument string (obtained from the pr_psargs field of the /proc/nnnnn/psinfo file). If no -f option is specified, the expression is matched only against the name of the executable file (obtained from the pr_fname field of the /proc/nnnnn/psinfo file).

Q We're testing some spam filtering software that automatically deletes things it considers spam. We want to add the subject of the message to the sendmail log file to help us verify that we're not throwing away good messages. Is there a feature or hack that implements message subject logging for sendmail 8.12.x?

A There's no specific "feature" to implement this, but it can be done with a simple ruleset. To begin, define a syslog map such as "maillog" and set its priority. The following example uses the debug priority instead of the default priority of info so that this information will only appear when mail.debug is specified in /etc/syslog.conf. Next, take the Subject: header (HSubject: ) and feed it through a custom rule (CheckSubj) that simply outputs it to maillog. You can also do this with any other header that you might wish to log. The following would be the entry in the sendmail.mc file (be sure that a tab separates the LHS and the RHS of the rule):

LOCAL_CONFIG
Kmaillog syslog -Ldebug
HSubject: $>+CheckSubj

LOCAL_RULESETS
SCheckSubj
R$*     $: $(maillog Subject:  $1 $) $1
Rebuild sendmail.cf and HUP the daemon, and you should start seeing subject log entries for each message.

Q I'm trying to transfer files to a FreeBSD 4.9-STABLE machine via sftp from a OS X 10.3.2 machine. I can ssh to the FreeBSD machine from the OS X machine fine, and the FreeBSD machine has the following line in the /etc/ssh/sshd_config file:

Subsystem    sftp    /usr/libexec/sftp-server
I can sftp into another user account, but mine is having issues. When I connect, I enter my password and hit return then get the error message:

Received message too long 1417113376
Does this error sound familiar? Is there an easy fix to my problem?

A Since other users can sftp to the FreeBSD machine, it's most likely something about your shell or your dot files. Try moving your shell initialization files (.bashrc, .profile, .cshrc, .tcshrc, etc) aside. From the OpenSSH FAQ:

sftp/scp fails at connection, but ssh is OK.

sftp and/or scp may fail at connection time if you have shell initialization (.profile, .bashrc, .cshrc, etc) which produces output for non-interactive sessions. This output confuses the sftp/scp client. You can verify if your shell is doing this by executing: ssh yourhost /usr/bin/true

If the above command produces any output, then you need to modify your shell initialization.

Q I've been using a .forward file to send mail to my phone and to keep a copy on the local machine. This works great, but with all the spam my address has started getting, I don't want to push everything out to my phone anymore. I'd like to just send messages under a certain size, say 2K. As far as I know, the .forward file can't do anything this complicated, so I'll need to move to something like procmail. I'm not sure how to specify my criteria in a procmail ruleset, though, because I've never used it before.

A If you're new to procmail, I highly suggest reading the procmail man pages, procmail(1), procmailex(5), procmailrc(5), and procmailsc(5). You might also want to take a look at Timmo's procmail tips page:

http://www.uwasa.fi/~ts/info/proctips.html
The answer to your specific question is quite simple, though. If procmail is the machine's LDA, just remove your .forward file and create the file $HOME/.procmailrc with the following contents:

:0
* < 2048               # a message less than 2K (2048 bytes) in size
{
  :0c                  # send it to the phone
  ! your@phone.address
  :0:                  # keep a local copy
  /your/mail/file
}


:0:                    # keep only a local copy of all other msgs
/your/mail/file
I'd also suggest adding an alias for your mailbox and adding a loop catcher with formail to avoid mailing loops that might occur if your phone address bounced a message, for example:

MBOX=/your/mail/file   # create an alias for the inbox

:0:                    # first deliver all loop msgs locally
* X-Loop: some unique text string of your choice
$MBOX

:0
* < 2048
{
  :0fwh                # add the loop header to prevent mail loops
  | formail -A"X-Loop: some unique text string of your choice"
  :0c
  ! your@phone.address
  :0:
  $MBOX
}

:0:
*
$MBOX
When testing new procmail rules, I always suggest specifying a log file and turning on full logging, too:

LOGFILE=$HOME/mail.log
VERBOSE=yes
If procmail is not the LDA, then you'll also need to invoke procmail from your .forward file in addition to creating the above .procmailrc file. Your .forward file should be world-readable and contain the following (replace YOUR_USERNAME with your actual username and make sure the path to procmail matches the path on your system):

"|exec /usr/local/bin/procmail #YOUR_USERNAME"
The #YOUR_USERNAME parameter is thrown away by the shell before procmail sees it, but it's a necessary kludge against over-optimizing sendmail programs.

Q I was reading about soft partitions in the Solaris DiskSuite documentation, and I thought this sounded useful, so I tried to set it up. I must not be doing it correctly, though. Can you tell me how to set up a 2-GB virtual partition under Solaris 8? Here's what I've done so far.

Created the state databases:

metadb -a -c 3 -f /dev/dsk/c0t2d0s7 /dev/dsk/c0t3d0s7

metadb -i

   flags        first blk     block count
a m  p  luo     16            1034         /dev/dsk/c0t2d0s7
a    p  luo     1050          1034         /dev/dsk/c0t2d0s7
a    p  luo     2084          1034         /dev/dsk/c0t2d0s7
a    p  luo     16            1034         /dev/dsk/c0t3d0s7
a    p  luo     1050          1034         /dev/dsk/c0t3d0s7
a    p  luo     2084          1034         /dev/dsk/c0t3d0s7
Created a stripe of the two disks:

metainit d8 1 2 c0t2d0s0 c0t3d0s0

metastat d8

d8: Concat/Stripe
    Size: 4204800 blocks
    Stripe 0: (interlace: 32 blocks)
        Device              Start Block  Dbase
        c0t3d0s0                   0     No
        c0t3d0s3                   0     No
Tried to create the soft partition:

metainit d1 -p d8 2GB
And received the error:

parse_ctd(): partial_ctd_str = malloc(-1)
A There's a bug report on SunSolve that matches your error output. This error occurs when there are lofi filesystems, such as UFS snapshots, mounted. You can work around this by unmounting the lofi filesystems. There's also a DiskSuite patch, 108693-18 or later, that Sun claims fixes the issue.

Amy 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: qna@oceanwave.com.