		Next

Headless System

Table of Contents

Building a headless bare-bone server

A system without the monitor is called a "headless" system. What I want to build is a bare-bone server, which not only without a monitor, but no mouse or keyboard either. I just did it. Not a big deal at all — No fancy Vnc or Samba servers at all, just setup sshd server properly and off you go.

In brief, here is what I setup properly for headless/bare-bone server to work:

Give the server a static IP from my home router.
Properly setup its sshd server. Ref: http://xpt.sourceforge.net/techdocs/nix/conn/ssh/ssh05-SshServerConfiguration/index.html#sshd_server_configuration_for_Slackware
Properly set grub's default boot to get into the setting that I want.
Setup its host name properly from my workstation:
```
echo '192.168.0.102 dmz dmz' >> /etc/hosts
```
Establish (passwordless) ssh connection from my workstation to the server. Ref: http://xpt.sourceforge.net/techdocs/nix/conn/ssh/ssh02-OpenSSHAuthentications/
```
$ ssh root@dmz
Last login: Thu Jun  5 17:41:00...
```
Launch any applications I want (from command line), including Xwindow applications — the Xwindow applications launched from the server will show up on my local Xwindow. You really can't tell which application is launched from where because there is no visual differences between them.

That's it. A headless/bare-bone system in Linux is not a big deal at all, as long as you know how to start things from the command line. If you prefer an X Desktop instead, to launch X applications via menu, read on. File transfers between the workstation and the server is via (passwordless) scp.

Once you've got to this stage, there is no need to switch monitor, mouse and keyboard between the two system any more. Feel free to install (or configure) any thing else you deem necessary (e.g., samba or nfs, etc).

Notes:

I use Slax as my dmz server. That's why I ssh into it as root. The Slax's frugal installation method make my dmz server quite secure — even if it is compromised (by any root kit), most probably a reboot is all it needs to clean up the contamination. Ref: http://live-developers.sourceforge.net/tools/persistent/#Keep_it_stable_and_reliable
To allow X11Forwarding, sshd_config on the remote server should be set up like this:
```
X11Forwarding  yes
X11DisplayOffset 10
```
ssh_config on the local machine should contain the following:
```
ForwardAgent yes
ForwardX11 yes
```
The last command in my /etc/rc.d/rc.local is the following. It sounds like the ding-dong door bell, which indicates me: "the headless server is ready".
```
beep -f 493.9 -l 200 -D 20 -n -f 392.0 -l 400
```
About the beep command, it is from the beep Debian package:
beep does what you'd expect: it beeps. But unlike printf "\a" beep allows you to control pitch, duration, and repetitions. Its job is to live inside shell/perl scripts and allow more granularity than one has otherwise. It is controlled completely through command line options. It's not supposed to be complex, and it isn't - but it makes system monitoring (or whatever else it gets hacked into) much more informative. Homepage: http://johnath.com/beep/
Removing the monitor and/or keyboard connection may cause the following symptom in very old BIOS — You may hear 1 long beep and 3 or 4 short beeps on boot up. This will happen every time you reboot because the computer is trying to tell you there is no display connected to the computer. My server box is so old that it is 586, 256M memory, does not support USB booting, yet it does not exhibit such behavior.

documented on: 2008-06-05, xpt

how to setup remote X Windows

compiled from http://www.linuxquestions.org/questions/slackware-14/remote-x-windows-how-to-setup-641945/

If you're trying to work on your son's computer from your computer, you can always start a remote X session over ssh. You shouldn't need any xhost mumbo jumbo to do it either. Starting from runlevel 3 (just because I don't know how to get this working from runlevel 4 because I don't use it), run `xinit` as your normal user. You can then ssh into his box making sure X forwarding is enabled. `ssh -l loginname -Y ip.add.re.ss` should do the trick — but I've found, at least with Slackware 11.0 and 12.0, that X forwarding will not work unless it's enabled in /etc/ssh/sshd_config on the TARGET machine (uncomment the "X11Forwarding" line and set it to "yes" instead of "no", and then restart sshd). The -Y parameter enables trusted X forwarding on your ssh session. Your mouse cursor must be inside the white box or your keyboard will not work (strange, I know). If you want to try this from runlevel 4, remember that terminal 6 is always available for a text console — try starting it from there (Ctrl+Alt+F6). If you try and start an X session (xinit) from runlevel 4, you may need to open it up on a second or third etc. display by typing `xinit — :1` or higher — but again, I'm not sure.

Once logged in through ssh, type 'startx', and the default window manager or desktop environment should start — and you've got a full remote X session. You *may* also be able to run GDM or something from the xinit window, but I'm not sure since I've never used it. Then you can use his computer from yours and work on getting Face Browser to work (which looks pretty nifty after a quick Google).

`xinit` starts nothing but a terminal in X — it doesn't start your window manager/desktop environment. X is started, but no window manager is loaded, so when you attempt to load the remote window manager through ssh, it'll show it on the current display. Note that this will fail if you have a ~/.xinitrc or ~/.xserverrc — if you do have one or both of those, you'll have to pass other options to xinit. See `man xinit`. If you use runlevel 4, I think you'd get something like "X server already running on display :0" or some such thing. You could try Xnest (after a brief try it works) to accomplish the same thing in runlevel 4 (from within an X session). Open a terminal and type `Xnest -ac :1 &`, which should open a black window, followed by `xterm -display localhost:1`, which should open an xterm in the window. The instructions would then be exactly as above (ssh, then startx). However, this is really slow, even with XFCE on the target machine. It's faster (still slow, but passable) using xinit outside of an X session.

-- T3slider wrote on 05-13-08

Here is my solution that works well. First, as it was said above, be sure that X11Forwarding is enabled on both remote and local machines. Then, using terminal (switch to tty6 to do the followings, but you can do it from kde or any other graphical environment as well):

export DISPLAY=:1
X :1 &

It exports the DISPLAY variable to be :1 and then starting X on display:1. At this moment you'll be taken to just fired up X, so switch back to your terminal and:

ssh remotelogin@remotemachine /usr/bin/startkde

and once more you'll be taken to X on display:1, but now with remote kde session showing on local machine. You can then try launching other apps afterward. If you use GDM on the remote machine, you can replace the startkde command with '/usr/bin/gdm', even if you use KDM on your local machine.

05-14-08, atelszewski

documented on: 2008-06-06, xpt