On Saturday 13 December 2003 17:25, Jack L. Stone wrote:
> Dear list:
> I manage a remote gateway/nat/router/fw server where it is not convenient
> for anyone to go downtown to the colo and do reboots.
>
> I've managed to do everything here remotely from my own console, including
> reboots when updating the OS requires it -- that is except when
> reconfiguring the natd.conf file to add another forwarding service. I can
> reboot and it comes up okay, but rather would avoid a reboot. BUT, if I try
> to kill/restart the natd daemon remotely, it kills my SSH session -- no
> restart of NATD -- cannot log back in and that means a 30-min trip for
> someone to the colo. That gets old and rather just reboot which is a lot
> less inconvenient.
>
> Obviously, when I do the kill of natd, it disconnects my SSH session and I
> can't restart the daemon so it can reread the natd.conf file for my
> changes.
>
> I've tried a background script, but that hasn't worked either. Perhaps a
> second session would stay alive.... either SSH or even a telnet session
> just for the duration for this event??? Or a better background script...??
The simple answer is : "a better background script" :)
I manage a bunch of remote machines and sometimes have to fool around with
NATD remotely. When I do this, I make a cron entry that starts
/root/ipfw-rescue .
In there there's something like :
/sbin/natd -f flush
/sbin/natd 10000 divert natd all from any to any via xl0
/sbin/natd 50000 pass all from any to any
killall -KILL natd
/sbin/natd -n xl0
This way the machine will always recover from ipfw or natd tests within 10
minutes.
When loading firewall rules remotely, I direct the output of ipfw to /dev/null
to be sure ipfw loads the entire rule set.
If for example you have a rc.firewall file like this :
${fwcmd} -f flush
${fwcmd} add blah blah
${fwcmd} add blah blah2
${fwcmd} add 5000 pass all from any to any
And you start it over SSH with :
sh /etc/rc.firewall
You will get locked out because ipfw prints every rule it adds. So after "ipfw
-f flush" it will print "ruleset flushed", but packets aren't allowed to
travel outside over the SSH connection (since the ruleset is empty) so
execution of rc.firewall stops there... :(
Loading the ruleset like this does work :
sh /etc/rc.firewall >/dev/null 2>/dev/null
(Direct both stdout and stderr to /dev/null)
Alternatively you could direct the output to a log-file so you can verify if
anything went wrong. (And don't forget to remove the cron-entry when you're
done)
Hope this helps,
Daan
_______________________________________________
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
