Questions 
              and Answers
             Amy Rich
              Greg Shapiro sends in the following suggestion about running named 
              as a non-root user (from the May issue: http://www.samag.com/documents/s=7933/sam0305j/0305j.htm):
              Greg writes: You advised the reader to change the permissions 
              of /etc/namedb to bind. The problem with doing so is that 
              if a vulnerability is found and an attacker can break into the bind 
              account, they will be able to overwrite all of the files in /etc/namedb, 
              including your configuration file and master zones. A better way 
              of managing that is to create a separate directory for slave zones 
              and only have that directory owned by bind.
              For example, in /etc/namedb/named.conf:
              
             
options
{
...
         directory             "/etc/namedb";
         dump-file             "stats/named_dump.db";
         memstatistics-file    "stats/named.memstats"; // BIND 8 only
         pid-file              "stats/named.pid";
         statistics-file       "stats/named.stats";
...
};
zone "example.com"
{
         type slave;
         file "slave/example.com";  // Note the slave/ subdirectory
         masters
         {
                  192.168.26.10;    // ns.example.com
         };
};
            Then you can:
             
             
mkdir /etc/namedb/stats /etc/namedb/slave
chown root:wheel /etc/namedb
chown bind:bind /etc/namedb/stats /etc/namedb/slave
 
            Q I'd like to have sendmail use 
            multiple virtual user tables located in two different directories 
            (it has to do with the way files are arranged on one of our mail servers). 
            Is there a directive I can use in my cf file to facilitate this?
             A  If you can, you're much 
              better off combining all of your virtualuser tables into one file 
              before you pass them to makemap:
              
             
cat /full/path/to/virtuser1 /full/path/to/virtuser2 \
  /full/path/to/virtuserN | makemap hash /etc/mail/virtusertable
 
            Having one unified database table means that an address only needs 
            to be looked up once. If you must have separate database tables, you 
            can use a sequence map, but it's possible that an address may 
            be looked up once for each database table that you have. Fewer tables 
            are better if you choose this route.
             From the sendmail operations manual (doc/op/op.me):
              sequence The arguments on the 'K' line are a list of 
              maps; the resulting map searches the argument maps in order until 
              it finds a match for the indicated key. For example, if the key 
              definition is:
              Kmap1 ... 
              Kmap2 ... 
              Kseqmap sequence map1 map2
              then a lookup against "seqmap" first does a lookup in 
              map1. If that is found, it returns immediately. Otherwise, the same 
              key is used for map2.
              With sendmail 8.10 and greater, you can specify the following 
              in your mc file:
              
             
LOCAL_CONFIG
Kvirtuser0 hash /etc/mail/virtusertable
Kvirtuser1 hash /full/path/to/second/virtusertable
FEATURE('virtusertable', 'sequence virtuser0 virtuser1')
            Q Do you know if there is a way to disable 
            reverse DNS lookups (IP addresses to hostname mapping) in BIND? I 
            am running a BIND 9 caching-only name server, and I want it to try 
            to find the answers for name to IP address lookups, but any reverse 
            lookup attempt should be suppressed (e.g., by always returning information 
            to the asking application that the mapping could not be found). Is 
            that possible?
             A  I'm not certain why you'd 
              want to accomplish this, since it has the potential to break a good 
              many things. You can do this by specifying your own top-level zone 
              files. Be sure that these entries are ONLY handing out information 
              to your own machines, and not any others. Put the following in named.conf. 
              If you're only using IPv4, you don't need the latter two 
              entries:
              
             
 zone "in-addr.arpa" {
         type master;
         file "blackhole";
         notify no;
 };
 zone "ip6.arpa" {
         type master;
         file "blackhole";
         notify no;
 };
 zone "ip6.int" {
         type master;
         file "blackhole";
         notify no;
 };
            The zone file blackhole would contain the following:
             
             
$TTL 6H
@ IN  SOA your.primary.server. contact-address.your.domain. (
                  2002012004      ; serial
                  1D              ; refresh
                  2H              ; retry
                  1W              ; expiry
                  2D )            ; minimum
@ IN  NS  your.primary.server.
 
            Q I have a Solaris 9 server that's 
            running X. How do I restrict port 6000 to just localhost? I want local 
            users to be able to use X but, because of security concerns, I don't 
            want remote users to have direct access to port 6000.
             A  Local users won't be using 
              TCP/IP to connect to the X server, so you can restrict TCP/IP connections 
              to port 6000. "What's New in the Solaris 9 Operating Environment", 
              found at:
              
             
http://docs.sun.com/db/doc/806-5202/6je7shk4c?a=view
 
            says the following:
             
             
New options enable system administrators to control which 
transport methods are used by the Solaris X server. Administrators 
who need to secure a host can now disable remote TCP connections 
directly to the Xserver, while allowing encrypted connections to 
be tunneled through Secure Shell. See the description of the 
-nolisten option in the Xserver(1) man page for further details.
 
            The man page for Xserver(1) contains:
             
             
-nolisten trans-type
       Disable a transport type. For example, TCP/IP connections 
       can be disabled with  -nolisten tcp
	    
            Q I have a color HP postscript printer 
            that's capable of doing landscape output. I already have a standard 
            portrait jobs, but I want to set up a queue to exclusively do landscape 
            jobs. I want to just be able to specify this alternate queue instead 
            of having to specify the landscape option every time I print. There 
            should be an easy to set this up, but I'm not sure what it is.
             A  Using HP's hppi software, 
              create a queue that's identical to your existing queue in all 
              but name. Let's say that your existing queue for portrait jobs 
              is called lp1. You could name this new queue lp1l (the trailing 
              l for landscape). Make sure you stop lpsched with the command:
              
             
/usr/sbin/lpshut
 
            Hand edit the text file /etc/lp/printers/lp1l/configuration and change 
            the line:
             
             
Options:
 
            to:
             
             
Options: landscape
 
            The option keywords that you put on the "Options:" line 
            are the ones that you would normally put on the lp command line after 
            -o. If you already have some options specified in your configuration 
            file, you can add a command and then the landscape directive. The 
            following will print 12 characters per inch, landscape, for example:
             
             
Options: 12,landscape
 
            For the various options you can use, take a look at the appropriate 
            man page under /opt/hpnpl/man/man1/. (You may wind up using ledger 
            instead of landscape depending on your printer type.)
             Finally, restart lpsched:
              
             
/etc/init.d/lp start
 
            Q I'm fairly new to FreeBSD and 
            am having some trouble getting my machine to stay up. I've been 
            playing around with the machine a lot recently, and have had it freeze 
            (my own fault) so that I had to power cycle it. I've mucked around 
            with fstab, but I didn't touch the data in /usr (ad2s3f).
             Now when I boot FreeBSD, it gives me this error after less than 
              a minute of uptime:
              
             
mode = 041777, inum = 7301, fs = /usr panic: ffs_valloc: dup alloc 
syncing disks, buffers remaining. panic:bdwrite buffer is not busy
Uptime: 23s
Terminate ACPI
Automatic reboot in 15 seconds - press a key on the console to abort
Press a key on the console to abort or switch off the system now
 
            With so little uptime, I don't have time to modify /etc/fstab 
            or run fsck. How I can fix this? I don't want to have to reinstall 
            everything from scratch now that I finally have the machine just the 
            way I want it.
             A  My first suggestion would be 
              to try and boot single user, since the corruption is on the /usr 
              filesystem. Hit a key during the 10-second countdown before FreeBSD 
              boots. Boot single user by typing:
              
             
boot -s
 
            When asked for a shell, just hit enter to accept the default sh. At 
            this point, you should have access to /sbin/fsck (statically linked). 
            I'd suggest fscking each filesystem, since you've been crashing 
            and power cycling this system a lot. This should fix the bad file 
            in /usr. If not, you can always try selecting the fixit option while 
            booting from floppy. See:
             
             
http://www.freebsd.org/relnotes/4-STABLE/installation/i386/trouble.html
 
            for more details on creating/using boot floppies and fixit disks.
             Before you fix things, you also may want to use find to 
              determine what the problem file is:
              
             
find /usr -inum 7301 -print
 
            Q Is it possible to use wildcards in 
            the /etc/mail/access? I've got spam coming in from emailoffers#.biz 
            where # is 1-200. I thought they might just all be coming from the 
            same IP or IP range, so I was going to block them that way, but that 
            doesn't appear to be the case. I want to block these idiots without 
            adding 200 entries to my access file, though.
             A  You can't use wildcard with 
              access_db, but 200 entries really isn't that many. It's 
              trivial to generate these entries with a short shell script. If 
              you don't want to populate your access file that way (perhaps 
              they keep adding more hosts, and you just want to catch them ALL 
              and not worry about it again), you can instead use a regex map. 
              From the sendmail README file:
              
             
              The regex map can be used to see if an address matches a certain 
              regular expression. For example, all-numerics local parts are common 
              spam addresses, so "^[0-9]+$" would match this. By using 
              such a map in a check_* rule-set, you can block a certain range 
              of addresses that would otherwise be considered valid.
             
             And from cf/README:
              
             
              If you wish to include your own checks, you can put your checks 
              in the rulesets Local_check_relay, Local_check_mail, and Local_check_rcpt. 
              For example, if you wanted to block senders with all numeric usernames 
              (e.g., [email protected]), you would use Local_check_mail and the 
              regex map:
               
                
LOCAL_CONFIG
Kallnumbers regex -a@MATCH ^[0-9]+$
LOCAL_RULESETS
SLocal_check_mail
# check address against various regex checks
R$*                             $: $>Parse0 $>3 $1
R$+ < @ bigisp.com. > $*        $: $(allnumbers $1 $)
R@MATCH                         $#error $: 553 Header Error
 
            
            So, you could write the following additions to your mc file:
             
             
LOCAL_CONFIG
Kcheckaddress  regex -a@MATCH emailoffers.*\.biz
LOCAL_RULESETS
SLocal_check_mail
R$*                      $: $>Parse0 $>3 $1
R$+                      $: $* $| $(checkaddress $1 $)
R@MATCH                  $#error $: "553 Rejected mail from emailoffers"
 
            Q My ISP's news server runs Typhoon 
            v1.2.3 and has been generating lots of duplicate articles recently. 
            These duplicates have the exact same body and message-id, and differ 
            only in the Path: and Xref: headers. Is this a known problem with 
            Typhoon, or does my ISP have something misconfigured?
             A  I'm not overly familiar 
              with the guts of Typhoon, but if you're seeing messages with 
              the same Message-Id but different Xref headers, your ISP may have 
              issues with their history file. The history file is what keeps track 
              of the Message-Id numbers to prevent duplicates and to allow lookup 
              of articles by Message-Id. I would speculate that the history file 
              is corrupted or that your ISP sys admins have configured the size 
              of the history file to be too small.
              Q Our workplace has a number of 
              scripts that they want to convert into binary executables. Is there 
              some utility to do this?
              A  Really this depends on what shell 
              you're using to write your scripts, and exactly what you're 
              trying to accomplish by turning them into "binaries."
              If you've got Bourne or Korn shell, and you don't mind 
              paying a rather hefty two-year license for a commercial product, 
              then take a look at SHELL-LOCK:
              
             
http://www.cactus.com/products/cactus/shell-lock.html
 
            If you've just got Bourne shell code and you want to output C 
            code that you can compile, take a look at CCsh:
             
             
http://www.comeaucomputing.com/tryccsh/
 
            This still has the benefit of actually obfuscating the code, if that's 
            your end goal.
             If you're writing ksh93 code, then you can use shcomp, which 
              comes with the ksh93 distribution at:
              
             
http://www.research.att.com/sw/download/
 
            The output of shcomp is an intermediate, machine-independent file 
            that is recognized by ksh93 via the magic number. This isn't 
            really compiled, per se, but it may still work for your circumstances. 
            The man page for shcomp is at:
             
             
http://www.research.att.com/~gsf/man/man1/shcomp.html
 
            There's also a a program called shc:
             
             
http://www.datsi.fi.upm.es/~frosal/frosal.html
 
            that chunks up your shell code and feeds it through argv.
             Q I'm using OpenSSH 3.5p1 on 
              a FreeBSD machine and connecting to an AIX machine acting as a gateway 
              and running the same version of OpenSSH. I want to telnet to an 
              internal AIX machine and run applications, making sure that my display 
              is set to my FreeBSD machine. Essentially, I want to do the following:
              
             
ssh -X gateway
telnet endhost
xclock
 
            How do I need to set up my DISPLAY on endhost to make the ssh tunnel 
            of X work?
             A  First, you need to configure 
              sshd to allow non-loopback connections by putting the following 
              in your sshd_config file and restarting or HUPing sshd:
              
             
X11UseLocalhost no
 
            Once you've made this change, you can use xauth to determine 
            what your MIT-MAGIC-COOKIE is on the gateway, so that you can make 
            connections from the endpoint. Starting from your FreeBSD machine:
             
             
ssh -X gateway
echo $DISPLAY
 
            This should give you output of:
             
             
gateway:10
 
            Then determine the MIT-MAGIC-COOKIE:
             
             
xauth list $DISPLAY
 
            which should output:
             
             
gateway:10  MIT-MAGIC-COOKIE-1  <some string>
 
            Now you can telnet to the endhost and set the display and add authorization 
            to talk to the X server:
             
             
telnet endpoint
setenv DISPLAY gateway:10
xauth add gateway:10  MIT-MAGIC-COOKIE-1  <some string>
 
            You should now be able to start whatever X applications you want.
             If you have the option to use ssh inside the gateway, ssh will 
              transparently set up the display for you so that you don't 
              have to do the above steps.
              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: [email protected].
            |