Tags:
create new tag
, view all tags
Making notes from the excellent series of articles by Colin Mattoon: How to create a Linux-based network of computers for peanuts.

I think the title of the article is misleading -- although they are Linux-based computers connected on a network, it is not, IMHO, a Linux-based network of computers -- it is an applications server with [X terminals | thin clients | whatever] using Linux connected via a network. Still, an interesting article, and I'm condensing it with the thought of implementing it, at least for a trial, on the ChurchServerProject.

See also:

See:

  • AboutThesePages

Contents

Notes

X Terminals and an Application Server connected on a LAN

X Terminals: 486DX, 16 MB of RAM (P75 to P100, 24 MB may be the point of dimishing returns) -- in this case, the X Terminals will not boot from the network thus ~250 MB disk -- decent video driver (hmm, how about sound -- is it possible?) -- CD-Rom optional (without one install over network)

Applications Server: 200- to 300-MHz, 80 to 128 MB RAM, or:

(Largo, FL's, main Application Server: dual 933-MHz, 3 GB RAM for 400 X terminals.)

For 1 to 6 users:

  • 90-MHz Pentium, 64 MB RAM with lean and efficient window manager and applications:
    • FVWM95, TWM, or ICEWM)
    • Abiword
    • Netscape 4.x

  • P200, 80 MB RAM -- KDE (2?) or GNOME (1?)

  • increase to 128 to 192 MB -- install Open Office (with /net)

Notes:

  1. Disk I/O more important than CPU speed -- a P300 with 512 MB may outperform a 1.2-GHz with 128 MB RAM

  1. Consider several smaller disks on different I/O channels (disk controllers)

  1. Put /usr/lib and / on one disk, /usr on another. (Consider RAID-0?)

  1. Hard Drive: 0.5 to 2 GB plus allowance for home directories

In another scenario, the X terminals could boot from the applications server or an additional "boot server" (EPROMS or floppies required)

No data on clients ==> no need for UPS

LAN:

10 Mb Coax network should be very adequate for up to 40 (?) clients -- 10 or 100 Mb -T may be beyond the point of diminishing returns -- for more clients, better networking infrastructure will pay off (there is a worthwhile discussion of some of the issues in the article, especially Part 3)

Network description -- 16 machines:

  • 1 file/print/application server -- (configured as church102.sch at 192.168.0.102 (ChurchServerProject)) -- create users accounts for XTermA thru XTermO, A thru O, or the male and female mail user accounts from ChurchClientAdministration, each with a home directory
  • (optional) Dialup gateway/router running a specialized Linux distribution such as Freesco or E-Smith -- or dos based iproute
  • up to 15 X terminals (PCs running Linux, configured as X terminals) (I'll be trying 15 X terminals configured as XTermA thru XTermO at 192.168.0.11 thru .24, respectively -- will configure a second server if appropriate)

Configure the Application Server

You can read part 3 of the article, but for my intents and purposes it boils down to installing a Linux distro with X windows running, whatever else you want (connection to the Internet), a printer, ... And then create user accounts for each user (or X terminal) -- in essence, your preferred "single user workstation" with multiple user accounts -- there is no need for this to be a "server" installation (although it could be, for other reasons)

Consider security -- see part 3 of the article, but I see nothing extra to worry about at this point.

Some other points:

  • Start XDM automatically (or whatever window / desktop manager) -- this will provide a (remote) graphical login -- as an option users could login at the (remote) command line and start X with startx -- examples:

    • Slackware: in /etc/inittab change id:3:initdefault to id:4:initdefault, or in /etc/rc.d/rc.local add =usr/X11R6/bin/xdm=

    • Debian: in the /etc/rc2.d directory run ln -s ../init.d/xdm S99xdm to add a symlink to the XDM script in /etc/init.d

  • Allow remote X users to login (on older distros, or if you don't plan to do network installs to the X terminals, you may not need to the following

    • In /etc/X11/xdm/Xaccess, uncomment the line (around line 40):

=#* #any host can get a login window=

    • if using XFree86 4.x or newer, in /etc/X11/xdm/xdm-config comment out the line (near the bottom):

! SECURITY: do not listen for XDMCP or Chooser requests
! Comment out this line if you want to manage X terminals with xdm
DisplayManager.requestPort:  0

  • You may want to enable remote use of the server's CD-ROM drive -- open /etc/exports and add a line that reads /mnt/cdrom (ro)

  • Reboot the application server (is that necessary?)

Configure the X Terminals

Pick a Distribution

Considerations:

  • You probably don't want to use the same Linux distribution you used on the applications server.

  • A distribution based on XFree86 3.x is just as good as one based on 4.x (and may be smaller and less resource intensive) -- XFree86 3.x and 4.x work and play well together.

  • Without CD-ROM drives on the X Terminals, we probably want to do a network install.

  • We don't need Pentium II- or III-optimized distributions such as Mandrake and Corel.

  • Other distros not recommended: Caldera, Red Hat,

  • Recommended distros: Slackware version 3.5 for oldest hardware and 8 to 12 MB RAM, 7.0 for slightly newer hardware, 16 MB RAM, and 200 MB hard drive, or Debian, or a Unix like FreeBSD (which may support less hardware)

  • See part IV of the article for a discussion on why the author did not choose a diskless setup (requires more knowledge, good for more than just X terminals, need bootproms or floppy (bootp), additional load on network, etc.(?))

Configuring a PC as an X terminal

  • Install your distro with ~125 MB for / and ~16 MB -- if using an old distro, avoid the cylinder 1024 limit (for LILO), including networking utilities and X -- you don't need a window manager or any applications (although you may want some applications for "standalone" use)

  • Configure the network interface: IP address (from above), netmask, no DNS, no default gateway (more for security than any other reason, AFAICT. Test by pinging the server (and vice versa).

  • Choose a root password (possibly the same for each X terminal, but not the same as the application server), but do not add any ordinary user accounts

  • "Configure X so that the machine will open a "gray screen" when the "startx" command is entered. Just a blank gray screen with a mouse cursor (unless you wasted time and disk space to install a window manager, there is nothing for X to display). But do not configure /etc/inittab or, as the case may be, /etc/rc2.d or any other initialization script to boot the machine to X. As in the case of the application server configured in part 3, we first configure the X terminal to boot to the multi-user, networking, character-cell (command line) runlevel." &lt:left as a quote since I'm not sure I really know how to get to just a blank gray screen -- summarize later>

  • Reboot (necessary??)

  • As a test, enter the following command (as root): /usr/X11R6/bin/X -query 192.168.1.10 (with correct server IP address) -- you should see (after a delay) the login window of the application server

  • If all OK, add the above command to boot -- kill X, then with:

    • Slackware: In /etc/rc.d/rc.local add the line you tested above -- =/usr/X11R6/bin/X -query 192.168.0.5=

    • Debian: in /etc/init.d/ create a new executable (chmod 755) file named xterminal containing:

#!/bin/sh
/usr/X11R6/bin/X -query 192.168.0.5 

<break>

And change to the /etc/rc2.d directory. There you will create a symlink to your script as the last step in booting the machine (Quite similar to configuration of the application server, no?)

ln -s ../init.d/xterminal S99xterminal

In that directory, the ls -l command should reveal your symlink as the very last entry:

S99xterminal -> ../init.d/xterminal

And if it does, you can reboot your machine and join the Slackware administrators in an orgy of self-congratulation before you go on to configure the remaining seven machines.

Red Hat, Caldera, SuSE users One or either of these two methods will get the job done. Adjust your default runlevels and the location of the specific files to edit based on your particular distribution, but the essence for all distributions is:

Boot to a command line only, multi-user, networked runlevel, and as a last step in system initialization, either in rc.local or as a script you create (and link to) in init.d, the machine will run the command:

/usr/X11R6/bin/X -query 192.168.1.10

(Or whatever address you assign to the application server in your network.)

Installing without a CD-ROM drive Watch for Part 5, where I explain how to install Linux over the network, and use applications, such as AbiWord, remotely from PC X terminals.

Other Notes

Faking It

Since I had two Linux boxes running (my email/Apache server and my workstation), I thought I could possibly test the use of the server as an X terminal to the workstation (which is set up as I might set up an applications server). I did have to go in and change things in the files as described above, started X on the server (using X -query 192.168.0.5), and eventually rebooted both machines. I got the X terminal gray screen as suggested above, but never got a login to the other machine. May recheck and try again.

Reviewing and continuing:

  • Initially did the things listed above for xdm, tried the X -query -- gray screen and nothing more -- checked ps -Al to see which window manager was running, could not find xdm, kdm, or gdm -- nevertheless

  • Modified the /usr/share/config/kdm/kdmrc file:

=[Xdmcp]=
Enable=True

  • Modified the /etc/X11/gdm/gdm.conf file:

=[Xdmcp]=
Enable=True

Did not comment out to avoid the local X server:
0=Standard

  • Started X -query again -- no luck, waiting for a convenient opportunity to reboot or restart X.

Starting X

X :1 -query 192.168.0.5 works to start a second X display

startx -- :1 the "--" is significant -- parameters after "--" go to the server (those before go to the client, presumably)

My Progress

I managed to get an X terminal (on my system8) working and talking to a Knoppix applications server (system12, temporary) and a Mandrake 9.0 applications server (system5).

Some things I learned:

  • I started by following the "instructions" listed above.

  • After doing so, I got the gray screen on system8, but no sign of a login on the Knoppix or Mandrake system.

  • On Knoppix, I eventually discovered that there were three versions of the Xaccess file -- two (hardlinked to each other), at /etc/X11/xdm/Xaccess and at /etc/X11/.../X11R6/...Xaccess, but these had no effect on kdm. The third copy is at /usr/share/config/kdm/Xaccess and it is the one that controls kdm on Knoppix.

    • In some other X experiments with knoppix I often got "connection denied" (or something similar) -- I later read that Debian often sets the -nolisten tcp option by default, and since knoppix is based on Debian... (I later did a grep -r -H -e nolisten -f /etc/* and found that, indeed, that was set in several places -- I didn't remove it to try any further experimentation.)

  • I had more difficulties with Mandrake. Eventually I discovered that (at least my installation of) Mandrake 9.0 was not starting a display server by default.

I learned this by using commands like:

netstat -ac | grep Xdmcp

ps -Al | grep dm

The first showed nothing listening for xdm (??), the second showed that the only thing running related to a display manager was prefdm, which, based on some quick skimming, I thought was intended to recognize which display manager was most appropriate (xdm, gdm, or kdm) and start it.

Even though no display manager was running, KDE started locally and ran fine (but without the login screen to choose a user -- the problem may be related to some autologin settings which I've since disabled with no change in behavior. (Somone has suggested I run urpme autologin.)

I mentioned this behavior on the Mandrake expert mailing list in an effort to find out whether it is the intended behavior of Mandrake (not running a display manager) -- not sure I got an authoritative answer. I've added kdm to local.rc and that lets me use the X terminal, so I'll let sleeping dogs lie.

In my first configurations, I did nothing with the fontserver. I had a few ugly looking fonts that I fixed (much later) by reassigning fonts in Mozilla and KMail (I may have to do more of this as I try other applications).

Later I tried to make the fontserver listen on port 7200 (instead of the default -1 -- does that mean "not listen (or serve) over the network"?). Changed several (two?) files as listed in How to use Cygwin to work with a Linux Server.

The files changed included:

  • /etc/.../xfs?? (two places)
  • /etc/XF86Config

Caused problems, and after several attempts, reverted the change.

Also, in the course of trying to deal with the no login screen issue, I was directed to the /etc/sysconfig/desktop file and experimented with entries like DESKTOP=KDE and DISPLAYMANAGER=KDM. Even after being pointed to the autologin options (Control Center --> _ ) these seemed to have no effect on the problem. Something else must be involved.

<Currently, no significant content below this line.>

Resources

See ResourceRecommendations. Feel free to add additional resources to these lists, but please follow the guidelines on ResourceRecommendations including ResourceRecommendations#Guidelines_for_Rating_Resources.

Recommended

Recommended for Specific Needs

  • (rhk) How to use Cygwin to work with a Linux Server; ; — includes this on dealing with the font server: "# Red Hat 7.x and Mandrake 8.x users can skip this step. Make sure that XFS (the X Font Server) is listening to the network: edit /etc/rc.d/init.d/xfs and make sure that the "-port" flag uses 7100 instead of -1. If you did have to do this, you'll also need to edit your /etc/X11/XF86Config-4 file. *service xfs restart*" — port was set to -1 on (my) Mandrake 9.0.

  • (rhk) Network Booting: Save time, avoid headaches with a centralized boot server; Tim Kientzle; October 2002; — diskless booting, dhcp, etc. (browsed the first three sections, probably useful if I want to use DHCP, PXE, or boot PROMs on a NIC. The Instant Classroom could come in handy: "For an instant classroom, configure a portable machine as a network boot server. When you arrive on-site, plug it into the classroom network, reboot each classroom machine, and immediately have the required setup."

Contributors

  • () RandyKramer - 17 Mar 2003
  • <If you edit this page: add your name here; move this to the next line; and include your comment marker (initials), if you have created one, in parenthesis before your WikiName.>

Page Ratings

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2003-04-25 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look