Linux advocates regularly hear from fans of other operating systems
about how unstable Linux is. They say there is no support for Linux
and there are no applications. Some go so far as to claim Linux is
nothing more that a collection of programs creating by a small group
of hackers and inexperienced programmers.
The sheer number of Linux Internet servers attests to Linux's stability.
Even a quick search of any of a number of Linux sites leads to hundreds
of companies tht provide Linux support. The fact that major software
vendors like Corel and Oracle have already ported their products to Unix,
demonstrates that the applications are there.
Looking (glancing even) at some of the names responsible for the Linux
source code shows the quality of the people working on the various
components of Linux.
All of these aspects seem to show that these statements of Linux opponents are
blatantly untrue and demonstrate the ability of Linux to fit in well
in most any environment.
However, one place where Linux advocates often
loose the battle is when talking about graphical administration tools.
Especially when compared to Windows NT, Linux seems to be lagging behind.
Or so it seems.
In my mind, one of the of problems lies in the modularity of Linux. Although
Linux is technically just the kernel,
the name is now used to include the all
of the files, scripts and programs that are delivered with the various
distributions. However, no two distributions are identical and the tools
each provides vary (sometimes greatly). What this means is that the tools
are often not always easy to find, which leads some people to believe that
the tools do not exist. In some cases, the tools that are provided are
lacking in some and functionality.
The real truth is that powerful graphical administration tools are not lacking.
In fact, like many aspects of Linux, you actually have a choice of several
different packages. It is just a simple matter of what tools you like working
One tool that I have grown fond of recently is Webmin, developed by Jamie
Cameron. As you might be able to
tell from its name, Webmin is used to administer your system using a Web
That means, you can administer your system from any system with a web browser.
Webmin has taken this one step further by enabling you to administer a wide
range of systems, including several different Linux distributions, Solaris,
DEC OSF1, AIX, HP/UX, Irix and FreeBSD.
In essence, Webmin provides an mini-HTTP server (written in perl), which
creates the forms,
processes the input, and executes the commands. Because you need to be root to
make most of the administration changes to you system, Webmin needs to be able
to do that as well. This means that Webmin runs by default with super-user
Some people may wince at the thought of allowing root access through a web
browser. Although there are some potential security
holes, Webmin has a
number of different features which increase the overall
The first place where Webmin addresses the issue of
is by requiring an
extra username and password to access the server. By default this is the user
"admin" who has the same password as root. I would suggest that once you have
Webmin installed, you change both the account
name and the password.
Webmin also allows you to assign administration to different users. You can
additional users, to which you can then assign privileges to administer
different aspects of your system. For example, it is possible to define a user
(or users) who are allowed to just administer the printers, whereas
another user can administer just DNS.
This is done using the Webmin Users module,
which also gives you an overview of which users have which privileges.
One of the basic security
has is that the information is transferred
across your network
(or the Internet) in clear text.
That is, it is possible to
intercept the connection and read the administrator's password. Webmin can
protect against this by using the Secure Socket Layer (SSL), provided you have the
Perl SSL libraries installed on your system.
The figure above shows you the initial start up page for Webmin. As you can see the
interface is very simple, while at the same time being very practical. Behind
each of the buttons is a different administrative function which is contained
within a single Webmin module. One of the modules is used to administer the
modules themselves. Part of the administration is to remove or install the
modules as needed.
Because Webmin is modular, it is very easy to add your own modules, without the
need of changing any of the existing scripts. Although the developer of a
module needs to make sure the right components are available, anyone using the
can plop it in like a Netscape plug-in.
When witting your own modules, there are two requirements that need to be followed.
needs to be an icon
for that module, which is stored as <module>/images/icon.gif. Second, there is
<module>/module.info. In both cases, <module> is the name of the particular
module. The module.info
file is a set of parameters, which take the form parameter = value and contains
information about the
module, like its name, a description, what
it supports and so on.
By convention, the module, should produce a page which looks like the other
Webmin modules. This
can be done by using any programming language, such as C. However, one of the
design goals of
Webmin is to have it run unchanged on as many platforms as possible. Therefore,
if you write a module
in C, or the module uses any special programs, you will need to recompile on
each new machine. By convention modules are written in perl, which makes them
portable across platforms.
Webmin has a particular advantage for administrators who are either new to a
particular aspects of administering a system or new to Linux in general, in
that it already knows the syntax of the various configuration files. This
ensures that that syntax is correct. I also know experienced administrators
who use Webmin to setup the basic configuration and then edit the files by
hand to make any additional changes.
The first step is to get Webmin from the
Webmin home page, which is provided as a
gzipped tar archive. When you
unpack the archive it creates a sub-directory based on the version you have. For
example, the current version (as of this writing) might create the directory
/usr/local/webmin-0.73). This becomes the root directory for the
make sure you are extracting it in the right place before you go on.
Next change into the directory where the Webmin archive was extracted and run
the script setup.sh. This is the primary setup/configuration script. This asks
you a series
of questions such as where to put the configuration directory for Webmin, which
The setup script also asks you your operating system,
administrator's username and
password, and other details about your existing configuration. Make sure that
the right operating system
and, if available, the right version. This is extremely important
as the location of the scripts and program, which Webmin uses, as well as their
are be different among different operating systems. In addition, Webmin uses
to determine what modules it should it include. If you don't get this right,
Webmin won't work right.
During the setup process the script will also ask you if Webmin should be
started when the system boots. This adds the Webmin startup script to the
rc-directory (i.e. /etc/rc.d/rc2.d to start in run-level
2). In addition, if you have a
previous version of Webmin in the config directory, Webmin knows to upgrade it.
Part of the configuration process is to include the necessary modules. In many
cases, the same module can be used for multiple operating systems with little
no changes. In other cases, there are specific modules for different operating
systems. For example, there are separate modules to configure
on a number of
different systems. This is one reason why it is important to chose the correct
operating system during the setup.
If you look in the configuration directory, you will see that it contains a few
files and a large number of directories. Here you find the start
and stop scripts, which are called from the appropriate rc-script if you have
configured Webmin to start at boot
time. The file miniserv.conf contains the
configuration information for the mini-server, such as the port it uses,
whether SSL is used and so forth. Some of these values are assigned when you
first setup Webmin and they can be changed using Webmin itself.
If you look at the directory name,
it is fairly straightforward to figure out what each script
does, even if you have never used Webmin before. There is a directory for each
which contains the configuration
information for that module. These directories mirror the directories under the
server root directory, which contain all of the various perl scripts.
When you connect to the server using the defined port, the script index.cgi in
server root directory is
run. This checks for which modules are installed and displays the necessary
icons for each module. Since index.cgi is a script, the menu it presents is
Therefore, if a module is removed or added there is no need to edit any pages
to reflect change you make.
The icons you see are hyperlinks to their respective directories. Here too the
page is the script index.cgi, which once again builds the page as
appropriate based on the current configuration. These scripts are dynamic as well.
as I mentioned
previously, it is possible to edit the normal system configuration files by
hand and then re-load the configuration from Webmin. That means, there is no
conflict if one administrator
prefers to edit the files by hand and another
chooses to use Webmin. When you access the particular module, the appropriate
configuration files are read with any changes that have been made by hand.
With many of the modules, the first page is simply an overview of what can be
configured. For example, clicking on the Samba button brings you the page in
Figure 2. At the top is a list of the configured shares. Clicking on one
allows you to configure that particular share. At the bottom of the page are
the global configuration options.
There are two modules which I feel require special attention as they are not
related to configuring your system.
The first is the File Manager module which is just that. It is a Java applet,
which provides you a full-featured file manager which affects the files and
directories on the remote
system (the one being administered). This includes all of the expected features,
such as copy, delete, move, rename, cut, paste, and so forth. You even have the ability to
view text files.
Sometimes configuring the files through Webmin or even the File Manager is not
enough. For example, you may need to execute commands on the remote machine.
Webmin makes this a lot easier by providing you a Java telnet
client. This means you
don't need to start an external program and can do it right from Webmin. Note
that this is truly a telnet client,
so if root is denied telnet access, it
will also be denied through this Webmin applet.
As of this writing, there are 8 Webmin third party modules in addition to the
modules that form the base product. The third party modules typically provide
which is only necessary for user with specific applications, such as managing
the secure shell
SSH, configuring the SAP router/proxy, administering MiniVend shops, and or
Qmail or Zmail.
There is also a set of network
utilities from Tim Niemueller
(http://www.niemueller.de/webmin-modules/nettools/) that use the Webmin
interface to give you access to standard monitoring tools, such as ping,
traceroute and nslookup. It also provides an "IP subnet
calculates the smallest possible network
(i.e. netmask) for a given number of