James K. Lowden wrote: 
>  
> Sooner or later, you're going to need remote access to the console, if for 
> no other reason than that single user mode is useful for all sorts of 
> things. 
 
If there's nothing going wrong, I don't see a reason. 
Things can happen: 
- Hardware can fail, burn down or something like that. Ok, that's risk I 
want to take. In such a case I'll always need to access the box live. 
- Kernel panic, or other crash. My watchdog will take action. 
- Harddisk get corrupted and fsck can't fix it (need to re-install). The 
chance it will happen is very small I think. Or have people other 
experiences? 
- While booting, services before telnet hang and stop the whole booting 
process. So telnet daemon will be the first thing to load after network. 
 
If the kernel needs to be updated, (don't see why needs to happen for the 
next period, except very serious bug maybe) I still need to go back, and 
also when a harddisk partition will get corrupted. And for a kernel update 
I can train myself the process on a local box so ensure it will come back. 
 
>  
> Suppose, for example, you update your rc.conf, change your network 
> settings, whatever, and reboot.  You can cross your fingers from 300 km 
> away and hope everything works, so you can ssh in again.  And if it 
> doesn't, what then? 
 
I don't see a reason for changing network connections in this environment. 
They will stay the same. I think you can always do stupid things like 
"shutdown -h" (however my watchdog will save me) or "rm -rf /" but that 
will always be. 
 
>  
> You can set up NetBSD to use a serial port for a remote console.  That 
> won't get you access to an i386's BIOS, but it will let you manage NetBSD. 
>  You can hook the serial port up to a modem, or to a terminal server (and 
> hook that up to your Ethernet). 
 
That's also something to consider. Thanks. 
 
/Bastiaan