Questions
and Answers
Amy Rich
Q Our mail hub is a FreeBSD 4.5-STABLE
box running Postfix. We were recently the target of a large-scale
spam attack. There are still a lot of undeliverable bogus messages
sitting in the queue (no valid user, and no valid bounce address).
I want to remove all of these bogus files, but I'm not certain
whether I can actually just rm the files while the mail server
is running, or whether I must shut it down and remove the spooled
messages with some other program. Any clues?
A Recent versions of Postfix include
an option to the postsuper command to clean out queued messages
by queue ID. To delete a message with a queue ID of ABCDEF, for
example, you would do:
postsuper -d ABCDEF
If you have a large number of messages to remove, create a file with
one queue ID per line and then run:
postsuper -d - < file
This is usually safe to do while Postfix is running, but there is
a small chance of deleting new incoming mail if it's assigned
the same queue ID before the bad message is deleted. From the Postfix
FAQ at:
http://www.postfix.org/faq.html#deleting)
The [possible conflict in message removal] scenario goes like this:
- The Postfix queue manager deletes the file that postsuper was
supposed to delete, because Postfix was finished with the message.
- New mail arrives, and the new message is given the same queue
ID as the message that postsuper was supposed to delete. The probability
for reusing a deleted queue ID is about 1 in 2^15 (the number
of different microsecond values that the system clock can distinguish).
- postsuper deletes the new message file, instead of the old
file that should have been deleted.
Q I'm having some issues with Jumpstart
on Solaris 8. I have a U2 acting as my Jumpstart server, and I've
been churning out machines just fine. I tried to do an overhaul of
a number of my packages, and now I can't get any of my machines
to jumpstart properly, even if I remove the scripts that add the packages.
Now when I try to do a jumpstart, it reads the initial profile and
creates the base OS image. When it reboots to start the next phase,
however, it claims that the hostname I've given the machine is
invalid. This same hostname worked just fine in the initial phase
of the jumpstart. I've stopped the Jumpstart process and looked
at /etc/hosts. Sure enough, even though /etc/hostname.hme0
has the correct hostname, there's no corresponding IP/hostname
information in /etc/hosts. All /etc/hosts has is a 127.0.0.1
entry for localhost. What did I do that broke my Jumpstart?
A It sounds as if you've corrupted
your Jumpstart boot image. When you were redoing your packages,
did you happen to export your Jumpstart boot image read write and
then try to jump your machine? If so, you probably overwrote files
in the boot image that used to be symbolic links to /tmp
during the boot process. To be absolutely sure that you correct
all of the corrupted parts of the image, you should recreate your
boot image from an original ISO image with the setup_install_server
script. If you want to just try to repair your image, the following
files in $CDROM_DIR/Solaris_8/Tools/Boot/ should be symbolic
links instead of real files:
etc/default/init -> ../../tmp/root/etc/default/init
etc/defaultdomain -> ../tmp/root/etc/defaultdomain
etc/defaultrouter -> ../tmp/root/etc/defaultrouter
etc/device.tab -> ../tmp/root/etc/device.tab
etc/dgroup.tab -> ../tmp/root/etc/dgroup.tab
etc/format.dat -> ../tmp/root/etc/format.dat
etc/inet/hosts -> ../../tmp/root/etc/inet/hosts
etc/inet/netmasks -> ../../tmp/root/etc/inet/netmasks
etc/instance -> ../tmp/root/etc/instance
etc/krb5/krb5.conf -> ../../tmp/root/etc/krb5/krb5.conf
etc/net/ticlts/hosts -> ../../../tmp/root/etc/net/ticlts/hosts
etc/net/ticots/hosts -> ../../../tmp/root/etc/net/ticots/hosts
etc/net/ticotsord/hosts -> ../../../tmp/root/etc/net/ticotsord/hosts
etc/nodename -> ../tmp/root/etc/nodename
etc/nsswitch.conf -> ../tmp/root/etc/nsswitch.conf
etc/ps_data -> ../tmp/root/etc/ps_data
etc/resolv.conf -> ../tmp/root/etc/resolv.conf
etc/sysidcfg -> ../tmp/root/etc/sysidcfg
etc/transfer_list -> ../tmp/root/etc/transfer_list
etc/vfstab -> ../tmp/root/etc/vfstab
etc/.mnt.lock -> ../tmp/root/etc/.mnt.lock
etc/.name_service_door -> ../tmp/root/etc/.name_service_door
etc/.sysIDtool.state -> ../tmp/root/etc/.sysIDtool.state
var -> ./tmp/root/var/
.tmp_proto/kernel -> ../tmp/root/kernel
Also be sure that etc/path_to_inst contains only the following:
#path_to_inst_bootstrap_1
Your Jumpstart may have also created some other extraneous files that
you should delete. Use find to locate all of the files that
were modified on the date that you tried your last unsuccessful jumpstart.
Before you try another jumpstart, be certain that your image is shared
read-only, or you'll corrupt the boot image again.
Q I was trying to compile OpenSSH
on my OpenBSD machine, but I keep getting the following error:
- -L. -Lopenbsd-compat/ -L/usr/local/lib -R/usr/local/lib -lssh -lopenbsd-compat -lz -lsocket -lnsl -lcrypto
Undefined first referenced
symbol in file
__inet_ntoa ./libssh.a(channels.o)
__inet_ntop sshconnect.o
ld: fatal: Symbol referencing errors. No output written to ssh
collect2: ld returned 1 exit status
*** Error code 1
I tried manually adding in -lresolv, since it seems like it's
missing some resolver functions:
gcc -o ssh ssh.o sshconnect.o sshconnect1.o sshconnect2.o sshtty.o
readconf.o clientloop.o -L. -Lopenbsd-compat/ -L/usr/local/lib \
-R/usr/local/lib -lssh -l openbsd-compat -lz -lsocket -lnsl \
-lcrypto -lresolv
Undefined first referenced
symbol in file
__inet_ntoa ./libssh.a(channels.o)
__inet_ntop sshconnect.o
ld: fatal: Symbol referencing errors. No output written to ssh
collect2: ld returned 1 exit status
*** Error code 1
Any clues why it can't find the resolver functions?
A This looks like you have installed
your own version of bind, and gcc is picking up the "new"
include files first. Try compiling with -lbind, if you have
a /usr/local/lib/libbind.a, or try fixing your bind installation
so that gcc does not pick up the conflicting include files first.
Q We have a Graphite series Apple
Airport that handles the 802.11b bridging at work. The clients are
two FreeBSD 4.5-STABLE laptops with Lucent gold cards. The Airport
was also upgraded to a gold card, so we could do 128-bit WEP, when
it was purchased (before it was discovered that WEP was broken).
We recently moved offices and reinstalled the two laptops. Now,
with no discernible pattern, we're seeing very odd behavior
on our wireless LAN. Everything will be working just fine, and then
the laptops will be unable to talk to anything, including each other
and the Airport. The LEDs on the laptop Lucent cards look normal,
though, and the lights on the Airport also look normal. The wired
LAN can still talk to the Airport when this happens. If we put the
laptops into ad hoc mode, they can talk just fine, but they obviously
can't talk with the wired network at that point. This also
breaks DHCP, which is used to feed the laptops much of their network
configuration information, including the IP.
We aren't sure if we accidentally did something to the Airport,
the laptop configuration, or what. Any insight you have would be
appreciated.
your airport's ethernet address
LANNetworkName
plaintext WEP key
airport.host.name
A Since you made several changes
at once, that's going to make it harder to track down the issue:
- Because the wired side can still talk to the airport, I would
guess it's not a physical wiring issue in your new building.
If you haven't already done so, you may want to test all
of the wires, anyway, for future sanity.
- Since the laptops can talk to each other in ad hoc mode, it's
probably not the gold card in either laptop. It's also unlikely
that it's your laptop configuration, since it works some
of the time. Just in case, however, I'll go over what should
be in your config files.
- It's unlikely that it's the Airport configuration,
since, again, you said it works some of the time. You can redo
the Airport configuration to be sure, and you may also want to
reset the Airport and upgrade the firmware while you're at
it.
- The wireless card in your Airport could be failing. The best
way to test this is to swap cards with a known working card, perhaps
from one of the laptops.
- Your Airport could be failing. There are known hardware issues
with certain serial number ranges of Graphite Airports.
Laptop configuration:
The laptop configuration is fairly simple. It can be completely
done in /etc/pccard.conf, or you can split it into /etc/pccard.conf
and /etc/dhclient-exit-hooks. I prefer the latter solution,
because it allows you to move between multiple networks without
having to manually reset your configuration. /etc/pccard.conf
should have the following entry:
# Lucent WaveLAN/IEEE
card "Lucent Technologies" "WaveLAN/IEEE"
config 0x1 "wi0" ?
insert logger -t pccard:$device -s WaveLAN/IEEE inserted
insert /etc/pccard_ether $device
remove logger -t pccard:$device -s WaveLAN/IEEE removed
remove /sbin/ifconfig $device delete
/etc/dhclient-exit-hooks is the file that will contain all
of the customizations such as your WEP key, power save mode, etc.
If you keep a WEP key in this file, it should only be readable by
root. Here's an example /etc/dhclient-exit-hooks file;
replace the following with the proper values for your site:
your airport's ethernet address
LANNetworkName
plaintext WEP key
airport.host.name
#!/bin/sh -x
# Read the BSS ID and network name
get_wireless_bss()
{
bssid=cmd | awk '$1 == "Current" && $2 == "BSSID:" { print $4 }'
bssnet=cmd | awk '$1 == "Current" && $2 == "netname" { print $5 }'}
# Try to identify and configure for the wireless net
find_wireless_net()
{
if [ "$bssid" = "your airport's ethernet address" ]
then
# On the work LAN
$cmd -e 1
$cmd -n LANNetworkName
$cmd -k 'plaintext WEP key'
elif [ "$bssnet" = "LANNetworkName" ]
then
# On the work LAN
$cmd -e 1
$cmd -n LANNetworkName
$cmd -k 'plaintext WEP key'
else
# unknown net, turn off encryption
$cmd -e 0
$cmd -n ''
fi
}
# Initialize the WaveLAN card with the proper parameters
if [ "$interface" = "wi0" -a "$reason" = "PREINIT" ]
then
cmd="/usr/sbin/wicontrol -i $interface"
$cmd -P 0 # turn off powersave mode for better throughput
$cmd -s airport.host.name
get_wireless_bss
if [ "$bssid" = "44:44:44:44:44:44" ]
then
# Unknown, try known networks
$cmd -e 1
for net in LANNetworkName
do
$cmd -n $net
sleep 1
get_wireless_bss
if [ "$bssid" != "44:44:44:44:44:44" ]
then
break
fi
done
fi
find_wireless_net
fi
exit 0
When you insert the card, it should connect to the network, and you
should be able to see the current settings by executing the following
command as root:
/usr/sbin/wicontrol -i wi0
If you're having issues making a connection at this point, you
can use the LEDs to help diagnose the problem. Look at table B-1 in
Appendix B of ftp://orinocowireless.com/pub/docs/ORINOCO/MANUALS/ug_pc.pdf
or the user manual that came with your gold card. If your LEDs are
both blinking once every 10 seconds, it means that the card in your
laptop is ok, but that it can't establish a connection with the
base station.
Airport configuration:
You can configure the Airport from pretty much any kind of machine
these days. If you're using a 128-bit WEP key, though, be sure
that you find software that supports it. I know people who've
had good luck with Windows clients using Freebase (http://freebase.sourceforge.net/)
and some who have used the Java-based configurator v1.5 on UNIX
hosts (http://edge.mcs.drexel.edu/GICL/people/sevy/airport/).
If you have a tool that will let you upload new firmware, you
may also want to completely reset the Airport (hold in the reset
switch within a few seconds of turning on the Airport. The right
light should flash amber when the Airport has been reset). Prior
to 1.3, Apple's Airport firmware was supplied as a standalone
file as part of a software download bundled into a smi archive file.
However, with the 1.3 release, the firmware is now embedded within
the base station admin utility. It's possible to extract the
firmware image using ResEdit, or you can grab a copy from firmware
(http://www.icir.org/fenner/airport/).
Airport failure:
There is a recall on Apple Airport base stations with the serial
number range PW940... to PW952... These Airports had a tendency
to blow their capacitors, resulting in the constant reset of the
station. I've also seen the stations fail slowly with the symptoms
you describe. Perhaps your Airport received a power surge that damaged
one or more of the capacitors. Take a look at http://www.vonwentzel.net/ABS/Repair.html
for a list of symptoms, hardware fixes, and information on the recall
from Apple.
Q I'm starting to enter the
world of writing GUI Perl applications. Are there any good Perl/GUI
application development tools out there, preferably something where
I can do drag and drop programming?
A Most GUI applications that you're
going to write in Perl will probably be integrated with Tk. Take
a look at O'Reilly's Mastering Perl/Tk book:
http://www.oreilly.com/catalog/mastperltk/
the Perl/Tk Web site:
http://www.perltk.org/
and the Perl/Tk FAQ:
http://w4.lns.cornell.edu/~pvhp/ptk/ptkFAQ.html
The User interface section on http://www.perl.com may also
be of some use if you're looking to integrate with something
other than Tk:
http://www.perl.com/cs/user/query/q/6?id_topic=75
If you're specifically looking for drag and drop GUI Perl/Tk
code builders, take a look at Guido, an open source tool that does
drag and drop Perl/Tk development:
http://guido.sourceforge.net/
Spectcl and related projects may also be worth looking at:
http://spectcl.sourceforge.net/
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.
|