Questions
and Answers
Amy Rich
Q I'm trying to compile aspell 0.60.2
on a Solaris 8 machine with gcc 2.95.3. The configure and build
processes seem to go fine until this line:
g++ -shared -nostdlib <lots of object files> -ldl \
-L/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3 \
-L/usr/ccs/lib -L/usr/local/lib -lstdc++ -lm -lgcc \
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/crtend.o \
/usr/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/crtn.o \
-Wl,-h -Wl,libaspell.so.15 -o .libs/libaspell.so.15.1.2
When the operation tries to link here, it spits out pages and pages
of errors that look similar to the following:
Text relocation remains referenced
against symbol offset in file
<unknown> 0xac8 /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/ \
2.95.3/libstdc++.a(iovfscanf.o)
<unknown> 0x584 /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/ \
2.95.3/libstdc++.a(outfloat.o)
<unknown> 0x1bc4 /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/ \
2.95.3/libstdc++.a(floatconv.o)
__udiv64 0x1044 /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/ \
2.95.3/libstdc++.a(iostream.o)
Presumably I'm missing a library directory or something like that.
The error output doesn't even list the symbol it's missing in the
first few pages (although it does for later ones), so I'm not certain
how I should track each of them down. Any hints on where I should
start?
A Your problem is that your libstdc++
was not built as a shared library. Whenever you try to compile something
shared, it will fail quite verbosely. The best answer is to rebuild
gcc/libstdc++ with shared library support. For aspell in particular,
though, you can disable building shared libraries by running configure
with the switch:
--disable-shared
This will create a statically linked libaspell (libaspell.a) instead
of a dynamic library (libaspell.so).
Q Our internal network is firewalled
from the rest of the world and is sitting in an RFC 1918 address
space. From the outside, we need to connect to the firewall host
and then connect to internal machines. Our firewall host is running
FreeBSD 4.10, and our internal machines run a mix of Unix variants.
On each of these machines, we've installed screen 4.00.02 so that
we don't lose a session if the external ssh connection fails. My
problem with this is that I ssh to the bastion host and run screen,
and then I ssh to multiple internal machines and also run screen.
This seems not to work because one screen session takes over the
previous ones. Is there a way around this, or can I not use screen
in this way?
A The cleanest solution, and the
easiest one to keep track of, is to run one screen session on the
bastion host and then run multiple ssh connections to the other
internal hosts from there. Your internal network should be reliable
enough that your ssh sessions will not drop, and you won't have
to remember which screen session you're currently in.
If you really want to have a screen session on the bastion host
controlling screen sessions on other machines, you can work around
the command character issue in two ways. Screen has a built-in method
of allowing you to send the command character to the window instead
of to the window manager screen itself. From the screen man page:
C-a a (meta) Send the command character (C-a) to window.
See escape command.
So you could switch between client screen sessions by sending C-a
a to the screen session on the bastion host.
The second method is to use a different command key on the bastion
host than on the client hosts. The previous reference to the escape
command can define this new key:
escape xy
Set the command character to x and the character generating a
literal command character (by triggering the "meta" command) to
y (similar to the -e option). Each argument is either a single character,
a two-character sequence of the form "^x" (meaning "C-x"), a backslash
followed by an octal number (specifying the ASCII code of the character),
or a backslash followed by a second character, such as "\^" or "\\".
The default is "^Aa".
So on each client, you would use the default command key sequence
of C-a and, on the bastion host, you could set the command
key to something like the back quote key:
escape "''"
To switch between clients on the bastion host, you would use 'n
and 'p, and to switch between windows on each client, you would
use C-an and C-ap.
If you're doing multi-user screen sessions, then you'll want to
use the defescape command:
defescape xy
Set the default command characters. This is equivalent to the
"escape" except that it is useful multi-user sessions only. In a
multi-user session "escape" changes the command character of the
calling user, where "defescape" changes the default command characters
for users that will be added later.
Q I've taken the plunge and upgraded
sendmail on my Solaris 9 machine from 8.12.11 to 8.13.3. I kept
the same mc files and the same site.config.m4 from the 8.12.11 install
so that things would be pretty much the same. The build and the
install went fine, and all of the permissions look fine. When I
try to start sendmail, however, it complains with the following
error:
Mar 14 13:42:21 smtp.my.domain sendmail[417]: unable to write pid to
/var/run/sendmail.pid: file in use by another process
It seems that sendmail creates the PID file anyway, though, because
it does exist and has been recently modified:
-rw------- 1 root smmsp 42 Mar 14 13:42:20 /var/run/sendmail.pid
So why is sendmail complaining when it's clearly succeeding?
A Starting with sendmail 8.13.0,
sendmail locks the PID file so that other processes do not overwrite
it. If you take a look at the RELEASE_NOTES file that came with
your distribution, you'll see the following:
8.13.0/8.13.0 2004/06/20
Keep daemon pid file(s) locked so other daemons don't try to
overwrite each other's pid files.
You've managed to start up more than one sendmail daemon, so the second
one is complaining that it can't create its lock file. If you're using
different configuration files for each daemon, you can set the PID
file name via m4 in each file with the following statement:
define('confPID_FILE','/var/run/sendmail-1.pid')
In the second mc file, you'll obviously need to pick a different PID
file name, like sendmail-2.pid.
If you're using the same sendmail.cf file for both instances,
then you can specify the PID file name on the command line with:
-OPidFile=/var/run/sendmail-1.pid
If you're running multiple daemons on different ports or in different
modes, you might want to create PID file names that include the port
number or mode (for example, sendmail-25.pid and sendmail-2525.pid
for ports 25 and 2525, or sendmail-d.pid and sendmail-q.pid for a
listening daemon and a queue runner).
Q We're going to be running a lot
of cat 5 cable in the near future, and I would like to find some
place that will distinctively label the cables for us so we don't
have to do it ourselves. Are there places that offer this kind of
service?
A You can buy pre-labeled cables
straight from various cable vendors. Take a look at:
http://lanshack.com/patch-cables.asp
under the "Custom label" option (none, one, or two cable ends marked).
If you visit:
http://www.cxtec.com/cables/labeling.php
you can even obtain a free sample of labeled cables before you decide
to buy.
Q Since Solaris 10 has finally hit
FCS, I've downloaded a copy and installed it on a test machine.
So far I'm really impressed by what I've seen. I've been compiling
a bunch of software on the machine, and I've run into an issue compiling
OpenSSH. I know that Sun ships a version of ssh with Solaris, but
I want to stick with OpenSSH because I'm running it on a number
of platforms and I want the same version on all machines. I've configured
OpenSSH with the following options:
./configure --prefix=/usr/local --localstatedir=/var \
--with-xauth=/usr/openwin/bin/xauth --with-tcp-wrappers \
--with-ssl-dir=/usr/local/ssl --with-random=/dev/random \
--with-default-path="/bin:/usr/bin:/usr/ucb:/usr/local/bin:/ \
sbin:/usr/sbin:/usr/local/sbin:/usr/X/bin:/usr/openwin/bin"
Everything compiles and installs fine, but when I start up ssh, I
get the following output:
Starting the ssh daemon
PRNG is not seeded
I'm using Sun's random devices, so why wouldn't there be enough entropy?
I can compile and start using the internal random stuff for OpenSSH,
but that's not very secure.
A I've seen several reports of
this problem, and it has to do with OpenSSL, not OpenSSH. You seem
to be using OpenSSL because you specify the path to SSL as /usr/local/ssl
and not the system default libraries. The /dev/*random devices are
actually symlinks under Solaris. This wasn't a problem before Solaris
10, but Solaris 10 sets O_NOFOLLOW, which causes the OpenSSL entropy
seeding to fail. Until the fix makes it into a distribution of OpenSSL,
you can work around this by specifying the actual device name pointed
at by /dev/random, /devices/pseudo/random@0:random.
Q I'm trying to set up my environment
to use CPAN to download/install Perl modules. I run the following
command for the first time, and it sends me through the initial
setup:
perl -MCPAN -e shell
I keep the defaults that are given to me when going through the setup:
CPAN build and cache directory? [/home/arr/.cpan]
Cache size for build directory (in MB)? [10]
Perform cache scanning (atstart or never)? [atstart]
Cache metadata (yes/no)? [yes]
Your terminal expects ISO-8859-1 (yes/no)? [yes]
Policy on building prerequisites (follow, ask or ignore)? [ask]
Where is your gzip program? [/usr/local/bin/gzip]
Where is your tar program? [/usr/local/bin/tar]
Where is your unzip program? [/usr/bin/unzip]
Where is your make program? [/usr/local/bin/make]
Warning: lynx not found in PATH
Where is your lynx program? []
Where is your wget program? [/usr/local/bin/wget]
Where is your ncftpget program? []
Where is your ftp program? [/usr/bin/ftp]
What is your favorite pager program? [/usr/local/bin/less]
What is your favorite shell? [/bin/tcsh]
Your choice: []
Your choice: []
Your choice: []
Timeout for inactivity during Makefile.PL? [0]
Your ftp_proxy?
Your http_proxy?
Your no_proxy?
It then tries to grab the MIRRORED.BY file:
You have no /home/arr/.cpan/sources/MIRRORED.BY
I'm trying to fetch one
LWP not available
CPAN: Net::FTP loaded ok
Fetching with Net::FTP:
ftp://ftp.perl.org/pub/CPAN/MIRRORED.BY
Couldn't fetch MIRRORED.BY from ftp.perl.org
Fetching with Net::FTP
ftp://ftp.perl.org/pub/CPAN/MIRRORED.BY.gz
Couldn't fetch MIRRORED.BY.gz from ftp.perl.org
Every time it tries to fetch the file, it times out. If I try to ftp
the file manually, I can log into the site and do an ls, but
if I try to transfer any data, it times out. Is there some other setting
I can use to get CPAN working correctly? Something I should have chosen
differently in the manual configuration?
A It sounds like you're using ftp
behind some sort of firewall that's not allowing you to pass all
of the packets. The way around this is to use passive mode ftp.
Assuming your ftp supports it, you can set this in your .cshrc or
.tcshrc by specifying the following environment variable:
setenv FTP_PASSIVE 1
You can also do this from the command line if you only want it to
last for that specific shell session. If you try to connect to CPAN
after doing this, you should be able to finish your configuration.
Another option is to use a tool such as ncftp, which will do passive
ftp automatically.
Q I have a Solaris 8 machine with
the latest Recommended patch set on it. I'm trying to set up Disk
Suite to mirror the boot drive. I've done this a bunch of times
before in various environments, but this time I'm having trouble.
I've set up / and swap successfully, and I'm trying to set up the
third slice as a data partition. These all work fine:
metainit -f d101 1 1 c0t0d0s0
metainit -f d102 1 1 c0t1d0s0
metainit -f d111 1 1 c0t0d0s0
metainit -f d112 1 1 c0t1d0s0
Then I attempt to set up one half of the data partition mirror by
issuing the same metainit command, and I receive an error:
metainit -f d131 1 1 c0t0d0s3
metainit: host.my.domain: d131: No such file or directory
The partition does exist, and I even have it mounted currently:
Filesystem Size Used Avail Use% Mounted on
/dev/dsk/c0t0d0s3 67G 300M 66G 1% /data
So why is it having an issue finding the disk in just this instance?
A Disk Suite isn't having an issue
finding your disk; it can't find the metadevice. By default, Disk
Suite is configured to have 128 metadevices. Your naming scheme
requires that you have a metadevice named d131 (and presumably d132,
too, if your other metadevices are any indication). To go above
the default of 128 metadevices, you need to edit /kernel/drv/md.conf
and change nmd=128 to a higher number (up to 1024). After making
the change to the device configuration file, reboot the machine
with the -r flag to reconfigure the devices. You can also
configure the number of disksets in this file by tuning the md_nsets
variable. The maximum number of disksets is 32.
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. |