Webmin

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 with.

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 browser. 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 privileges.

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 security.

The first place where Webmin addresses the issue of security 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 create 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 problems HTTP 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 easily 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 particular module needs to make sure the right components are available, anyone using the module can plop it in like a Netscape plug-in.

When witting your own modules, there are two requirements that need to be followed. First, there needs to be an icon for that module, which is stored as <module>/images/icon.gif. Second, there is the <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 operating system 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 HTTP server, so 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 defaults to /etc/webmin.

The setup script also asks you your operating system, administrator's username and password, and other details about your existing configuration. Make sure that you choose 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 options, are be different among different operating systems. In addition, Webmin uses this information 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 appropriate 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 or no changes. In other cases, there are specific modules for different operating systems. For example, there are separate modules to configure NFS 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 scripts, text 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, hostname, 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 module, 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 the 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 dynamic. 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 default 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. Therefore, 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 directly 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 over 30 modules that form the base product. The third party modules typically provide functionality 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 managing 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 Calculator," which calculates the smallest possible network (i.e. netmask) for a given number of nodes.

User Comments: