Tuesday, December 11, 2007

Configuring Linux using a GUI

Many hardcore Linux users would shudder at the thought of configuring Linux network services using a GUI. A solid argument could be made that a GUI has no place being on a server in the first place. Servers are just supposed to sit quietly in the corner and do their job by themselves without user interaction. GUIs, by definition, are designed to make user interaction easier. A GUI adds needless overhead to a machine that’s not supposed to be interacting with users from its own console. Therefore, you should keep a GUI off of the server and configure services to run from a command line.

Although it’s practically sacrilegious, using a GUI for configuring servers can make sense in some cases. Primarily, using a GUI can help network administrators who aren’t familiar with Linux learn to set up network services faster. Many network administrators come from a Windows background, where practically everything is point-and-click. Although they need to earn new tools, the old Windows skills can more easily be translated to Linux through GUI tools.

Even for seasoned Linux users, trying to figure out the locations, layouts, and choices of configuration files that need to be maintained can be a chore. Some services can use three or four different .conf files. A slight error in the file can cause the service to fail. If the error was overlooked, a lot of time can be lost to troubleshooting. GUI tools that automatically find and populate the corresponding .conf files can end confusion and decrease the chance of errors.

GUI configuration options
Linux gives you several options when it comes to GUI-based network administration. Since the distribution we’ve chosen to use in this series revolves around SuSE 10.2, the major GUI configuration tool you’ll use is YaST. Other distributions have their own tools, but YaST is very well-organized, with an easy-to-follow arrangement.

YaST does a lot, but it doesn’t do it all. For those services YaST can’t control, we’re going to use Webmin, an add-on tool which allows you to control Linux services from inside of a Web browser. This means you have to learn how to use another tool, but it’s still easier than doing configurations from the command line.

A quick look around YaST
Although it is contrary to what many Linux admins would advise, I’m going to log into my SuSE 10.2 machine as root for this setup. I don’t do this often, but it saves me from having to enter the root password each time I perform an administration task.
Once you are done setting up these services, log out.

The first thing you’ll want to do is to select the Computer menu

The new GNOME 2.16 menu is quite a change from the usual cascading menu.

From the menu, select Control Center.
The Control Center is grouped in both Groups and Common Tasks.

From the Common Tasks section, select Administrator Settings to open the YaST
Admin Tool. You’ll see a screen similar to the figure below

It should be obvious that Network Services is your next destination.

Select Network Services to reveal a listing of the various Network Services that can
be configured from within YaST.
A nice collection of GUI tools to help you configure your Linux server.

Working with Webmin
There are a number of ways to go about the installation of Webmin, but the easiest and most consistent method of installing Webmin is from source. To get the source tarball, go to sourceforge site for the latest release. Once you have that file downloaded, you are going to untar the archive with the command tar xvzf webmin-1.310.tar.gz.

Now cd into the newly created webmin-1.310 directory. Inside this directory is the setup script to install Webmin. From within this directory, run the command ./setup.sh /var/www/html/webmin (where /var/www/html/webmin is the directory you wish to install
Webmin into).
Note: The /var/www/html/webmin directory does not have to exist, because the Webmin setup script will create it for you.

While the installation script is running, it is going to ask you the following:
  • Webmin configuration directory
  • The location at which Webmin will store logs
  • Path to Perl
  • Your server OS (Webmin tries to detect this)
  • The port Webmin will run on (defaults to 10,000)
  • The username and password to log in to Webmin
  • Your server’s hostname (Webmin tries to detect this)
  • SSL usage; should only prompt if Perl’s SSL libraries are installed (this author has not run Webmin under SSL)
  • Whether you want Webmin to start with system boot (highly recommended)
An interesting gotcha: During installation on Fedora Core 6, I was only asked for the installation directory. I was not prompted for a password, server hostname, server OS, port number, path to Perl, or SSL usage. Initially, it caused many an eyebrow lift when I logged into the site without an admin password.

I tried using the root username and password for my system; it worked. I attribute
this to Webmin being previously installed (but not run) via RPM. After the installation
script completed, it informed me:
Webmin has been installed and started successfully. Use your web browser to go to
http://localhost.localdomain:10000/
and login with the name and password you entered previously.
Because Webmin uses SSL for encryption only, the certificate it uses is not signed by one of the recognized CAs such as Verisign. When you first connect to the Webmin server, your browser will ask you if you want to accept the certificate presented, as it does not recognize the CA. Say yes.
The directory from the previous version of Webmin /usr/libexec/webmin Can now be safely deleted to free up disk space, assuming that all third-party modules have been copied to the new version.


The last section of the presented information was a good hint as to why I was not given the chance to set up an admin.
Now that Webmin is installed, it’s time to take a peek around and see what it has to offer.

Logging in
As stated above, you may have to log in with your root username and password.
Once logged in, you will be greeted with the Webmin main page.

Webmin’s main administration page.

From there, the first place to visit is the Webmin Configuration screen.

Here you can configure Webmin options.

Security configurations
From within the Webmin configuration screen, there are a number of items you will want to set up. Obviously, security for such a tool is high on the list. Select the IP Access Control link to set up a list of allowed or denied hosts; this prevents password guessing. You may have set up a rigid password that’s a mixture of alpha and numeric characters (as well as upper and lower case), but eventually someone’s going to crack it.

To add one more layer of security, set up this list so you allow only specific IP addresses to access the tool. Make sure you include any known safe IP address that will be needing access to the Webmin interface. All other hosts are denied.

Along this same line of security, select the Trusted Referrers link. From here, you can configure Webmin’s referrer-checking support, which ensures that malicious links from other sites cannot trick your browser into doing dangerous things with Webmin. In this section, there is a text area where you can enter trusted sites, a radio selection, and a check box. The radio selection allows you to choose to Enable Referrer Checking, and the check box allows you to select to Trust Links From Unknown Referrers.

From everything I’ve read and experienced, the default configuration for Webmin is pretty secure. For those working with mission-critical servers, however, it might befit you to uncheck the Trust Links From Unknown Referrers box, and configure some trusted Web sites.

The next step in securing Webmin is enabling the system to use SSL tunnels; this will allow remote login without passing unencrypted passwords across the ether. However, there are steps that must be taken before this feature can be used. First, OpenSSL must be installed; on many newer distributions, this is already taken care of. If not, then download the most recent OpenSSL from rpmfind and run the command (as root) rpm -ivhopenssl-XXX.rpm (where XXX is the release number).

With OpenSSL installed, you must install the Net::SSLeay Perl module. Download this module from the Net::SSLeay site, untar the archive with the command tar xvzf Net_SSLeay.pm-XXX.tar.gz (where XXX is the release number), change into the newly created Net::SSLeay directory, run the command perl Makefile.PL, and run the command make install.

To test the installation, run the command:perl -e ‘use Net::SSLeay’. If no errors are reported, you are good to go.

Select the SSL Encryption link from within the Webmin Configuration page, and you should see the following text, indicating SSL is working properly:
The host on which Webmin is running appears to have the SSLeay Perl module installed.

The first thing you want to verify is whether Enable SSL If Available? is checked. If it is, then you should now be able to log in to your Webmin site with the URL https://localhost.localdomain:10000/.

Your Webmin login is now encrypted.

Webmin users
Creating Webmin users is a very important task and should not be taken lightly. It’s necessary to grant users access to various aspects of your Webmin server (especially if your company’s server farm can not be administered by one person alone).

However, as in any good UNIX environment, users should be created and maintained wisely. To make this an easier task, I suggest creating groups to suit your needs. Say, for example, you have an IT team that needs access to the Webmin interface. From the Webmin main menu, select Webmin Users. Inside this page, Webmin Groups can be administered. Select Create New Webmin Group to create a new group.

From the list of options, select which modules the IT group needs to have access to, and press Save. Now, go to the Create Webmin User section, and create a new user. During this configuration, select the IT group from the Member Of Group list. There are some nice configuration options here, such as allowing users access to the site only on given days and times. Once you Save, the user will be created, and the user will inherit all of the options from the IT group.

0 comments: