My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck was waiting for an answer, you could remotely ssh in, kill it, restart it, and answer (or give it the right flags).
Does anyone know if it's possible to have that happen with CentOS? It would be nice to have it boot that way, so that if you checked, and figured it should have been up already, you could handle the problem without coming in....
mark
On Wed, Apr 27, 2011 at 4:14 PM, m.roth@5-cent.us wrote:
My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck was waiting for an answer, you could remotely ssh in, kill it, restart it, and answer (or give it the right flags).
Does anyone know if it's possible to have that happen with CentOS? It would be nice to have it boot that way, so that if you checked, and figured it should have been up already, you could handle the problem without coming in....
mark
I think having a decent remote console is the solution to that. DRAC, KVMoIP, Serial console, etc... I'm not sure how it could be considered safe to start services like sshd before the filesystem has been checked.
// Brian Mathis
Brian Mathis wrote:
On Wed, Apr 27, 2011 at 4:14 PM, m.roth@5-cent.us wrote:
My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck was waiting for an answer, you could remotely ssh in, kill it,
restart
it, and answer (or give it the right flags).
Does anyone know if it's possible to have that happen with CentOS? It would be nice to have it boot that way, so that if you checked, and figured it should have been up already, you could handle the problem without coming in....
I think having a decent remote console is the solution to that. DRAC, KVMoIP, Serial console, etc... I'm not sure how it could be considered safe to start services like sshd before the filesystem has been checked.
Hmm, now *that's* an interesting thought: with, say, DRAC, could you ssh into a management server, then go to a booting system?
mark
On Wed, Apr 27, 2011 at 4:28 PM, m.roth@5-cent.us wrote:
Brian Mathis wrote:
On Wed, Apr 27, 2011 at 4:14 PM, m.roth@5-cent.us wrote:
My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck was waiting for an answer, you could remotely ssh in, kill it,
restart
it, and answer (or give it the right flags).
Does anyone know if it's possible to have that happen with CentOS? It would be nice to have it boot that way, so that if you checked, and figured it should have been up already, you could handle the problem without coming in....
I think having a decent remote console is the solution to that. DRAC, KVMoIP, Serial console, etc... I'm not sure how it could be considered safe to start services like sshd before the filesystem has been checked.
Hmm, now *that's* an interesting thought: with, say, DRAC, could you ssh into a management server, then go to a booting system?
mark
A DRAC can provide: - Web interface to server control and monitoring functions - Remote console (KVM) - SSH login to a command-line server control - SSH login to Serial console redirect
I haven;t used the SSH part that much. However, DRAC is Dell specific, and must be purchased with the server. With remote console, you might be able to get in, but I'm not sure if the other gettys are running before the fsck starts.
// Brian Mathis
On Wed, Apr 27, 2011 at 05:25:22PM -0400, Brian Mathis wrote:
With remote console, you might be able to get in, but I'm not sure if the other gettys are running before the fsck starts.
With a true serial console you get access to ''the'' console, where the message about proceeding with the fsck would normally appear. The remote serial console HOWTO is old but covers this ground fairly well:
http://tldp.org/HOWTO/Remote-Serial-Console-HOWTO/index.html
It addresses getting access to the BIOS, the bootloader, and the kernel / getty, so you have access to pretty much the entire boot process. This has saved my bacon quite a few times.
Serial console aggregators run less than $1000, and you can ssh into them to get access to a given console. On mine, for example, I might do
ssh admin:deadbox@serial-console.example.com
to get to deadbox's console.
--keith
On Wed, Apr 27, 2011 at 10:28 PM, m.roth@5-cent.us wrote:
Hmm, now *that's* an interesting thought: with, say, DRAC, could you ssh into a management server, then go to a booting system?
I'd recommend you use a vpn connection instead, so you can go straight to the iDRAC/ILO/RSA2 (Dell/HP/IBM, respectively) using ssh and https
That way you can powercycle the server, access the bios, and work in the console without a running sshd.
BR Bent
On 04/27/2011 03:22 PM, Brian Mathis wrote:
On Wed, Apr 27, 2011 at 4:14 PM, m.roth@5-cent.us wrote:
My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck was waiting for an answer, you could remotely ssh in, kill it, restart it, and answer (or give it the right flags).
Does anyone know if it's possible to have that happen with CentOS? It would be nice to have it boot that way, so that if you checked, and figured it should have been up already, you could handle the problem without coming in....
markI think having a decent remote console is the solution to that. DRAC, KVMoIP, Serial console, etc... I'm not sure how it could be considered safe to start services like sshd before the filesystem has been checked.
sshd can't come up before the fsck ... fsck is done on unmounted file systems. On the old Sun machines (and the new ones for that matter) there was a remote console (exactly what Brian mentions) that you had access to where you started the OS. This Console allow you to see things before sshd was turned on via the machine, but it was also on a separate IP address from the machine.
On Thu, Apr 28, 2011 at 03:38:44AM -0500, Johnny Hughes wrote:
On Wed, Apr 27, 2011 at 4:14 PM, m.roth@5-cent.us wrote:
Does anyone know if it's possible to have that happen with CentOS? It would be nice to have it boot that way, so that if you checked, and figured it should have been up already, you could handle the problem without coming in....
marksshd can't come up before the fsck ... fsck is done on unmounted file systems. On the old Sun machines (and the new ones for that matter) there was a remote console (exactly what Brian mentions) that you had access to where you started the OS. This Console allow you to see things before sshd was turned on via the machine, but it was also on a separate IP address from the machine.
Same with DRAC. It's useful, for example, if one is trying to do something like team NICs, and a mistype makes the machine's main IP address unreachable. As Johnny says, it's a separate IP address.
On 04/27/11 1:14 PM, m.roth@5-cent.us wrote:
My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck was waiting for an answer, you could remotely ssh in, kill it, restart it, and answer (or give it the right flags).
not on any Sun I've ever seen. fsck happens before TCP or much of anything else
maybe he's confusing the serial consoles of the Sun's, which were usually attached to Console servers that you could ssh into ?
On Wed, Apr 27, 2011 at 04:14:48PM -0400, m.roth@5-cent.us wrote:
My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot, so that if there was a problem, and fsck
Define "old Sun". SunOS 3 and 4 never had ssh. Solaris 2.x, Solaris 7, Solaris 8 never came with ssh out of box. Solaris 9 was the first version to come with (a broken) SSH as part of the standard build.
was waiting for an answer, you could remotely ssh in, kill it, restart it, and answer (or give it the right flags).
No. You could do it on the console (as others have said) and so with a serial console connected to a terminal server, or with later-day LOM devices, you could get to the console "out of band".
Sun, in fact, were the poster boys for needing to fsck because they threw a lot of stuff onto /usr and had /usr as a separate partition. And many many of the shared libraries were in /usr/lib, so you could only run statically linked programs (normally in /sbin) before filesystems were mounted. SunOS 4 didn't even have "cat" available, so the startup scripts had a shcat() function which used shell builtins to emulate it.
m.roth@5-cent.us m.roth@5-cent.us wrote:
My manager reminds me that "in the old Sun days", the ssh server came up first, *before* the fsck on boot
As others have indicated, but not in so many words, your manager is out to lunch in this case: ssh, once it was introduced, was started at run level 3 (or the equivalent, for SunOS 4, which wasn't SYSV).
On old Sun hardware, you could connect to the serial port to get console. (You could also have a graphical console if you had the add-in video cards, but people rarely used those for anything but workstations.) If your serial console was on a console server or serial aggregator (like a modem server in reverse), then you could telnet into it to get console on the Sun box.
Later, the serial console was augmented by the ALOM (which predates the DRAC for Dells). Originally you could only telnet into it (using a separate management ethernet connection) which means you should have your management interface on a separate admin net.
Between 5 and 10 years ago, Sun got around to introducing SSH to the ALOM. At *that* point, you could ssh into a Sun to get console. Everything is relative, but I wouldn't refer to that as "the old Sun days", unless you're meaning "before Oracle".
As I've mentioned on other threads, if you need this kind of functionality for an x86 box that doesn't have its own ALOM/DRAC/iLO (all manufacturer names for similar functions), I'd suggest the AdderLink iPEPS (network only) or iPEPS/DA (network + local kybd/monitor/mouse). It uses encrypted VNC instead of SSH, and can be teamed with an electronic KVM switch to allow you to use it with multiple machines.
Devin
-
Bent Terp -
Brian Mathis -
Devin Reade -
Hakan Koseoglu -
John R Pierce -
Johnny Hughes -
Keith Keller -
m.roth＠5-cent.us -
Scott Robbins -
Stephen Harris