 Questions
and Answers
Amy Rich
Q I'm running Solaris 9 on a machine
with one Ethernet card, but a large number of virtual interfaces.
I want to use snoop to view the traffic on one of these virtual
interfaces, but I'm not sure how to do that. The following command
doesn't seem to work:
snoop -d hme0:1
A Snoop is used to view packets on
a physical interface, not logical ones. There is no way to look only
at a virtual interface. If you need to snoop for traffic on this interface
separately from the others, then I suggest adding another physical
network card. If you're looking for a particular kind of traffic,
you can always try limiting the snoop output by using regular expressions.
Q I'm trying to build a stripped-down
Solaris 8 server to act as our gateway. I tried removing the following
NFS packages, since this machine should never mount anything via
NFS:
SUNWnfscr Network File System (NFS) client support (Root)
SUNWnfscu Network File System (NFS) client support (Usr)
SUNWnfscx Network File System (NFS) client support (Root) (64-bit)
SUNWnfssr Network File System (NFS) server support (Root)
SUNWnfssu Network File System (NFS) server support (Usr)
SUNWnfssx Network File System (NFS) server support (Root) (64-bit)
It turns out that SUNWvolu claims to depend on NFS, but I figured
that was just for using automounter, so I removed the NFS packages
anyway. When I rebooted, vold no longer worked, though, so
obviously there's some deeper connection. Why on earth would vold
need NFS to mount things like CDROMs?
A vold treats everything
like an NFS filesystem mounted under /vol. If you look in /etc/mnntab,
you see the following line:
host:vold(pid207) /vol nfs ignore,dev=4540001 1054073390
If vold mounts a CDROM, then you'll see an entry in /etc/mnntab
for /vol/dev/dsk/c0t6d0/<something> as well (assuming your CDROM
drive is at c0t6). The only time NFS is involved is during the actual
mounting procedure. After that, the data is read by the kernel as
HSFS or whatever format exists on your media.
When
building secure machines, I always deinstall vold as well:
SUNWvolg Volume Management Graphical User Interface
SUNWvolr Volume Management, (Root)
SUNWvolu Volume Management, (Usr)
SUNWvolux Volume Management (Usr) (64-bit)
If necessary, you can always explicitly mount the CDROM by hand with
the mount command. Doing the mount by hand doesn't require
NFS at all, so all of the extraneous NFS client and server packages
can be removed.
Q I'm running Solaris 8, and I fear
that I've unknowingly damaged my system. There have been no changes
made recently that I know of, but this machine was shut down and
then rebooted due to some maintenance that was being performed on
our power systems at work. When the machine was turned back on,
it started to boot, and then it displayed this message:
mount:/usr ld.so.1 not found
I booted the machine from the network and then mounted /usr to look
around. ld.so.1 is in fact in /usr/lib, and it looks fine. The checksums
match other machines that are working ok, and the permissions match
as well. Is something else broken, and the error message just misleading?
Have I been hacked and not realized it? I hope you can tell me that
I've somehow managed to break the machine myself (and there's an easy
fix like adding a package back in or something). Help!
A You have the root filesystem
and the /usr filesystem on two different slices, so it wouldn't
be looking at /usr/lib before /usr was mounted. Instead, the machine
is looking in /etc/lib for ld.so.1. If you boot from the net or
CDROM, and look in /etc/lib, you'll probably note that this file
is missing. How that happened, I'm not sure (perhaps you removed
it a while ago and the machine has not been rebooted since?). /etc/lib/ld.so.1
is part of SUNWcsr, as are /etc/lib/libdl.so.1 and /etc/lib/nss_files.so.1.
You may want to run pkgchk to see whether there are any other issues
with SUNWcsr if you think you may have somehow damaged part of the
package:
pkgchk SUNWcsr
The quick and dirty fix to get the machine up and running again is
to copy /usr/lib/ld.so.1 over to /etc/lib.
Q I'm running Solaris 8 on an E450.
We have a generic account that should not be able to log in, run
cron jobs, etc. My understanding of the /etc/shadow file is that
an entry with *NP* cannot log in but can still run cron jobs. An
entry with *LK* should not be able to do either. I've modified the
password entry to have *LK* in the password field, but the user
can still run cron jobs. Is my understanding flawed, or did I set
something up wrong or forget a step?
A Your understanding is mostly
correct, with one exception. An /etc/shadow entry with *NP* can
actually log in if a password is not required ‡ la ssh authorized_keys,
.rhosts, etc. The issue of your locked user still being able to
run cron jobs was actually a bug that was recently fixed, though.
Ironically, because of the fix, various people have filed bug reports
with Sunsolve saying that what was previously functioning has mysteriously
stopped working. A couple reports state that the "fix" happened
in 108993-18, so I'd try installing the latest 108993 patch and
see if that helps.
Q This is sort of an odd request,
but is necessitated by some testing that our development group would
like to do. We're running Solaris 8 on a number of different UltraSPARC
machines. We need make time appear to go faster or slower on these
machines depending on the test. We don't need to muck with the hardware
clock, just have the time/date change according to the rate we want.
With all of the Y2K testing that had to happen several years ago,
I presume someone must have come up with a product that does this.
It would be great if you could point me at such a beast.
A If you're only concerned with
the time and date as reported by the OS, then you need look no farther
than your base Solaris install. The /usr/bin/date command takes
an optional flag of -a to skew the system clock one way or another.
From the man page:
-a [-]sss.fff Slowly adjust the time by sss.fff seconds (fff represents
fractions of a second). This adjustment can be positive or negative.
The system's clock will be sped up or slowed down until it has drifted
by the number of seconds specified. Only the superuser may adjust
the time.
Q We're running Solaris 9 with a
bunch of third party software installed. Unfortunately, this means
we have overlapping man pages in /usr/share and /usr/local. Our
standard system path has /usr/local before /usr/bin, for example,
so most of the time people want the corresponding man pages in /usr/local.
Occasionally, especially when writing shell scripts and explicitly
using binaries in /usr/bin, people will want the man page for the
stock Solaris command.
A
good example is the df command. Because the MANPATH has /usr/local/man
before /usr/share/man, people who run man df always get the
FSF man page. Just calling nroff with the path of the system man
page doesn't work because Sun no longer does their man pages in
roff format. How can people access the man page for the stock Sun
df command instead of the FSF one?
A In the case of df, you
can actually use the section to differentiate it from the GNU df.
For /usr/bin/df it would be:
man -s 1m df
For /usr/ucb/df, it would be:
man -s 1b df
For GNU's df, it would be:
man -s 1 df
There are some cases where the third party man pages and the Sun
man pages will have the same section designation, though. In that
case, you can specify the path you'd like to use on the command
line:
man -M /usr/share/man df
Q We've finally upgraded to the latest
and greatest OpenSSH (3.6.1p2) on our internal Solaris 8 machines.
I can't seem to get password aging to work with the new version, and
this is a big problem for us. Is there something new that needs to
be configured in sshd_config or ssh_config that I've just overlooked?
(I'm using the stock installed ones on the test machine.)
A Password aging on Solaris 8 is
actually broken with 3.6.1. See the bug report at:
http://bugzilla.mindrot.org/show_bug.cgi?id=14
There is a third party patch you can apply to 3.6.1p2 to get it working
again, though:
http://www.zip.com.au/~dtucker/openssh/
Q I've been trying to set up sendmail
8.12.9 to forward all "unknown" mail to another host. I've read through
the sendmail documentation, and I think I have everything right in
my mc file, but when I try to send mail to a nonexistent user, I get
user unknown error instead of having the mail forwarded onto the other
machine. Here's my mc file:
divert(0)dnl
OSTYPE(solaris2)dnl
FEATURE('nouucp','reject')dnl
FEATURE('redirect')dnl
FEATURE('use_cw_file')dnl
FEATURE('local_procmail')dnl
FEATURE('stickyhost')dnl
FEATURE('always_add_domain')dnl
FEATURE('access_db')dnl
LOCAL_USER('root')dnl
EXPOSED_USER('root')dnl
#
define('LUSER_RELAY','machine.other.domain')dnl
define('confSAFE_QUEUE', 'true')
define('confPRIVACY_FLAGS', ''authwarnings,noexpn,novrfy'')dnl
define('confTO_IDENT', '0s')dnl
define('confSMTP_LOGIN_MSG', '$j (NO UCE)')dnl
MAILER(local)dnl
MAILER(smtp)dnl
A It took some digging for me to find
information on this particular issue, but I believe that your problem
is the stickyhost feature. According to the README, stickyhost is
really meant to be used in conjunction with the LOCAL_RELAY and MAIL_HUB
directives. Here's the actual text:
stickyhost This feature is sometimes used with LOCAL_RELAY, although
it can be used for a different effect with MAIL_HUB.
When used without MAIL_HUB, email sent to "user@local.host" are
marked as "sticky" -- that is, the local addresses aren't matched
against UDB, don't go through ruleset 5, and are not forwarded to
the LOCAL_RELAY (if defined).
With MAIL_HUB, mail addressed to "user@local.host" is forwarded
to the mail hub, with the envelope address still remaining "user@local.host".
Without stickyhost, the envelope would be changed to "user@mail_hub",
in order to protect against mailing loops.
Since you're not using MAIL_HUB, ruleset 5 never gets called,
and that's where the LUSER_RELAY rules are (see the bottom two lines
here):
######################################################################
### Ruleset 5 -- special rewriting after aliases have been expanded ###
######################################################################
SLocal_localaddr
Slocaladdr=5
R$+ $: $1 $| $>"Local_localaddr" $1
R$+ $| $#ok $@ $1 no change
R$+ $| $#$* $#$2
R$+ $| $* $: $1
# deal with plussed users so aliases work nicely
R$+ + * $#local $@ $&h $: $1
R$+ + $* $#local $@ + $2 $: $1 + *
# prepend an empty "forward host" on the front
R$+ $: <> $1
# send unrecognized local users to a relay host
R< > $+ $: < $L > $(user $1 $) look up user
R< $* > $+ <> $: < > $2 found; strip $L
If you remove the stickyhost directive and regenerate your cf file,
your LUSER_RELAY directive should work.
Q I'm using the gcc-3.3 package
from sunfreeware.com to bootstrap my own gcc-3.3 compiler on a Solaris
9 machine. The configure goes ok, and part of the build goes ok,
but then it bombs out with the following errors:
(cd .libs && rm -f libstdc++.la && ln -s ../libstdc++.la libstdc++.la)
Making all in po
Making all in testsuite
mksh: Fatal error in reader: = missing from replacement macro reference
Current working directory /usr/local/src/gcc-3.3/sparc-sun-solaris2.9/ \
sparcv9/libstdc++-v3/testsuite
*** Error code 1
make: Fatal error: Command failed for target 'all-recursive'
Current working directory /usr/local/src/gcc-3.3/sparc-sun-solaris2.9/ \
sparcv9/libstdc++-v3
*** Error code 1
make: Fatal error: Command failed for target 'all-recursive-am'
Current working directory /usr/local/src/gcc-3.3/sparc-sun-solaris2.9/ \
sparcv9/libstdc++-v3
*** Error code 1
make: Fatal error: Command failed for target 'multi-do'
Current working directory /usr/local/src/gcc-3.3/sparc-sun-solaris2.9/ \
libstdc++-v3
*** Error code 1
make: Fatal error: Command failed for target 'all-multi'
Current working directory /usr/local/src/gcc-3.3/sparc-sun-solaris2.9/ \
libstdc++-v3
*** Error code 1
make: Fatal error: Command failed for target 'all-recursive-am'
Current working directory /usr/local/src/gcc-3.3/sparc-sun-solaris2.9/ \
libstdc++-v3
*** Error code 1
make: Fatal error: Command failed for target 'all-target-libstdc++-v3'
Current working directory /usr/local/src/gcc-3.3
*** Error code 1
make: Fatal error: Command failed for target 'bootstrap'
I'm not sure what mksh is, or what replacement macro reference it's
talking about. Obviously, someone has gotten the compile to work because
there's a package already, but I can't seem to work around this issue.
Do you have any suggestions?
A You get this error when you're
trying to compile some of the extra languages that come with gcc
but you aren't using GNU make. You can either specify that you only
want C, or you can install GNU make (or put it first in your path)
and reconfigure gcc. I would suggest the latter, since various other
pieces of software will also want GNU make.
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.
| 
