 Questions
and Answers
Amy Rich
Q I've just installed the new release
of Solaris 10, and it looks really cool! One issue I'm having, however,
is that I can't figure out how to button down security and turn
off most of the services at boot time. It used to be that you'd
just delete the necessary files in /etc/rc*.d/, but that doesn't
seem to work for a lot of things in Solaris 10. How are you supposed
to disable stuff under this new version of the OS, and why did it
change?
A The new Solaris 10 model is called
the Service Management Framework (SMF). The Service Manager controls
stopping, starting, and restarting services on the fly and can identify
dependencies on other services so that things always start in the
right order. Each service is controlled by an XML configuration
file, called a manifest. These manifests are stored in a repository
and can be viewed and modified by the repository daemon, svc.configd(1M).
The repository is read by the master restarter daemon, svc.startd(1M),
which evaluates dependencies and initiates the services as needed.
Traditional inetd services are now part of the service manager
as well. Any of the inetd services can be enabled, disabled,
or restarted via the same mechanism as any other service manager-enabled
program.
If you want to see all of the services controlled by the service
manager, run the command svcs -a. The command svcadm
will allow you to, among other things, enable and disable each service.
You can use the svcs -x command to list all of the services
that are not running and the reason why they are down.
The service manager also allows you to apply batch changes with
the command svccfg. Take a look in /var/svc/profile/
for a file called generic_limited_net.xml for a more restricted
set of services. To apply a different SMF profile than the standard
one, become a user that has Service Management rights and run the
command:
svccfg apply /var/svc/profile/generic_limited_net.xml
If you know what you want and none of the profiles supplied with the
OS meet your needs, you can always create your own and apply it, too.
Take a look at these two sections of the Solaris 10 System Administrator
Collection:
http://docs.sun.com/app/docs/doc/817-1985/6mhm8o5n0?a=view
http://docs.sun.com/app/docs/doc/817-1985/6mhm8o5q9?a=view
Q I just upgraded OpenSSH
from 3.7.1p2 to 3.8, and I'm having problems with X. Some of my applications
now spit out errors like the following:
warning, error event received:
X Error of failed request: BadAtom (invalid Atom parameter)
Major opcode of failed request: 18 (X_ChangeProperty)
Atom id in failed request: 0x1a0
Serial number of failed request: 44
Current serial number in output stream: 46
Clearly I've munged something, but I'm not sure what. Do you have
any suggestions on how to fix things?
A This is actually a FAQ for OpenSSH
3.8. OpenSSH now uses untrusted X11 cookies by default, but some
applications require trusted. You can restore the default behavior
from versions previous to 3.8 by adding the following line to the
system-wide ssh_config file:
ForwardX11Trusted yes
You can also modify your personal ~/.ssh/config file to have
the modification apply to one or more hosts. This example applies
it to all hosts:
Host *
ForwardX11 yes
ForwardX11Trusted yes
If ForwardX11 is not set to on either in the site-wide
ssh_config or in a personal ~/.ssh/config, then the
ForwardX11Trusted setting has no effect at all.
You can instead modify the behavior of ssh on a per-connection
basis by using ssh -Y instead of ssh -X. From the
ssh(1) man page:
-X Enables X11 forwarding. This can also be specified on a per-host
basis in a configuration file.
X11 forwarding should be enabled with caution. Users with the
ability to bypass file permissions on the remote host (for the user's
X authorization database) can access the local X11 display through
the forwarded connection. An attacker may then be able to perform
activities such as keystroke monitoring.
-Y Enables trusted X11 forwarding.
Q I'm using BIND 9.2.3 to serve
DNS info and accept info from a bunch of machines doing DDNS. We
have a large number of clients feeding DDNS requests to the BIND
server, and the journal file is growing quite large. Is there some
way I can tell BIND that the journal file should only grow to a
certain size, say 100M? I don't want to fill up this partition,
and I don't want to have to keep restarting BIND to force it to
roll the journal file. Thanks for any advice you can offer.
A The functionality you desire
is available in BIND 9.3 but not BIND 9.2.x. In BIND 9.3.x you can
set the maximum size of the journal file with the configuration
file option max-journal-size. According to the documentation:
max-journal-size Sets a maximum size for each journal file (Section
4.2.1). When the journal file approaches the specified size, some
of the oldest transactions in the journal will be automatically
removed. The default is unlimited.
So you'd want:
options {
max-journal-size 100M;
};
As a caveat for those early adopters who were running the beta versions
of BIND 9.3.0 up to beta 3, you'll want to remove the existing journal.
Journal compaction could leave it corrupted according to the first
item listed at:
http://www.isc.org/index.pl?/sw/bind/bind9.php
Q We have an old news server
running Highwinds Typhoon that we're looking to decommission. It doesn't
see a lot of use anymore, but we need to make sure that we're not
disabling news on someone important in the company. I've seen a bunch
of programs that will deliver general statistics on the article throughput,
but I need something that lists all of the IPs that are reading news
from the server. Has someone already written a program to do this,
or do I need to roll my own?
A There are a lot of contributed
programs for the Highwinds products located at:
http://www.highwinds-software.com/support/contributed.aspx
The Perl script twbw.pl:
http://www.highwinds-software.com/downloads/contributed/twbw.pl.gz
will do what you need with a little modification. As written, the
script ignores a number of lines where the traffic is considered too
little. You can comment out these sections to get a full accounting
of every IP that contacts your server. Here's a context diff against
the twbw.pl script:
$ diff -c typhoon-by-addr.pl twbw.pl
*** typhoon-by-addr.pl Tue Jan 4 10:58:43 2005
--- twbw.pl Fri Dec 31 00:13:25 2004
***************
*** 80,90 ****
if ($totallines == 1){$logstarttime=$end};
! # if ($line[8] <= 5){
! # $linesignored++;
! # #print "$line \n";
! # next;
! # }
$linesprocessed++;
$feed = $line[2];
--- 76,86 ----
if ($totallines == 1){$logstarttime=$end};
! if ($line[8] <= 5){
! $linesignored++;
! #print "$line \n";
! next;
! }
$linesprocessed++;
$feed = $line[2];
***************
*** 130,135 ****
printf "%-17s %-20s %9.2f %14s
%9.2f\n",$i,$i_feed{$i},$totalmegabytes,$totaltime,$avgbandwidth;
}
print "\n";
! #print "$linesignored lines were ignored due to inactivity\n";
print "$linesprocessed lines were processed\n";
! print "$totallines were in the file\n";
--- 126,131 ----
printf "%-17s %-20s %9.2f %14s
%9.2f\n",$i,$i_feed{$i},$totalmegabytes,$totaltime,$avgbandwidth;
}
print "\n";
! print "$linesignored lines were ignored due to inactivity\n";
print "$linesprocessed lines were processed\n";
! print "$totallines were in the file $file\n";
The script is run with the stats.detailed file as input (e.g.,
substituting the path to your stats.detailed log file):
typhoon-by-addr.pl < /var/log/typhoon/stats.detailed
To get the necessary data, you'll also need to turn on detailed logging
and generate the stats.detailed file by modifying Typhoon's
start.conf file to include the line:
DETAILEDSTATS="-detailedstats"; export DETAILEDSTATS;
Then restart Typhoon for the changes to take effect.
Q I'm running sendmail 8.12.11 on
An HP-UX 11i machine. We recently started experiencing issues with
some of our telecommuters using SMTP-AUTH. I used an outside account
to telnet to port 25 of the mail server, and I issued the EHLO command.
I got back a 502 error code without any explanation:
telnet xxx.xxx.xxx.xxx 25
Trying xxx.xxx.xxx.xxx...
Connected to xxx.xxx.xxx.xxx.
Escape character is '^]'.
220 smtp.my.domain ESMTP (UCE not allowed)
EHLO my.client.address
502
Because this didn't work, I tried a HELO instead, and that seemed
to work fine. Nothing has changed with the sendmail configuration
in months, and the machine has not been rebooted nor has the sendmail
process even been restarted. I'm not sure why things suddenly started
failing and would appreciate any insight you can offer.
A You're probably having several
issues related to ESMTP, not just SMTP-AUTH. This kind of behavior
is seen when there's something filtering the SMTP connection such
as a Cisco PIX, Checkpoint, Raptor, etc. I'd check with the network
department to see whether they've installed some sort of new firewall
in front of your mail server that's doing a proxy connection. The
most popular culprit in this case is the Cisco PIX Mailguard (or
Mailhost, as it was known in earlier releases):
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/ \
products_tech_note09186a00800b2ecb.shtml
You can disable the Mailguard feature in software version 4.2 and
later by issuing the following command while in configure mode on
the PIX:
no fixup protocol smtp 25
Q We have a number of remote
FreeBSD servers that we'd like to power off after shutdown in preparation
for some power work in the data center. I've tried a couple of things,
but I can't seem to get the machines to shut off. Do you have a step-by-step
process I could use?
A I'm going to assume that you're
running FreeBSD on some sort of x86-based architecture. Your machine
must support either APM or ACPI and contain a motherboard (ATX,
not AT) capable of powering off when commanded to by said drivers.
If you have very old PCs, it's possible that they're AT based and
won't work. If your hardware supports power management, and you're
running FreeBSD 4, the easiest route will be to make sure that APM
is enabled. To compile APM support into your kernel, add the following
line to the configuration file (or remove the leading work disable
from in front of the line if you're working off the generic configuration
file):
device apm0 at nexus? disable flags 0x20 # Advanced Power Management
Recompile and install the new kernel, and put the following into /etc/rc.conf:
apm_enable="YES"
apmd_enable="YES"
Once you reboot, you should be able to perform a halt -p to
power off the machine. For more information on apm, see the
apm(4), apm(8), and zzz(8) man pages.
If you're using FreeBSD 5, you may want to opt to use ACPI instead
of APM. ACPI and APM cannot co-exist and should not be used on the
same machine, so you need to pick one or the other. APCI is handled
by a dynamic driver module, acpi.ko, in FreeBSD 5. The module
loads by default, and it's suggested that you don't compile it into
the kernel directly. ACPI configuration is handled by the command
acpiconf (see the acpiconf(8) man page for detailed
information). When ACPI is configured, the machine can be powered
off with either of the following two commands:
halt -p
acpiconf -s 5
If you desire, you can also enable ACPI for FreeBSD 4.9 and above
(remember to disable APM) by adding the following line to the kernel
configuration and rebuilding:
device acpica
Amy Rich has more than a decade of Unix systems administration
experience in various types of environments. Her current roles include
that of Senior Systems Administrator for the University Systems Group
at Tufts University, Unix systems administration consultant, and author.
She can be reached at: qna@oceanwave.com. | 
