Questions and Answers

Amy Rich

Q I'm running MIMEDefang with SpamAssassin and sendmail 8.12.6. I've noticed that there are always a number of MIMEDefang processes running, generally one for each sendmail process. Each of these sendmail processes was handling a piece of email from a domain listed as a spammer in /etc/mail/access. Shouldn't these connections have been rejected altogether instead of firing off a MIMEDefang process? If it's not this way by default, can I change it so that so many processes don't get spawned?

A Depending on when the check occurs, your MIMEDefang milter might still be invoked at connection time. If you blacklist a sender, for example, the milter is still invoked at connection and HELO time. Sendmail doesn't know to reject the sender until "MAIL FROM:". These processes shouldn't be taking up much in the way of resources beyond those needed to spawn the process itself. If your machine is being swamped by this, you may want to take a look at the mimedefang-multiplexor. The multiplexor only spawns a new process when it actually has data to pass to it.

Q We want users on our Solaris 8 machine, sheridan, to be able to chown their files to other users on the same machine. We ran into a problem doing this, and found information saying that we needed to set rstchown to 0 in /etc/system. We did this on sheridan, and things seemed to be working great on the filesystems that are automounted locally. However, we're having issues again trying to make this work on files that are automounted from another Solaris 8 machine, sinclair. We've made sure that sinclair is exporting this filesystem rw,suid and that sheridan is mounting it as such. We tested the local and NFS-mounted files with the exact same users, groups, and file and directory permissions. No dice. Is it impossible to have this work over NFS, or do we need to export the files differently?

A If you're trying to have users chown their files over to other users on an NFS share, then the machine exporting the share must also have rstchown set to 0 in /etc/system. The check happens on the machine that the filesystem is local to, not where it happens to be mounted.

Q We are setting up a Veritas VCS cluster system with Sybase with an application layered on top. How do I disable Sybase cron jobs on the inactive system and failover cron to the standby server when Sybase and the application get failed over? I want to make sure that the cron jobs are only available and running on the active server, so there is no corruption.

A Sybase cron jobs check for the existence of the script or Sybase processes and abort if they're not found. You can use this to your advantage by storing the cron jobs in files on the local disk on the active machine in your cluster. If the file doesn't exist, it knows it's not on the active server and the cron job won't run.

Q I'm being annoyed by a spammer using 216.39.112.0/20. It's more than a class C-sized space, but not an entire class B-sized space. Is there a way to block IPs at the CIDR level in the sendmail access list, or do I have to list all 16 of the class C-sized spaces by hand?

A There is no way to actually put CIDR blocks directly into your access map, since it would cause a great deal of overhead in the sendmail lookup code. The lookup code runs for all lookups, not just those in your CIDR block, so you'd see a significant performance hit. You can, however, use the cidrexpand Perl script located in the sendmail contrib directory to generate the entries you need on the fly. In your /etc/mail/access file, place the following CIDR entry along with any other access statements you currently use:

216.39.112.0/20

makemap hash access < access

cidrexpand < /etc/mail/access | makemap hash /etc/mail/access

Q I've done a default install of Apache fresh out of the box. When I start Apache with apachectl start, it displays the following error:

/usr/local/bin/apachectl[62]: sin: 0403-009 number incorrect for this command

$ULIMIT_MAX_FILES

A I've seen other people claim to have this issue with non-English locales on AIX. Are you perhaps running a non-English locale, but you just translated the message for the question? The reason it fails on a non-English version of AIX because of an issue with ulimit.

You'll see the following command defined for ULIMIT_MAX_FILES on various systems:

ULIMIT_MAX_FILES="ulimit -S -n 'ulimit -H -n'"

Q I'm trying to compile some software on Solaris 8. The software needs to link against BerkeleyDB, but it's not finding the libraries when it goes to link. I'm fairly certain that this is because BerkeleyDB puts things in the awful and non-standard place of /usr/local/BerkeleyDB. Can I globally change my LD_LIBRARY_PATH so I can easily compile this and other software with BerkeleyDB?

A In Solaris 8 and up, there's a program called crle (configure runtime linking environment). Without any arguments, it displays the current config file contents. You can add a directory to the linking environment by using the -l switch to crle. For example, if you run crle on a system that has only the defaults, you'll see:

Default configuration file (/var/ld/ld.config) not found
  Default Library Path (ELF):   /usr/lib  (system default)
  Trusted Directories (ELF):    /usr/lib/secure  (system default)

crle -l /usr/lib:/usr/local/BerkeleyDB/lib

Configuration file [3]: /var/ld/ld.config 
  Default Library Path (ELF):   /usr/lib:/usr/local/BerkeleyDB/lib
  Trusted Directories (ELF):    /usr/lib/secure  (system default)

Command line:
  crle -c /var/ld/ld.config -l /usr/lib:/usr/local/lib
  

A You might want to take a look at LUFS, a hybrid userspace Linux filesystem framework, at:

http://sourceforge.net/projects/lufs

Q I am using procmail on Red Hat 7.0 and experiencing some issues with one of my recipes. My intent was to save a copy of the message and send back a reply to the sender with a subject and body indicating that the mail was rejected. I've tried the following rule:

:0H
*  ^Subject.*(test spam)
{  
  :0
      spam

  :0:formail4.lock
    | (formail -rt -I"Subject: We do not accept spam." \
      -A"From: abuse@this.domain" \
      -A"Reply-To: spam@this.domain" \
      -A"X-Loop: abuse@mthis.domain" ;\
      cat /etc/mail/spamreply ) \
      | /usr/sbin/sendmail -t -N never -R hdrs || true
}

A You can use procmail to perform as many delivery actions as you want. What you're missing is the c flag to let procmail know that you're going to keep a copy for the next action. From the procmailrc man page:

c Generate a carbon copy of this mail. This only makes sense on delivering recipes. The only non-delivering recipe this flag has an effect on is on a nesting block, in order to generate a carbon copy this will clone the running procmail process (lockfiles will not be inherited), whereby the clone will proceed as usual and the parent will jump across the block.

You don't need to explicitly name your lockfile in the second delivery recipe. You will want to place another colon after the c so that you have a lockfile for writing to your local mail spool, though. Your block should look like:

:0H
*  ^Subject.*(test spam)
{  
  :0c:
      spam

  :0:
    | (formail -rt -I"Subject: We do not accept spam." \
      -A"From: abuse@this.domain" \
      -A"Reply-To: spam@this.domain" \
      -A"X-Loop: abuse@mthis.domain" ;\
      cat /etc/mail/spamreply ) \
      | /usr/sbin/sendmail -t -N never -R hdrs || true
}

I've tried all kinds of variants of use bytes, calling setlocale, and setting $ENV{LANG} within the program, and nothing seems to work. Here's an example of the problem area of the script:

#!/usr/local/bin/perl5.8.0 -w

use strict;
use bytes;

sub readwrite {
  local *TFILE;
  open (TFILE, "<testfile") || die;
  while (<TFILE>) {
    print "<<  $_";
  }
  close TFILE;
}

readwrite();
 
1;

A You need to use binmode to set the mode of the file you're reading to :bytes, and you also need to set the mode of STDOUT to either :bytes or :utf8, or whatever your xterm (or other) will understand. If you don't explicitly state what the mode of STDOUT should be, it will inherit the system default. Try this as your subroutine:

sub readwrite {
  local *TFILE;
  open (TFILE, "<testfile") || die;
  binmode(TFILE, ":bytes");
  binmode(STDOUT, ":bytes");
  while (<TFILE>) {
    print "<<  $_";
  }
  close TFILE;
}

A You mention "the active machine". I would bet that you are running Veritas Cluster on your Suns. VCS is known to have this behavior. It starts all agents and subprocesses at the highest possible priority. Changing the ScriptPriority in the VCS resource settings modifies the nice level of the "online" and other scripts, which becomes inherited by the Oracle processes themselves. The range for the ScriptPriority on Solaris is from -60 to 60. Assuming you're running a TS (timeshare) process rather than a RT (realtime) process, a priority of 0 maps to the standard user nice level of 0.

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.