[Sheflug] Linux Servers 101

["Stephen J. Turnbull" <nospam [at] sk.tsukuba.ac.jp>]

Short (ho ho ho!) answers first.

>>>>> "Ian" == Ian Wright <Ian [at] iw63.freeserve.co.uk> writes:

    Ian> I'm not sure I need 'commercial' level security.  [...]  My
    Ian> web connect times are also very short and irregular so it is
    Ian> quite unlikely that anyone would manage a 'hit' on my system
    Ian> as it now is.

Please rethink; I'm pretty sure you will regret that attitude as soon
as you have a wide pipe to the 'net and have to start closing random
holes you've forgotten you opened.

    Ian> I looked at ssh but, after 5 attempts, I still haven't
    Ian> managed to do a successful ./configure on it!

Huh?  What's wrong with the RPMs?  Surely they must be available?  (I
use Debian, dunno RPMS but sure I know .debs are easily available!)

    Ian> Can anyone tell me what is going on please and explain in
    Ian> Janet and John language how to run a program residing on one
    Ian> machine on another -

(1) You can run a file server and load the file from the remote
    machine into the local RAM and execute it.

(2) You can login via a terminal to the remote machine and interact
    with the program via the terminal.

(3) You can login via a non-interactive shell to the remote machine,
    and start the remote program non-interactively.

(4) You can login via a non-interactive shell to the remote machine,
    and start the remote program non-interactively, using an X window
    to display output and capture input.

    Ian> all I am trying to do is use a project timetracking program
    Ian> on the RH5.2 machine which is in the workshop - I can't find
    Ian> a suitable program to run under RH5.2 but I have Ktimemon and
    Ian> ptimetracker on the Mandrake box.

Well, (1) will probably fail in your case because of library version
skew.  It's possible to make this work, but you don't want to try for
just one program.

For the others, you need to decide (A) where you want the log files
stored and (B) where you want user I/O to take place.

First you need a way to log in from the Red Hat box where you're
working (RH) to the Mandrake box (M).  This means that

  o M must run a remote shell server.  The "usual suspects" include
    ssh (best), stelnetd (not bad), telnetd (poor third), rsh (yuck).
    These are normally configured in /etc/inetd.conf.  Install them
    using your package manager.  A more exotic possibility would be to
    run the script

    #!/bin/sh
    while (1); do
     xterm -display RH:0.0     # note this is foreground!!!  No `&'!
     sleep 30                  # try again every 30 seconds
    done

    on M.  This will provide you with a shell of whatever user runs
    the script on M, as an xterm window that magically pops up on RH
    soon after (< 30 sec) X starts.  This requires that RH live at a
    constant IP address, and that you do `xhost +M' on RH when you
    start X.  (I don't see how to get xauth or whatever to work in
    this situation, maybe kerberos would but I doubt Ian is up to
    kerberizing his system at this point.  :-)

  o The network must permit the shell protocol to pass.  Possible
    obstructions:

      - firewall code; do `ipchains -L' (as root) and look up the
        blocked ports (if any) in /etc/services (or on ShefLUG ;)  This
        is a bidirectional issue; you must check in each direction.
      - routing; do `route -n' on each host to make sure the other
        host's IP address has a route.  This is a bidirectional issue;
        you must check in each direction.  `traceroute other-host' can
        sometimes help identify problems, but your setup is probably
        too simple for this to help.
      - /etc/hosts.{allow,deny}  Make sure that neither host is in
        /etc/hosts.deny (including implicitly through the ALL or
        PARANOID keywords) if you use a two-file config; if you use a
        one-file config make sure that neither is DENY'd in
        /etc/hosts.allow (for the relevant port/service).

  o RH must have the corresponding client.

(A) If you want the files on RH, you'll need to either transfer them
    manually via rcp, ftp, or the like (requiring the correct server
    on M and the corresponding client on RH, plus making sure the
    network passes those protocols), or you'll need to run a network
    file system such as NFS on one box and mount the log file's
    directory on the other.  If you're just as happy to have them on
    M, you're done.

(B) If you use strategy (1), (2), or (3) above you're done.  It will
    appear in the terminal you use to start the program or not at
    all.  If you use strategy (4), presumably you want user input to
    take place on RH.  You can execute `xhost +M' on RH as the user
    who owns the X display, or with a little luck a more secure and
    transparent authorization protocol will be automatically setup.
    You must check the network as above.  And you must ensure that the
    program started knows which display to use (if I understood the
    error messages correctly, a program running on M is trying to
    display on M).  This can be ensured by (a) making sure that
    DISPLAY=RH:0.0 is in the environment of the program, or starting
    the program with the `-display RH:0.0' flag.

You should be done....

Note that these are _not_ symmetric conditions, it's just that
apparently you had the permissions going in the opposite direction to
what you need in at least some cases.

    Ian> I had thought that this linux across networks was supposed to
    Ian> be the bees knees but I'm beginning to think its more like
    Ian> the wasps backside...

Well, consider that you couldn't do this trick _at all_ on any Windows
or Macintosh system (without installing and configuring X, and going
through the same rigamarole besides).

Hint:  when you get it to work, do `history | tail -40 >
remote-timemon', then edit out the bloopers and the leading line
numbers and the irrelevant commands, and you have a script that you
can call with `source remote-timemon' to get it to work again.  You
just need to remember where you put remote-timemon....

Later you write:

    Ian> I thought that the idea of a server was to provide a central
    Ian> resource of files and programs which you could access and run
    Ian> from other machines on a network.

Servers provide resources, it's true.  This means they must listen for
requests.  That's all there is to it; somebody has to write a
"listener", and bind it to a communications channel.  But the resource
can be anything, including access to the user (the X server).  Nor
does it necessarily involve "centralization."  The essential point is
that the server (slave) waits (listens) for requests from the client
(master), which can come at any time.

To give a complex counter-example, your ISP does NOT provide a "PPP
server."  PPP is a peer-to-peer protocol.  When you start pppd, you
assign it to a communications channel (/dev/ttyS0 or /dev/modem or
/dev/mouse, it doesn't care), and it starts jabbering away.  If there
just happens to be a pppd on the other end of the channel, jabbering
back, eventually they get into synch and start talking LCP and PAP and
IPCP, and then TCP/IP and all the good stuff built on that.  (If
there's a mouse, instead, nothing useful will happen.)  So what
does your ISP really serve?

The telecommunications channel itself!  Its server is a program called
getty.  getty is a server that listens on a /dev/tty, makes a serial
connection with the modem, and then hands off that connection to an
arbitrary program---in this case pppd.

But (if you know what you're doing) it's possible to telnet from one
machine to another, start (using exec) pppd on the second machine and
return to the first one and start pppd there, effectively creating a
new network connection on top of the telnet connection.  (See the
VPN-HOWTO for details.)  All manually.  So there's generally no
difference between servers and other programs, except for the "waiting
for requests" part.  pppd doesn't do that, really (it just starts
jabbering, _assuming_ that something is on the other end listening to
it), so it's technically _not_ a server.

Another problem is that in a network environment, it is not always
clear where I/O is supposed to take place: the local host? the remote
host? a third party?  Eg, if Mandrake was connected to the net and I
had my public key on it, I could do "ssh mandrake xmessage -display
RH:0.0 'hi ian!'" and you would see it on RH!  Sometimes different I/O
channels are directed to several different hosts.  (Hard to come up
with an elementary example of this, but eg a secure webserver might
grab files locally, send them across the Internet as http, and log
them to another host on the LAN using the syslog port.)

    Ian> If, as I thought was often the case, this server has no
    Ian> keyboard and screen, how can you provide the 'telnet?'  link
    Ian> to the machine wanting to run a program on the server?

By providing a telnet server on the server host.  But that's often not
what you want to do.

For example, if you want to serve files, you can run ftpd or httpd
(Apache) or rshd or sshd on the server to provide host-to-host copy
services.  Just like doing "cp /etc/important-file /tmp/tmp; edit
/tmp/tmp", you can do "wget http://over-there/etc/file /tmp/tmp; edit
/tmp/tmp".  Annoying if you don't really want a copy, but want to edit
"in-place", since you have to do the reverse copy (I always forget and
wonder why my Web site doesn't reflect the changes I've made).  In
that case, you run a file server which emulates a file system that can
be mounted like a hard disk: NFS, AFS, Samba, and Coda are examples.
Then you just do "edit /mnt/over-there-nfs/etc/file".

You can serve authorization with login, sshd, xdm, or kerberos
(kerberos does provide a true "network login").

You can serve an interface to the user with getty (on /dev/console) or
/usr/bin/X11/X.

There's (cryptic) list of network-servable services in (where else
but) /etc/services.

    Ian> I guess there must be a more clever way of running the
    Ian> programs than just Telnet and I'm still too ignorant to have
    Ian> found it. Or is there a way to run a script or something
    Ian> which will watch for other machines logging onto the network
    Ian> and automatically make a connection to them?

Unfortunately, machines don't normally log onto a network.  They
simply boot up.  It doesn't really make sense, anyway, since normally
most of the machines booting up don't want the service in the first
place, at least not right away.  Instead, most services you might want
your machines to offer are run in one of several ways:

(1) Started at boot and run in the background as daemons.  This is
    necessary if the service is time-based or has independent tasks to
    do besides in response to external events.  (You can think of the
    kernel as the grandaddy of all daemons.)  If it provides a service
    only to the local host, it can listen on a socket, a named pipe,
    or other more esoteric possibilities for requests from clients.
    Otherwise it listens on an Internet port.

(2) Started in response to requests from clients.  This can be done by
    the kernel (this is sort of what the aliases in the file
    /etc/modules.conf are for) or by the "Internet superserver" inetd
    (see /etc/inetd.conf).

(3) Started at specific times ("cron jobs").

(4) Explicitly started by the user (from a shell, eg via telnet).  PPP
    is often used this way, although typically deeply wrapped in
    scripts (and with its own hooks for calling yet other scripts).

"Complex," you say?  "What do I do?" you want to know?

Yes, it's complex.  That's the price of flexibility.  Windows
networking is "easy", because really you're limited to file and
printer sharing, and you have to use SMB (Lanman, Samba) protocols for
those.  That limitation means that you can set up "Windows networking"
in a four or five tab dialog.

But you can't run a compute-bound graphics calculation on a server and
display it on your Windows workstation (unless you run a separate X or
VNC server, which requires additional configuration).  Nor can you
easily provide a wide range of network services (I have intentionally
served IRC, SMTP, POP, news, mailing lists, ftp, http, Coda, NFS,
telnet, ssh, cvs, X, emacs, finger, auth, ntp, lpd, fsp, talk,
hylafax, wnn, canna, and probably others from my personal Linux
workstation, and I don't even do computers for a living).  Forget a
Beowulf cluster!  If you want that flexibility and power, you have to
deal with the configuration.  Even on Windows, the server admin is a
busy guy/gal.  The surprise is that it's as simple as it is on *nix.

What do you need to do to set up servers?  First, you need to decide
what you want to do.  Serve files?  Off-load resource hog programs to
other boxes?  Serve the web?

Then you need to decide the responsibilities of each box.

Then you need to install the server programs on appropriate boxes;
usually this isn't too difficult with modern Linux distributions.  (In
fact, the big problem with most distros is uninstalling "default"
services you don't need, which are simply security holes.)  Package
managers will normally edit /etc/inetd.conf (or add scripts to
/etc/init.d to start servers at boot) so they'll be started
automatically.

So what exactly is it you wanna do, again?  :-)

-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."
---------------------------------------------------------------------
Sheffield Linux User's Group - http://www.sheflug.co.uk
To unsubscribe from this list send mail to
- <sheflug-request [at] vuw.ac.nz> - with the word 
 "unsubscribe" in the body of the message. 

  GNU the choice of a complete generation.