echo '192.168.0.102 dmz dmz' >> /etc/hosts
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
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.
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
You can reduce the cost of ownership of your Linux system by not using a VGA monitor. This creates what is also known as a "headless" system. Operating costs may not be important at home, but will be in a corporate environment with large numbers of Linux servers racked in data centers. In such cases, access to the Linux box can be more cheaply provided via the COM port.
I've included this section as I have occasionally hosted the website www.linuxhomenetworking.com at friends' homes and felt badly about borrowing their monitors. Having access via the COM ports has also helped me in both the home and business situations. The most common occurrence is when the system is hung, locking out network access, and I need to get to it by using:
A notebook PC with a console cable connected to the COM port.
A modem connected to the COM port
Telnet to login to a terminal server that has one of its ports connected to the Linux box's COM port
One of the advantages of this method is that you don't need a keyboard either. Unfortunately your BIOS may halt the system during the Power On Self Test (POST) if it doesn't detect a keyboard. Make sure you disable this feature in the BIOS setup of your PC before proceeding. This feature can usually be found on the very first screen under the "Halt On" option.
You will also need to make sure that you have activated your COM ports in your BIOS settings.
For non-modem connectivity (PC to PC) connect a NULL modem cable to the COM port you want to test, connect the other end to the client PC running "Hyperterm" or whatever terminal emulation software you are using. One popular Linux equivalent to Hyperterm is "minicom". A brief configuration guide for minicom follows the section below.
If you're using a modem for connectivity, then you'll need a FULL modem cable and testing will have to be done using a dial up connection.
In RedHat Linux, the COM1 and COM2 ports are controlled by a program called "agetty", but "agetty" usually isn't activated when you boot up unless its configuration file /etc/inittab is modified. In other versions of Linux, "agetty" may be called just plain "getty". Here is a table that lists the physical ports to their equivalent Linux device names.
| Port | Linux "agetty" Device Name |
| COM1 | ttyS0 |
| COM2 | ttyS1 |
The following lines added to /etc/inittab will configure your COM ports for terminal access:
# Run COM1 and COM2 gettys in standard runlevels S0:235:respawn:/sbin/agetty -L 19200 ttyS0 vt102 S1:235:respawn:/sbin/agetty -L 19200 ttyS1 vt102
In summary, these lines mean:
At boot time, when the system enters runlevels 2, 3 or 5, "agetty" must attach itself to devices ttyS0 and ttyS1 and emulate a VT102 terminal running at 19200 baud.
The "-L" means ignore modem control signals, this option should be omitted if you are connecting the port to a modem.
The respawn means that agetty will restart automatically if, for whatever reason, it dies.
The next step is to restart the "init" process to re-read /etc/inittab
[root@bigboy tmp]# init q
Now you need to configure the terminal client such "as Hyperterm" to match the speed settings in /etc/inittab. Connect the console / modem cable between the client and your Linux box. Hit "enter" a couple times, and celebrate when you see something like this:
Red Hat Linux release 8.0 (Psyche) Kernel 2.4.18-14 on an i586
bigboy login:
Note: By default, user "root" will not be able to log in from a terminal. To do this you'll have to edit the /etc/securetty file which contains the device names of tty lines on which root is allowed to login. Just add ttyS0 and ttyS1 to the list if you need this access.
documented on: 2008-05-21
Subject: How to build a head/headless, multimedia, file, and print server using Puppy Linux
Hardware Requirements
Designated Desktop or Laptop
Desirable Audio output
Ethernet Cable
Wireless/Wired Router
Key Board can be removed later
Mouse can be removed later
Monitor can be removed later
Optional Large LCD television
Another computer to use as a remote control
A stereo receiver/ tuner
Some speakers
Software Requirements
Puppy Linux
Brief steps
install Puppy to the hard drive.
install Tightvnc server
install X11vnc.
install Samba
enable X11vnc and Tightvnc
setup the password for vncserver
At this point you may want to know why I installed two vnc servers. X11vnc will allow me to use, modify the display that is currently scene also know as display : 0. X11vnc is very fickle if you do something like inappropriately quit the session it can remain locked up and the only way to resolve is to login with a different vnc session and reboot the computer. This is where Tightvnc comes into play.
If you want to remove the monitor, mouse and keyboard (a headless system) you have to do the following. Remove the monitor connection and reboot the computer. You will hear 1 long beep and 3 or 4 short beeps following. This will happen every time you reboot because the computer is trying to tell you there is no display connected to the computer.
You need to wait 2 minutes for Puppy Linux O.S. to get to the section where it asks you to select you monitor.
Then connect the cable and you have to choose a display resolution, default is 640 X 480. Once you choose one remove the monitor connection then hit Enter.
Wait for 20 seconds then plug the cable in again. The O.S. need you to answer one more question. You need to disconnect the monitor then hit Enter then it will boot up and enter the gui all is good.
Log into the computer using your vncviewer client in Mac or Windows. Or run the command vncviewer 192.168.X.X:5900 or 192.168.X.X:5901. The latter is the admin using Tightvnc viewer and requires a password. The former requires no password and this is the one everyone should use to change the music playing, play movies if you have this machine connected to a large display, store files, print or play your favorite S.N.E.S. , Atari, P.C. Engine or Arcade Roms.
Getting the print sharing to work…
Last edited by lindylex on Wed Apr 30, 2008
documented on: 2008-05-21
"krfb" and "krdc" allow you to setup & control a session on a remote computer. Check out the "kdenetwork" package. Once "kdenetwork" installed they can be found under KDE Menu > Internet > Remote Access
My non-technical description of krdc & krfb
krdc is a client that will allow you to control a remote pc using the VNC or RDP protocol. And krfb is a server you install on your remote pc to allow you to connect to and control it using the VNC protocol.
If you install and setup "krfb" on you PCLOS pc then you could use UltraVNC http://www.uvnc.com/download/index.html or TightVNC Viewer http://www.tightvnc.com/download.html which would be my choice, because they have a viewer (client) that can be run without installing. This would allow remote control of the PLCOS pc From the XP pc and the PCLOS display would display everything done from the XP machine.
Edit: Both links pointed to the same website.
Last Edit: February 12, 2008 by callmeajs
documented on: 2008-05-21
By Steven J. Vaughan-Nichols on March 25, 2003
With networking built in from the ground up and programs like telnet and SSH, Linux comes with remote control. But if you need to troubleshoot and administer Windows PCs from your Linux workstation or just run the occasional Windows program without worrying about Windows/Linux compatibility software, NetOp is the program for you. . .
> VNC
VNC is not secure.
However, you can wrap it in SSL using stunnel.
or if screen refresh is a big problem see:
tightvnc.org
Uses vnc base with jpg screen display and its open source…whehee
Scupper
To manage windoze boxes you have two options: rdesktop and vnc. I preffer rdesktop (RDP client for Linux, requires windows to be running terminal services) because it kicks ass! It also does somethign VNC can't do….lets you get to the login prompt. See with VNC even though its running as a service, unless someone is logged in on the windows box you can't controll the box. So if you just reboot the windows box running vnc service, you have to make sure it automatically logs someone in for vnc to kick in. rdesktop is awesome!
Rdesktop works with windows terminal services and has frontend GUI's.
rdesktop is great. if you like that, try tsclient - it's a frontend to rdesktop that allows storing configurations. still needs a little work, but it's nice.
documented on: 2008-05-21
Posted by Cliff on Jan 12, 2005
Administration of headless machines can be a pain, and working on multiple machines can also be a bit of a bother. KVM boxes solve some of the problem, but sometimes finding a keyboard and a monitor to lug around to these machines is most of the problem. Is there a portable solution that might solve both of these problems? Wouldn't it be nice to carry around a specialized laptop that could act as both a portable display and input device? Does something like this currently exist?
The best bet is a single user/single server KVM over IP unit, which is essentially a bridge between Ethernet and a Keyboard/Video/Mouse set.
by jdray
Two choices: first, an IP KVM installed in each rack. But you still have to address the power switch and media. Another poster mentioned PXE booting. It works, but takes effort to build all the different images you want to have handy, and what do you do for a hung box 1,000 miles away? Or once you address the power question, the NIC is bad?
Second: IBM (and others) offer remote systems management cards that not only give you full remote KVM on the server the card is installed in, but they also give you access to the system power and screen captures of blue screens that may have occured before the server rebooted itself to recover. They can also present virtual floppy and CD-ROM drives to their host servers. Finally, if you don't want to run 10/100 and do IP allocations for each management card, you can daisy chain up to 24 servers together over RS-485 and use any one of them as a gateway to the IP network.
One IP address. Full remote KVM access to up to 24 servers at a time. Access to the system power. Access to screenshots of blue screens that may have tripped a reboot. Full hardware and software alert forwarding directly handled by the gateway card or passed on to enterprise systems management environments via numerous methods. Virtual floppy and CD-ROM drives. If you still absolutely insist on going onsite to the box, you can sit at a desk in the corner and get an IP.
by LinuxHam
The issue with network-based server management is that it isn't suitable for a large data center. For instance, a typical webhosting setup might have a couple hundred (or thousand) servers - the ideal target for remote management, because it's wildly impractical/impossible to put them all on KVMs. Each server will have one NIC for the "public" network, the one connected to the Internet. To help lock down remote access for SSH etc., you will also have a private network. We're already up to two distinct networks here, you'll note. Now add a third one for management, which incidentally is also going to require DHCP. The cost for building yet another discrete internal network - and managing it! - is going to be nontrivial. It's usually cheaper, and about as effective, to buy a couple cheap-ass carts and put monitors and keyboards on them. It means your NOC staff has to get off their asses every now and then, but… Is sparing them that really worth the $10k+ it will probably cost in network hardware (not to mention cabling nightmares)?
Serial consoles are great, but not for PCs. In a big DC, you will not have the root password to every server. You will be logging in via some special authentication mechanism like SecurID and then doing sudo su (or just ssh public keys). So getting a login prompt is not going to be helpful; you'll have to reboot the server. On real Unix hardware, you can usually do this by sending a hardware break and typing "reboot" (or similar). This will work even if the OS is crashed or thrashing or whatever. On a PC, no dice, because it's purely the software which handles the serial connection. So you have to hit the reset button, which will probably solve whatever issue was going on anyway (while simultaneously destroying any in-memory logs of what the cause might have been).
For us, in our DC with about 5000 servers, the worst servers to manage are actually the real Unix hardware, but that's only because we have just the one laptop (and because the Unix servers are all disasters held together by spit and baling wire, but that's another story). Also the laptop sucks ass and keeps breaking because it's 6 years old and has been dropped several times. That's something else to keep in mind if you're looking for a laptop-based solution: People Will Drop It. Not only that, if they have to step away from the server for a second, the laptop will get left on the floor, where some unwary soul will step on it or wheel a crash cart over it. Laptops are expensive, even secondhand. A crummy 15" CRT and keyboard will set you back $100, if that, and if they're on a cart that can be wheeled around they won't get dropped (often). Just make sure to buy monitors with fully-removable video and power cords, so when someone wheels the cart off without unplugging it you won't wreck the server's video connector and pull the PDC out of the rack.
by ctr2sprt
If we can't ssh to computers or telnet to equipment (switches, etc) we have an OpenBSD laptop which we can use as a console via a serial cable and kermit. That's assuming a unixish system, though. If you're only running Windows on servers then why not install TightVNC and control it from your desktop?
by grub
KVM over IP ? - I think some one has already mentioned this previously, however, they mentioned the plugin card variety. You can also purchase a stand alone box, similar to a regular KVM, however, it routes the Keyboard, Video and Mouse via IP to any machine that is network capable. The client is supplied either as a windows binary or as a Java applet (when you browse to the maintenance webpage. You can, in theory use a wireless PDA or laptop with a java enabled web browser to connect directly and control these devices.
by farzadb82
documented on: 2008-05-21