Re: server rebooted
[EMAIL PROTECTED] wrote: Hello. I have a dedicated server the one was up for more than 84 days but this Friday 19, suddenly the server was rebooted. this is the output of the "last" command # last | grep reboot reboot ~ vie 19 sep 13:55 I already have check the logs but i can't found any hint that could help me to know why the server as was rebooted. Any idea on what to check or how to know what makes the server to reboot? thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]" Check all the logs, not only the lastlog. Start with /var/log/messages, and continue there. See behaviour of all the installed daemons and what did they log. If the kernel is not debug-enabled, there are chances you won't find out certain crashes. A power-off problem will be noticed because of disrupted timestamps in the logs, and no shutting down messages from the daemons and the kernel. And if you don't CAREFULLY and PATIENTLY find anything in the logs, check them for intrusion, if you have some other logging device in the network check that one too for weird traffic etc. But I think I'm paranoid :PpPp Alin. smime.p7s Description: S/MIME Cryptographic Signature
[no subject]
Mario Freitas wrote: > Hi, > I recently configured a jail on a FreeBSD gateway doing nat for the > interface alias (the jail address, say 192.168.J.J). I tried with natd > and ipnat too. > However there are some problems I still do not understand. First > when I added "nameserver 192.168.X.X" (the nameserver running outside > the jail environment) to the jail, every query to the name server is > made via the loopback interface instead of the internal interface, or > $intif (where I have 192.168.X.X plus 192.168.J.J). Shouldn't the packet > travel(virtually) via the $intif interface (as if the request was coming > from any machine on the LAN)? Also, the packets are travelling through > the loopback interface, where bind _is not_ listening :) (another weird > behaviour?) This is normal. Jails use the loopback interface. You should alter your configuration accordingly. > Second, I've tried using, unsuccessfully, many ipfw rules so any user > inside the jail environment can establish statefully any tcp connection > to the internet. What I do not understand is why the request does not > (virtually) come through $intif (192.168.J.J). Because the jail(8) uses the loopback interface. [snip] I seem to recall some old discussion about the roadmap for jail(8), and somebody mentioned the consideration of a set of patches to virtualize the entire freebsd network stack to facilitate the type of feature you thought jail's have, but don't. __ __ _ | \/ | __ _ ___| |_ __ _ | |\/| |/ _` / __| __/ _` | | | | | (_| \__ \ || (_| | |_| |_|\__,_|___/\__\__,_| [EMAIL PROTECTED] http://wifibsd.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jails & ipfw + nat
Hi, I recently configured a jail on a FreeBSD gateway doing nat for the interface alias (the jail address, say 192.168.J.J). I tried with natd and ipnat too. However there are some problems I still do not understand. First when I added "nameserver 192.168.X.X" (the nameserver running outside the jail environment) to the jail, every query to the name server is made via the loopback interface instead of the internal interface, or $intif (where I have 192.168.X.X plus 192.168.J.J). Shouldn't the packet travel(virtually) via the $intif interface (as if the request was coming from any machine on the LAN)? Also, the packets are travelling through the loopback interface, where bind _is not_ listening :) (another weird behaviour?) Second, I've tried using, unsuccessfully, many ipfw rules so any user inside the jail environment can establish statefully any tcp connection to the internet. What I do not understand is why the request does not (virtually) come through $intif (192.168.J.J). Inside the jail, after executing telnet www.google.com 80, tcpdump -i $intif(outside the jail) shows nothing, but tcpdump -i $extif(also outside) shows packets coming from www.google.com:80 to $extip, both in natd and ipnat cases: ipfw logs the packet being denied tcp from www.google.com:80 to $extip in via $extif (keep-state is not triggered). Any clarification would be appreciated. Sincerely, -- Mário Freitas ([EMAIL PROTECTED]) Núcleo Português de FreeBSD (NPF) signature.asc Description: This is a digitally signed message part
server rebooted
Hello. I have a dedicated server the one was up for more than 84 days but this Friday 19, suddenly the server was rebooted. this is the output of the "last" command # last | grep reboot reboot ~ vie 19 sep 13:55 I already have check the logs but i can't found any hint that could help me to know why the server as was rebooted. Any idea on what to check or how to know what makes the server to reboot? thanks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
