\documentclass{article}
\title{Debian in Computer Labs Howto}
\author{Bernhard R. Link <brlnk@debian.org>}
\begin{document}
\begin{abstract}
Environments with many (and often changing) users of more or 
less different knowledge and needs working on some central
administrated computers seem to get old-fashioned. But as
I administrate such an `Computer Pool', I wanted to
collect tricks for others and hope to get other people's
tricks back in return.

Debian is traditionally best suited for such an environment,
as it is designed to make things transparent and easy,
and does not hide and complicate things in order to make
it look easier.

Such an environment has also some conflicting requirement
to many efforts of the last time. Target is not some
person being administrator and user of a single computer,
but to help an administrator to build a usable system
for its users.\footnote{Note that Debian documentation
of speaks about the administrator as the user of Debian,
while this howto is placed one level below}

Usability for the users has many aspects: Different users
(especially with experienced under them) want to configure
the system each in a way they know. Most importantly they want
to use their favourite window manager. On the other hand
users coach each other and ask each other how to do things.
(Especially with dedicated rooms full of computers.) Thus
they still should be able to do the same, even in different
settings. A user\footnote{at least all I've met and every real
person I've heard of.} does not use the spreadshead 
program looking
the most similar to his window manager, but the one someone
other can explain or has the features he wants. And he 
gets confused and complains,
if this one his hidden from him.

\end{abstract}

\section{WindowManagers}
When having multiple window managers, having everywhere the
same menu makes life much easier. A very large obstacle for
the inexperienced users are in my experience those gnome
and kde menus. Having multiple menus (the Debian one and
an KDE or Gnome menu or both) leads them to always search
in the wrong one. And having not the same menu structure
as the user next to him is in my experience the easiest
way to bring an user in a severe state of confusion.

\subsection{icewm}
\verb|icewm| is a very good choice to give unexperienced users.
It behaves like most of them expect, while being fast
and not confusing with unnecessary details. \verb|icewm-gnome|
has also gnome support in it, but also adds the confusing
gnome-menus. As of woody it also has a standard theme, that
scares most people away from it in my experience. This all
gets better with putting the following lines in the
\verb|/etc/X11/icewm/preferences|:
\begin{verbatim}
Theme="warp3/default.theme"
ShowGnomeAppsMenu=0
ShowGnomeUserMenu=0
ShowKDEMenu=0
GNOMEFolderIcon=0
\end{verbatim}

Also recommendable is to put the most important programs to
\verb|/etc/X11/icewm/menu| and \verb|/etc/X11/icewm/toolbar|
and to point the users to \verb|/usr/share/doc/icewm/html/icewm.html|.

\subsection{KDE}
KDE is in my experience best not installed at all. I seems to
resist any way to integrate it. (So either a subset of everything
else or only KDE should be installed).
Sometimes users demand it,
even on the slowest computers. (They will not stay long with
it normally, though). 

I'd be glad if someone could tell be how
one could at least get rid of those menus and place an normal
Debian menu there. (Or stop it always starting KDE-programs instead
of working ones, or if at least anyone could tell me on which
package to file a bugreport, that KDE-programs cannot parse
nontrivial \verb|/etc/printcap|).

\section{Browsers}

An large problems with the browsers is their disk cache. Even
only some hundreds of users with netscape, mozilla, konqueror
and phoenix using tens of megabytes for caching each, will often
outnumber the whole user data, bring users over their quotas
and cause other troubles.

Another thing that is nice to have is some default startpage
and bookmarks pointing to the local organisation. Or default
proxy settings.

\subsection{Mozilla}

Mozilla (and browsers based on this like phoenix) have a powerful
configuration system. This allows making default setting and
even changing them later without having to cope with the users
settings.

In theory, the lines like the following in the \verb|/etc/mozilla/prefs.js|
should all be needed to set start-page, language, disk-cache and proxy to defaults.
\begin{verbatim}
pref("browser.startup.homepage", "http://www.uni-freiburg.de");
pref("intl.accept_languages", "de, en");
pref("browser.cache.disk.capacity", 0);
pref("network.proxy.http", "proxy.uni-freiburg.de");
pref("network.proxy.http_port", 8080);
pref("network.proxy.type", 1);
\end{verbatim}

But while the startpage setting works in phoenix this way, it does not in
mozilla (if someone understands this _overwrite bit, please tell me, how to
set it there). The proxy settings will not taken, when there are some like
them \verb|/usr/lib/mozilla/defaults/prefi/all.js|, which sadly are in woody's
mozilla (see bug \#180875).

\subsection{Netscape}

I've not yet found something to globally place arbitrary configuration 
settings for this browser. (And the things made in \verb|/usr/bin/X11/netscape|
suggest this is not easily possible.

Of course one can place files to /etc/netscape4/defaults, but this will 
neither make it possible to change settings for users, that already started
the browser but did not change this setting.

Possible settings for the \verb|preferences.js| are:
\begin{verbatim}
user_pref("browser.cache.disk_cache_size", 0);
user_pref("browser.startup.homepage", "http://www.uni-freiburg.de");
user_pref("browser.startup.homepage_override", false);
\end{verbatim}

Things would be easier, if netscape could be removed altogether,
though it is currently the only one, that has build in java and
therefore does not require the ugly Java2 licence terms to get
java plugins.

\subsection{konqueror}

Anyone knows how to make default settings here? I've not yet
investigated this one yet.

\section{Sharing Configuration \emph{(still missing)}}

\dots cfengine \dots custom \verb|.deb|-packages \dots \dots ssh \dots rsync \dots

\section{Authentification \emph{(parts missing)}}

A lab will normaly have some policy on passwords. \verb|libpam_cracklib|
can be very helpful to enforce some demands on password's strength. 
And as the clients have to know, whom to let in and whom to deny, they
have to have access to the userdata and passwords in some way. But as
local situation and demands differ, the answers do so, too.

\subsection{NIS}

\dots disadvantages \dots no md5 \dots insecure \dots

\subsection{ldap}

\dots

\subsection{kerberos}

\dots

\subsection{others}

\dots ssh \dots nss-modules \dots cfengine \dots

\section{Home directories}

Having multiple clients causes the need to have user's files stored
central and accessed from the clients, i.e. to get \verb|/home|
to the clients.
People have different opinions about \verb|/var/mail|. Some
prefer it shared, too. Which allows to divide quota for 
mail and normal files. Other prefer changing user's mailboxes
to \verb|$HOME/.mail|, reducing troubles with locking and mountpoints.

\subsection{Autofs}

Using a automounter one can let the clients automatically mount
those subdirectories in \verb|/home|, that are accessed. This
can allow more fine grained permissions, which computer can
access which home-directories. And it makes it possible to
distribute home-directories over several servers or partitions
in a transparent way. (i.e. the user may only see by \verb|quota| or
\verb|df|, which server or partition his home-directory is stored on).

As this gives large flexibility, it has so many possible configurations
that none is suitable for so many people to include it here. There
are also no problems replacing a single \verb|/home| mountpoint over
nfs with this solution, so that one can wait with this until it is
needed.

For more documentation, see
\url{http://www.linux-consulting.com/Amd_AutoFS/autofs.html}.

\subsection{nfs}

Nfs is the oldest and fastest way to get \verb|/home| anywhere.
Though one should be away speed is bought by reliance on the
security of the local network. Nothing is encrypted and
only authentication is the ip-address. 

Currently the kernel-space nfs-server is quite better than
the user-space one and should be prefered in order to get locking
and higher reliability.

\subsection{openAFS}

OpenAFS seems to get more widespread in the last time. While
it does not rely that heavy on the security of the net, it is
also said to be quite difficult to set up. And its complex
access control lists and its own users and group handling are
of course a two edged sword.

\subsection{\dots}

And many many more\dots

\section{Different small things}

\subsection{xlock}

Configuring \verb|xlock| a default logout button can be a nice thing.
One also can configure the default modes when just typing xlock.
(Can be nice with instable xservers crashing with some modes).
Just place a \verb|/etc/X11/Xresources/XLock| with something like:
\begin{verbatim}
! number of minutes to logout button, -1 disables:
XLock*logoutButton: 15
! list of modes to take from when using random mode:
XLock*modelist: roll
! mode to take when nothing given:
XLock*mode: roll
\end{verbatim}

\subsection{dvips}
Something every environment has its own preference, is the question
whether \verb|dvips| should directly print or create a \verb|.ps|-file.
While I've heard about labs every one complaining, if they had to
enter an extra \verb|lpr|-command, in my area everyone is complaining
if it prints directly. That's just the \verb!o |lpr! line in 
\verb|/etc//texmf/dvips/config.ps| causing so much screams or wasted
paper.

\subsection{noflushd}
When local harddisks are to loud, noflushd (\url{http://noflushd.sourceforge.net/}) is said to help.

\section{Thanks}
I'm looking forward to receive more suggestions for additional 
things to include.

Thanks for already doing so to:
\begin{itemize}
\item Thomas Reifferscheid
\end{itemize}
\end{document}
