Chapter 1. Introduction to Webmin

This chapter explains what Webmin is, why it was written, and what you can expect from this book.


1.1 What is Webmin?

Webmin is a program that simplifies the process of managing a Linux or UNIX system. Traditionally, you have needed to manually edit configuration files and run commands to create accounts, set up web servers, or manage email forwarding. Webmin now lets you perform these tasks through an easy-to-use web interface, and automatically updates all of the required configuration files for you. This makes the job of administering your system much easier.

Some of the things that you can do with Webmin include:

  • Creating, editing, and deleting UNIX login accounts on your system

  • Exporting files and directories to other systems with the NFS protocol

  • Setting up disk quotas to control how much space users can take up with their files

  • Installing, viewing, and removing software packages in RPM and other formats

  • Changing your system's IP address, DNS settings, and routing configuration

  • Setting up a firewall to protect your computer or give hosts on an internal LAN access to the Internet

  • Creating and configuring virtual web sites for the Apache Web server

  • Managing databases, tables, and fields in a MySQL or PostgreSQL database server

  • Sharing files with Windows systems by configuring Samba

These are just a few of the available functions. Webmin lets you configure almost all of the common services and popular servers on UNIX systems using a simple web interface. It protects you from the syntax errors and other mistakes that are often made when editing configuration files directly, and warns you before potentially dangerous actions.

Because Webmin is accessed though a web browser, you can log in to it from any system that is connected to yours through a network. There is absolutely no difference between running it locally and running it remotely, and it is much easier to use over the network than other graphical configuration programs.

Webmin has what is known as a modular design. This means that each of its functions is contained in a module that can generally be installed or removed independently from the rest of the program. Each module is responsible for managing some service or server, such as UNIX users, the Apache Web server, or software packages.

If you have been manually configuring your system up till now, any existing settings will be recognized by Webmin. It always reads the standard configuration files on your system and updates them directly, instead of using its own separate database. This means that you can freely mix Webmin, manual configuration, and other programs or scripts that work in the same way.

Even though this book is written for Linux users, Webmin can be used on many other flavors of UNIX as well, such as Solaris, FreeBSD, and HP/UX. One of its biggest strengths is its understanding of the differences between all these operating systems and the way it adjusts its user interface and behavior to fit your OS. This means that it can often hide the underlying differences between each UNIX variant and present a similar or identical interface no matter which one you are using.

Webmin on its own is not particularly useful though—it is only a configuration tool, so you must have programs installed for it to configure. For example, the Apache module requires that the actual Apache Web server be installed. Fortunately, all of the services and servers that Webmin manages are either included with most Linux distributions as standard, or can be freely downloaded and installed.


1.2 Who Should Use Webmin?

Webmin was written for use by people who have some Linux experience but are not familiar with the intricacies of system administration. Even though it makes the process of creating UNIX users or managing the Squid proxy server easy, you must first have some idea of what a UNIX account is and what Squid does. The average Webmin user is probably someone running it on their Linux system at home or on a company network.

The program assumes that you are familiar with basic TCP/IP networking concepts, such as IP addresses, DNS servers, and hostnames. It also assumes that the user understands the layout of the UNIX filesystem, what users and groups are, and where user files are located. If you use Webmin to manage a server like Apache or Sendmail, you should first have an idea of what they can do and what kind of configuration you want completed.

Webmin itself runs with full UNIX root privileges, which means that it can edit any file and run any command on your system. This means that it is quite possible to delete all of the files on your system or make it un-bootable if you make a mistake when using the program, especially if you are configuring something that you don't understand. Even though Webmin will usually warn you before performing some potentially dangerous action, there is still plenty of scope for causing damage.

Even though it can be used on a system with no connection to the Internet, Webmin does benefit if your Linux system is on a network. It can download new software packages, Perl modules, or even new versions of Webmin for you, if connected. A permanent high-speed connection is best, but even a dial-up connection is good enough for most purposes.

Because Webmin runs with root privileges, you must be able to log in to your system as root to install and start it. This means that it cannot be used on a system on which you have only a normal UNIX account, such as a virtual web server that is shared with other people. You might, however, be able to get your system administrator to install and configure it for you.

If you are already an experienced UNIX system administrator, Webmin may not feel like the tool for you because using it is generally slower than directly editing configuration files and running commands. However, even the experts can benefit from its automatic syntax checking and the actions that it can perform automatically.

It is also possible to give different people different levels of access to Webmin, so that an experienced administrator can use it to safely delegate responsibility to less-skilled subordinates. For example, you might want someone to be only able to manage the BIND DNS server and nothing else, while giving yourself full access to the system and all of Webmin's functions.


1.3 How and Why Was it Developed?

Webmin, the program, was designed and created by me, Jamie Cameron—the author of this book. I started it back in 1997 and released the first version (0.1) in October of that year. Since that time, its user interface, features, and appearance have changed dramatically, and almost all of the code has been re-written. The basic concept of a web-based administration tool, however, has been the same since that very first release.

I started writing it when I was the administrator for a system running a DNS server and was spending a lot of time updating the server's configuration files to add new host records requested by users. Giving them the root password was not an option—they did not have the experience to properly edit the zone files and re-start the server. The solution was a simple web interface that would display existing DNS records and allow them to be edited, created, and deleted. Users could then safely be given access to this interface to make the changes that they needed.

DNS management was just the start though. Once I saw the possibilities for simplifying the configuration of a UNIX system though a web interface, I started adding other features to the program and putting them into modules. Next came modules for UNIX users, Samba, mounting filesystems, NFS, and Cron jobs. I thought up the name Webmin, made it available for anyone to download, and announced it on a few mailing lists. The initial feedback was good, so I kept on writing.

Over the years, the program has gone through three different user interfaces, grown to 83 modules, added support for non-English languages, provided advanced access control, included lots more operating systems, and offered many other features. The Linux distribution companies Caldera and MSC.Linux have supported the project financially, and many users have made contributions of code patches, modules, translations, and suggestions. In addition to the standard modules, over 100 have been written by other people and are available to be added to Webmin on your system once you have installed the program.


1.4 What is this Book About?

This book explains how to install Webmin, how to use almost all of its modules, and how to write your own. The book focuses on the standard modules that come with the Webmin package, not those written by other people. Not all of the 83 standard modules are covered, however, as some are not very useful to the average administrator.

Although this book is written primarily for Linux users, the program behaves almost identically on other operating systems. Each chapter also lists any differences between Linux and other UNIX variants in their "Other Operating Systems" sections. This means that it is still very useful if you are running Webmin on FreeBSD, Solaris, MacOS X, or some other variety of UNIX.

Each chapter in the book covers the use of Webmin for managing a particular service or server, such as NFS exports, Sendmail, or the ProFTPD FTP server. Most chapters only discuss a single module, but some cover two or three that have similar or related purposes. Each chapter is pretty much self-contained, so there is no need to read through the entire book in sequence if you just want to find out how to configure one server. Chapters 2, 3, and possibly Chapter 52, however, should be read first as they explain how to install Webmin, how to secure it, and how to limit what other users can do with a module, respectively.

Each chapter is broken up into sections, and most sections explain how to perform a specific task. A section will generally contain an introduction to the task explaining why you might want to do it, followed by a list of steps to follow in the Webmin user interface to carry it out. At the beginning of each chapter are sections that introduce the server being configured and the concepts behind it, and list the underlying configuration files that get modified when you use the module covered in that chapter.

Chapters 55 to 60 cover the development of your own Webmin modules and themes, and therefore have a different style. The average user does not need to read them, but if you have an idea for a module that is not currently available, they provide all the information that you need to implement it.


1.5 Who Should Read this Book?

This book should be read by anyone wanting to use Webmin to manage their Linux or UNIX systems. It was written for readers with a basic knowledge of UNIX commands and concepts—people who have installed Linux and have used it for a while.

Each chapter starts with an introduction to the service being configured so that readers have some idea of what the DNS protocol is for or how a firewall works. Even so, a complete novice should not try to set up a server until he understands how it works and what he wants it to do. The best way to learn is to use the service on some other system as a user. For example, if you have used a proxy server before on some other network, then you will have the background knowledge needed to use this book to set up the Squid proxy on your own system.

The development chapters, on the other hand, are written for someone who already understands how to write Perl scripts and CGI programs on a UNIX system. This means that they are more complex than the rest of the book, and assume some knowledge of programming and manual system administration. They can be skipped, however, if you just want to learn how to use Webmin rather than how to extend it.


1.6 Conventions Used in this Book

The following special text styles are used in this book:

Bold Used for text that appears in Webmin itself, such as error messages, icon names, buttons, and field labels.

Fixed width This style is used for the names of shell commands, UNIX users, directories and files. Also used for text in configuration files, program code and API functions.

Italics Used to indicate example input entered by the user into Webmin, example commands, or directories. Also used in Chapter 60 "The Webmin API" for the names of parameters to functions.


1.7 Acknowledgments

This book could not have been written without the support of Jill Harry and the others at Prentice Hall, Robert Kern for suggesting the idea, my wife Foong Ching for her constant support, and all the members of the Webmin mailing list for their ideas and suggestions over the years.


Chapter 2. Installing Webmin

This chapter explains how to download the appropriate Webmin package for your operating system, how to install it, and what you will see after logging in for the first time.


2.1 Downloading Webmin for Your System

The latest version of Webmin can always be downloaded from www.webmin.com/. At the time of writing, the latest release was Version 1.100, but new versions come out frequently. All of the instructions below, however, will use Version 1.100 for the filenames. If you download a later release, the version number in all the filenames and paths will have changed.

Some Linux distributions, such as Mandrake and Caldera, include Webmin as a standard feature, so it may already be installed on your system. The version that they include, however, may not be the latest official version that is available for download. If you are happy with the release that you already have, however, you can skip this chapter.

Other Linux distributions, like Debian and Gentoo, include Webmin as a package that can be downloaded and installed automatically. On Debian, the command apt-get install webmin will install the latest version available in the Debian APT repository. This can sometimes be a few versions behind the newest official release, however, so you may want to download from www.webmin.com/ instead. On Gentoo Linux, the command emerge webmin will install the latest version from the Gentoo Portage repository, which should be the same as the newest official release.

If you are upgrading from an older Webmin version, the process is exactly the same as installing for the first time. Any changes that you have made to the configuration of Webmin itself, or to other servers like Apache or Sendmail, will be left unharmed by the upgrade.

While Webmin supports a wide variety of UNIX variants, it does not cover all of them. Because it deals with system configuration files that differ in location and format between different kinds of UNIX operating systems, it has been written to behave differently depending on the type of operating system that it is running on. To see a complete list of supported operating systems, visit the web page www.webmin.com/support.html. If your operating system is not on the list, you cannot use Webmin.

Before downloading Webmin for installation on your system, you have to choose a package format in which to download it. The available formats are:

RPM If you are running Red Hat, SuSE, Mandrake, Caldera, MSC, or any other Linux distribution which supports the RPM packaging format, then the RPM package is your best choice.

tar.gz The tar.gz packaged version of Webmin will work on any operating system, but is slightly harder to install than the RPM and Solaris packages.

Solaris package If you are running Solaris on Sparc or x86, then this is the package format for you.

For instructions on installing your chosen package type, see Section 2.2 "Installing the RPM Package" below.


2.2 Installing the RPM Package

In the top-right corner of every Webmin website page is a link for the RPM package. A link can also be found on the page www.webmin.com/download.html. Once you have downloaded it, you should have a file on your Linux system named something like webmin-1.1.100-1.noarch.rpm. To install, run the following command as root:

rpm –U webmin-1.1.100-1.noarch.rpm

The RPM install can only fail if you do not have Perl installed, or if Webmin cannot identify your operating system. If that occurs and your Linux distribution is on the list of supported operating systems, you should install the tar.gz version instead. Because all Linux distributions are slightly different, the Webmin install process has to positively identify the exact distribution and version that you are running, such as Red Hat 7.3. This can fail if one of the files that contain the distribution name (such as /etc/issue) has been modified.

Assuming the RPM install successfully completes, you will be able to login to Webmin immediately. Open a web browser, and go to the URL http://localhost:10000/ if you are running the browser on the same Linux system on which Webmin was installed, or http://your-systems-hostname:10000/ if the browser is being run on another PC. Either way, a web form will appear prompting for a username and password, as shown in Figure 2.1.

Figure 2.1. The Webmin login page.

You should be able to login as root, using the same password as the root UNIX user on your Linux system. If the password is changed using the command-line passwd command or the Users and Groups module, your Webmin password will change too.

If the OpenSSL library and the Net::SSLeay Perl module have already been installed on your system, Webmin will automatically start in SSL mode. This means that you should use a URL starting with https:// instead of http:// to connect to it. Attempting to connect with the non-SSL URL will only bring up a page with a link to the https:// URL on it, which you should follow to log in.


2.3 Installing the tar.gz Package

In the top-right corner of every Webmin website page there is a link for the tar.gz package. A link can also be found on the page www.webmin.com/download.html. Once you have downloaded it, you should have a file on your system named something like webmin-1.1.100.tar.gz. To install the package, follow these steps:

  1. Login to your system as root.

  2. Choose a directory under which you want Webmin installed. This is usually /usr/local, but can be /opt or any other location that you prefer. The instructions below will use /usr/local for simplicity.

  3. Copy the webmin-1.1.100.tar.gz file to the /usr/local directory.

  4. Run the following commands to uncompress and extract the tar.gz file and run the following setup script:

    cd /usr/local
gunzip webmin-1.1.100.tar.gz
tar xf webmin-1.1.100.tar
cd webmin-1.1.100
./setup.sh

  5. After running the setup.sh script, you will be asked a series of questions that control the installation process. The questions and their meanings are:

    Config file directory [/etc/webmin] This is the directory in which Webmin will store all of its own configuration files. It is best just to hit Enter to accept the default of /etc/webmin. If this directory already exists from an older version of Webmin that you are upgrading from, this is the only question that will be asked.

    Log file directory [/var/webmin] This is the directory in which Webmin's log and process ID files will be stored. Just hit Enter to accept the default of /var/webmin for this one as well.

    Full path to perl This is the location of the Perl executable on your system. If it is at /usr/bin/perl or /usr/local/bin/perl, then you can just type enter to accept the default. Otherwise, you must enter the full path to the Perl interpreter.

    Operating system This question will only be asked if Webmin cannot automatically identify your operating system. You must enter the number next to one of the operating system names that appears in the list before the question.

    Version Like the question above, this will only be asked if Webmin cannot identify your operating system. Again, you must enter the number next to one of the version numbers displayed.

    Web server port (default 10000) This is the HTTP port on which Webmin listens. It is best to stick with the default, unless you are running some other network server on port 10000.

    Login name (default admin) This is asking for the username that you will use for logging into Webmin. admin is the traditional username, but anything can be used.

    Login password This is the password that must be entered along with the username. You must enter this twice, to verify that you haven't accidentally made a mistake.

    Use SSL (y/n) This question will only be asked if you have already installed the OpenSSL and Net::SSLeay libraries on your system, as explained in Chapter 3. If you enter y, Webmin will use SSL right from the start. If you enter n now, however, you can still turn it on later.

    Start Webmin at boot time (y/n) This question controls whether Webmin will be starting when your system boots up, which means that you do not have to re-start it yourself manually every time you reboot. If you want to have it started at boot, just enter y. If not, enter n.

  6. After all the questions have been answered, the install process will finish, and a message showing the URL that you can use to log in will appear. You can now delete the old webmin-1.1.100.tar file if you no longer need it. Do not delete the /usr/local/webmin-1.1.100 directory that was created when the tar file was extracted, however. This contains all the scripts that Webmin needs to run.

Now that the package has been installed, you can open a web browser, and go to the URL http://localhost:10000/ if you are running the browser on the same Linux system on which Webmin was installed, or http://your-systems-hostname:10000/ if the browser is being run on another PC. Either way, a web form will appear prompting for a username and password as shown in Figure 2.1. Log in using the username and password that you chose before in response to the Login name and Login password questions.

If you answered yes to the SSL question, you should use a URL starting with https:// instead of http:// to connect. If Webmin detects a non-SSL connection when it is in SSL mode, it will display a page with a link to the correct URL.


2.4 Installing the Solaris Package

The Solaris version of Webmin is only available for download from www.webmin.com/download.html. Once you have downloaded it, you should have a file on your Solaris system named something like webmin-1.1.100-1.pkg.gz. To install, run the following commands as root:

gunzip webmin-1.1.100.pkg.gz
pkgadd –d webmin-1.1.100.pkg.gz WSwebmin

The Solaris package can only fail if you already have Webmin installed, or if you do not have the Perl executable at /usr/local/bin/perl. If you have Perl installed somewhere else on your system, you should create a symbolic link from /usr/local/bin/perl to the real location.

Assuming the Solaris package install completes successfully, you will be able to log in to Webmin immediately. Open a web browser, and go to the URL http://localhost:10000/ if you are running the browser on the same Linux system on which Webmin was installed, or http://your-systems-hostname:10000/ if the browser is being run on another PC. Either way, a web form will appear prompting for a username and password, as shown in Figure 2.1.

You should be able to login as root, using the same password as the root UNIX user on your Solaris system. If you change the UNIX root password down the road, however, the Webmin root user will not change. This is because the package install just copies the current password from the /etc/shadow file.


2.5 The Webmin User Interface

Assuming the installation process and login were successful, your browser should show the Webmin main menu with the Webmin category selected, as shown in Figure 2.2. You can switch to other categories by clicking on the icons along the top of the page, such as System, Servers, or Others. Every module is a member of one category, and a table of icons for each module in the selected category will appear in the body of the page. To enter a module, just click on its icon.

Figure 2.2. Modules in the Webmin category.

To log out of Webmin, just click on the Logout link that appears in the top-right corner of every page. To send feedback to the author (that's me), click on the Feedback link that is next to the Logout button. To visit www.webmin.com/, click on the Webmin logo in the top-left corner of any page.

If you are using a different theme, the user interface will appear different to the screen, as shown in Figure 2.2. Some versions of Webmin that come with Linux distributions use a different theme by default, such as Mandrake and Caldera. The main menu, however, will still show categories and modules, maybe using different sized icons in a different on-screen layout. All the screen shots in this book were captured using the default theme, so you may want to switch to it now (see Chapter 52 for instructions on how to change the current theme).

All Webmin modules have a common layout and user interface, in order to make navigation easier. When you click on a module icon from the main menu, the main page of the module will appear. For example, Figure 2.3 shows the main page of the Disk Quotas module.

Figure 2.3. The Disk Quotas module main page.

At the top are the category icons that appear on every Webmin page, so that you can easily switch to another module. Below are links for Help, Module Config, and Search Docs. Not every module will display all of these links, but where they appear they have common purposes:

Help This link opens a pop-up window containing an overview of the module and the options available on the main page.

Module Config This link displays a form containing configurable options for the current module. See Figure 2.4 for an example of the options available in the Disk Quotas module. Each module has its own set of options, but all use a similar interface for editing them. In most cases, you will not need to change any of these configuration options for normal use of a module.

Figure 2.4. The configuration page for the Disk Quotas module.

Search Docs This link displays a list of UNIX man pages, package documentation, HOWTO files, and websites related to the server or program that the module is configuring. This can be useful for finding out additional information about the underlying configuration files and commands that Webmin is using.

Other pages below the first page in each module also have a common layout. Figure 2.5 shows a sample page from the Disk Quotas module. Below the list of category icons is a link labeled Module Index, which will always return you to the module's main page. This can be found on almost every page of every module. Next to it is another Help link that pops up a window displaying information on the current page. Not all pages have online help, so this link will not always appear. Finally, at the bottom of the page is a link, whose label starts with Return to, that will take you back one level in the module's hierarchy of pages.

Figure 2.5. An example page from the Disk Quotas module.

    [ Team LiB ]


2.6 Uninstalling Webmin

If, for some unimaginable reason, you want to remove Webmin from your system, you can just log in as root and run the command:

/etc/webmin/uninstall.sh

This command will ask if you are sure you want to uninstall, and if you do it will delete the Webmin scripts and configuration directories. This means that any configuration you have done to Webmin itself, such as changing IP access control, switching themes, or creating new Webmin users will be lost. There will, however, be no harm done to the configuration of other servers such as Apache or Sendmail, even if they were done using Webmin.


2.7 Summary

After reading this chapter, you should understand how to install Webmin for the first time on a server, or upgrade an existing installation to the latest release. You should also know the differences between the three package formats, and which one is suitable for your operating system. Because this entire book is about Webmin, it should definitely be installed before reading on!


Chapter 3. Securing Your Webmin Server

This chapter covers the necessary steps for adding additional security to Webmin on your system once it has been installed. It explains both IP address restrictions and the use of SSL.


3.1 Network Security

Unless you are running Webmin on a system that is never connected to any other network, it is a wise idea to restrict which client network addresses are allowed to log in. Because Webmin is so powerful, anyone who manages to log in will have total control over your system—as though they had root shell access. Even though a username and password is always required to log in, it is always good to have an additional layer of security in case an attacker guesses (or somehow discovers) your password. IP access control also protects you from any bugs in Webmin that may show up in future that will allow an attacker to log in without a password—some older releases have had just this problem.

To restrict the IP addresses and networks from which Webmin will accept connections, follow these steps:

  1. In the Webmin category, click on the icon for the Webmin Configuration module.

  2. Click on the icon for IP Access Control. The form shown in Figure 3.1 will appear for restricting client IP addresses.

    Figure 3.1. The IP access control form.

  3. Select the option Only allow from listed addresses, and enter the IP addresses or hostnames of client systems in the text box from which you will allow access. If you want to allow access from an entire IP network, enter the address of the network with 0 for the final octet. For example, if you wanted to allow all clients with IP addresses from 192.168.1.0 up to 192.168.0.255, you would enter 192.168.1.0.

    Networks can also be entered in the standard network/netmask format, like 192.168.1.0/255.255.255.0. You can also grant access from an entire domain by entering a wildcard hostname like *.foo.com, assuming that reverse IP address resolution has been set up for that domain.

  4. When done, click the Save button to apply your changes. Webmin will warn you if the restrictions will prevent the client system on which you are currently running your browser from logging in so you do not accidentally lock yourself out!


3.2 SSL Encryption

If you are accessing your Webmin server over an untrusted network such as the Internet, you should be aware that, by default, an attacker can capture your login and password by listening in on network traffic. This is particularly easy if you are using a non-switched Ethernet network shared by people that you do not fully trust, such as those in offices or universities.

Fortunately there is a solution that is relatively easy to set up—switching Webmin to use SSL so that all network traffic between your web browser and the server is encrypted. The RPM package of Webmin will run in SSL mode by default if the OpenSSL library and Net::SSLeay Perl module are installed. Most systems, however, do not meet these requirements so you will need to follow the steps below to enable SSL:

  1. Install the OpenSSL library, if you do not already have it. Most recent Linux distributions will include it as standard, but you may have to install it from your distribution CD. If there are separate packages for openssl and openssl-devel, make sure both are installed. If your operating system does not come with OpenSSL, you can download it from www.openssl.org/ instead.

  2. Install the Net::SSLeay Perl module, if it is not already installed. If your system is connected to the Internet, the easiest way to do this is to enter the Perl Modules module of Webmin (under the Others category), enter Net::SSLeay into the From CPAN field and click the Install button.

    After the Perl module has finished downloading, click on Continue with install to have Webmin automatically compile and install it.

  3. Once both are installed, go to the Webmin Configuration module and click on SSL Encryption. The form shown in Figure 3.2 will appear.

    Figure 3.2. The SSL activation form.

  4. On the top part of the page, change the Enable SSL if available? option to Yes, and click Save. If all goes well, Webmin will be switched to SSL mode and your browser will connect to it securely.

  5. If this is the first time you have connected to Webmin in SSL mode, your browser will display a warning about the certificate being invalid. For now, you can ignore this warning and choose to accept the certificate. For more details, see Section 3.3 "Requesting a Valid SSL Certificate".

  6. From now on, when logging into Webmin you must use a URL starting with https:// instead of just http://. Once in SSL mode, it will no longer accept insecure connections.

  7. Go back to the SSL Encryption page and scroll down to the second form. If a warning starting with Because you are currently using the default Webmin SSL key… is displayed, you definitely should continue following these steps to create your own private SSL certificate and key. If, however, it does not appear, then a private key was created at installation time and there is no need to go on reading.

  8. If your system is always accessed using the same hostname in the URL, enter it into the Server name in URL field, such as www.example.com. This will cause the generated certificate to be associated only with that hostname. Otherwise select Any hostname to allow the certificate to be used with any URL hostname. This is more convenient, but slightly less secure.

  9. In the Email address field, enter your email address—such as joe@example.com.

  10. If appropriate, fill in the Department field with the name of the department or group within the organization to which this system belongs, such as Network Engineering. This can be left blank if inappropriate, such as on a home system.

  11. In the Organization field, enter the name of the company or organization that owns this system, such as Foo Corporation. Again, this can be left blank if it makes no sense.

  12. In the State field, enter the name of the state that your system is in, such as California.

  13. In the Country code field, enter the two-letter code for the country in which the system resides, such as US.

  14. Leave the Write key to file field unchanged, and the Use new key immediately field set to Yes.

  15. Hit the Create Now button to generate a new key and certificate, write them to /etc/webmin/miniserv.pem and immediately activate them. Your browser will probably prompt you again to accept the new certificate.

Older versions of Webmin just used a fixed SSL key that was included as part of the package. This, however, was completely useless for securing network traffic because anyone with a copy of that key can decrypt the data that is supposedly protected with SSL! For this reason, recent Webmin versions create a new private key at installation time if possible, and warn you if the old fixed SSL key is being used.


3.3 Requesting a Valid SSL Certificate

If you want to use a valid SSL certificate and do not have one for your hostname, it is possible to generate one using the openssl command and a certificate authority. A valid certificate is one that is recognized by all browsers because it was signed by a recognized authority. Those created by Webmin itself, by following the steps in Section 3.2 "SSL Encryption", do not meet this criteria and will trigger a warning in all browsers when they connect to the Webmin server.

Unfortunately, certificate authorities charge money for signing and verifying that the owner of the server in the hostname actually matches the company details in the certificate. For this reason, most people do not bother to use a signed certificate with Webmin, as there is no real advantage in security once you have accepted an unsigned certificate into your browser for the first time.

If you do want to obtain a real valid certificate, however, the steps to follow are:

  1. At the shell prompt, run the openssl genrsa -out key.pem 1024 command. This will create the key.pem file, which is your private key.

  2. Run the openssl req -new -key key.pem -out req.pem command. When it asks for the common name, be sure to enter the full hostname of your server as used in the URL, like www.yourserver.com. This will create the req.pem file, which is the certificate signing request (CSR).

  3. Send the CSR to your certificate authority by whatever method they use. They should send you back a file that starts with —BEGIN CERTIFICATE— which can be put in the cert.pem file.

  4. In Webmin, enter the Webmin Configuration module and click on SSL Encryption.

  5. In the SSL Encryption form (shown in Figure 3.2), enter the path to your key.pem file into the Private key file field, and the path to your cert.pem file into the Certificate file field.

  6. Click the Save button to switch to the new certificate.

From now on, your browser should no longer display a warning when connecting to Webmin in SSL mode.


3.4 Summary

Securing your Webmin server to prevent unauthorized access is critical, as there are many potential attackers on the Internet who would love to use it to take over your system. This chapter has covered the two different types of security configuration (IP access control and SSL) that should be performed where possible. Because some versions of Webmin have had remotely exploitable security holes, it is also advisable to always upgrade to the latest version as soon as it becomes available to ensure your system's security.


Chapter 4. Users and Groups

This chapter is devoted to the Users and Groups module, which allows you to create and manage UNIX user accounts and UNIX groups.


4.1 Introduction to UNIX Users and Groups

On Linux and other UNIX operating systems, a user is a person who can login to the system via SSH, telnet, FTP or at the console. Users can also receive email and own files on the server's local filesystems. Each user has a login name, a password, and a home directory in which all its files are stored. Users also have several additional attributes, such as a real name, shell (the program that is run when the user logs in), and expiry date.

Each user is a member of at least one group, called a primary group. In addition, a user can be a member of an unlimited number of secondary groups. Group membership can be used to control the files that a user can read and edit. For example, if two users are working on the same project you might put them in the same group so they can both edit a particular file that other users cannot access.

Every system will have several standard user accounts like root and nobody that are created when the system is installed—although most of these (except for root) cannot be used to login. If your server will be used by more than one person, you will need to create an additional user account for each person to keep their files and email separate. Even if you are the only person who uses your machine, it is a good idea to create a user account for yourself that you use to login with instead of using the root account.

Depending on your operating system, user and group information will be stored in different files in the /etc directory. On modern versions of Linux, /etc/passwd and /etc/shadow are used to store user details, and /etc/group for group details. The Users and Groups module works by directly editing those files, not by calling any external programs or functions. This means that if you are using NIS or storing users in an LDAP server, this module is not for you.


4.2 The Users and Groups Module

The Webmin module Users and Groups that is found under the System category (as shown in Figure 4.1) can be used to create, edit, and delete all the UNIX users and groups on your system. You should always be careful when using this module to edit existing system users like root and daemon because changing or deleting them could stop your system from working. Some users have their home directory set to / (the root directory). Deleting such a user would cause all the files on your system to be deleted!

Figure 4.1. The Users and Groups module icon.

In addition to managing the UNIX users on your system, this module can also affect user settings in other modules. For example, Samba has its own list of users and passwords that should be kept in sync with the UNIX password list. Webmin can handle this for you automatically using the other modules option that appears on the user creation, editing, and deletion forms. You must, however, enable this in every other module that you want automatically updated. The module also has options for synchronizing UNIX groups in a similar way, such as with Samba groups. However, since this feature only works with Samba 3.0, which is still under development, it is not covered in this chapter.

Once you enter the module, the main page lists all the users that currently exist on your system in one table (Figure 4.2), and all the groups in another (Figure 4.3). If there are too many users or groups to sensibly display in a table, then a small form allowing you to search for a user or group will be displayed instead.

Figure 4.2. List of existing users.

Figure 4.3. List of existing groups.

    [ Team LiB ]


4.3 Creating a New User

To create a new UNIX user, complete the following steps:

  1. Click on the Create a new user link above or below the table of existing users. A form for entering the details of the new user will appear, as shown in Figure 4.4.

    Figure 4.4. The user creation form.

  2. At this point you have to decide on a username for the new user, which should be something simple without spaces in it—like jcameron or jamie—and not used by any other user. If your server is receiving email, the username determines the part of the user's email address to the left of the @. Enter your choice in the Username field.

  3. The User ID field should generally be left unchanged, as it is worked out for you by Webmin. If you set it to the same user ID as another user, they will be able to access each other's files. This is generally not a good idea.

  4. In the Real name field, you should enter the user's full name, such as Jamie Cameron.

  5. Every user has a home directory, in which the user stores his personal documents and preference files. In the Home directory field, you should enter a directory that does not exist yet, such as /home/jcameron. When the user is created, this directory will be created and its ownership granted to the new user.

    If Webmin on your system offers an Automatic option for the home directory, it is generally best to stick with that.

  6. The user's shell is a program that is run when he makes a text mode login of some kind (via SSH, for example), or opens a shell prompt after logging in graphically at the console. The shell is responsible for running the commands that you type (such as ls and cat), running scripts on login and logout, and providing an interface for command editing. Shells like bash and tcsh are easier for users to use, because they allow the up and down arrows to be used to scroll through previous commands, and the tab key to auto-complete commands and filenames.

    In some cases, you might not want a user to be able to make a shell login at all, as in when the user is only meant to be able to read and send email. In that case, his shell should be set to /bin/false, which is a program that does nothing and exits immediately.

    You should select whatever shell you want the user to have from the list in the Shell field. If your choice is not on the list, select the Other option and enter the path to the shell in the field below.

  7. For the Password field, you have four choices:

    No password required The user can login without needing to enter any password.

    No login allowed The user can never login.

    Normal password You get to enter the user's password.

    Pre-encrypted password You must enter a password that is already encrypted, such as one taken from the /etc/shadow file on another system.

    Generally you will want to use the Normal password option. Note that on many operating systems, only the first eight characters of the password are actually used.

  8. On most systems, a set of inputs under the heading Password options will be available. The first of these is the Expiry date—if you want the user to be unable to login after a particular date, fill in this field.

  9. The Minimum days field is the number of days after the user is created or the password is last changed that the user must wait before changing it again. Leave it blank to allow changing as soon as the user wants.

  10. The Maximum days field is the number of days after the user is created or the password is last changed that the password will expire and need to be changed. A user with this option set will be forced to change his password periodically, which is good for system security. Leave it blank to prevent the password from ever expiring.

  11. The Warning days field is the number of days before the password expiry date that the user will be warned at login that his password is about to expire. If left blank, the user will not know that his account has expired until he tries to log in and is forced to choose a new password.

  12. The Inactive days field is the number of days after the password expires that the entire account will be disabled if the user has not chosen a new password. If left empty, the account will never expire.

  13. For the Primary group, either select an existing group or enter the name of a new one that Webmin will create for you.

  14. If you want the user to be a member of more than one group, select some of the groups from the Secondary group list.

  15. If you want the user's home directory to be created, select the Create home directory? option. If the directory does not already exist, you should select this as well as Copy files to home directory? so that the user gets a basic set of preference files like .profile and Desktop.

  16. To create the user in other modules that you have configured for such action, select Create user in other modules? It is possible to set up the Samba module to automatically create a user in its user list, and the MySQL module to create a new database user, among others.

  17. To create the user, click the Create button. After a short delay, you will be returned to the list of existing users, which should include your newly created user.

Once the Create button has been clicked, the new user will be able to login via SSH, telnet, or whatever other services you have set up


4.4 Editing an Existing User

You can change any of the details of any user that already exists on your system by following these steps:

  1. Click on the user you want to edit from the existing list. A form containing all the details of the user will appear, as shown in Figure 4.5.

    Figure 4.5. The user editing form.

  2. Change any of the details that you want to modify, including the username. The fields have the same meanings as described inSection 4.3 "Creating a New User".

  3. If you have modified the User ID or changed the Primary group, files owned by the user may need to be updated to use the new IDs. The options at the bottom of the page labeled Change user ID on files? and Change group ID on files? control which directories will be searched for files with the old IDs.

  4. If you have changed the user's home directory, you can have Webmin rename it to the new path. However, if the new home directory already exists, this may not always be what you want. The Move home directory if changed? option determines if it is moved or not.

  5. To have the user updated in other modules where this has been set up, select Modify user in other modules? If you are changing the username, this will also rename the user's Sendmail mail file and Cron jobs.

  6. Click the Save button to have Webmin update the user. Once it is complete, you will be returned to the lists of users and groups.


4.5 Deleting a User

You should always be careful when deleting a user, as important files in the user's home directory may be lost. It is generally never a good idea to delete any of the users that are created when your system is first installed—especially root! Even normal users that you have created can be disabled by editing the user and setting the password option to No login allowed.

If you still want to go ahead and delete a user, follow these steps:

  1. Click on the user you want to edit from the existing list. A form containing all the details of the user will appear, as shown in Figure 4.5.

  2. Click the Delete button at the bottom of the page. This will bring up a form asking you to confirm the deletion, with buttons to delete just the user or his home directory as well. The amount of disk space used by the user's home directory will be shown.

  3. Select the Delete user in other modules? option if you want the user to be deleted from other modules in which deletion has been set up. Any Cron jobs belonging to the user will be deleted, as will his Sendmail mail file.

  4. Click either the Delete User or Delete User and Home Directory button to delete the user. A page showing the progress of the deletion will be displayed while it is taking place.


4.6 Creating a New Group

A new UNIX group can be added by following these steps:

  1. Click on the Create a new group link at the top or bottom of the existing list of groups. A form for entering the details of the group will appear, as shown in Figure 4.6.

    Figure 4.6. The group creation form.

  2. Choose a name for the new group, and enter it into the Group name field. The name must not be used by any other group, and should be short and contain no spaces.

  3. The Group ID field should be left alone, as it is automatically determined by Webmin. If for some reason you change it, make sure that it is not the same as any existing group's ID.

  4. The Password field can be ignored, as group passwords are never used.

  5. In the Members field, enter the names of any existing users that you want included in this group. You can use the button to the left of the field to pop up a selection window of all existing users.

  6. Click the Create button to have Webmin create the new group. Once it is complete, you will be returned to the lists of users and groups.

Once the new group has been created, you can edit users to make it their primary group or one of their secondary groups.


4.7 Editing an Existing Group

You do not often need to edit an existing group, as users can be added to or removed from it by editing them directly. However, if you do want to edit a group, follow these steps:

  1. Click on the name of the group that you want to edit from the list of existing groups. This will bring up the group editing form, as shown in Figure 4.7.

    Figure 4.7. The group editing form.

  2. Change any of the details such as the group ID or member list. It is not possible to change the name of an existing group.

  3. If you are changing the group ID, files owned by the group may need to be updated to use the new ID. Use the Change group ID on files? option to control which directories will be searched for files that need updating.

  4. Click on the Save button to make the changes active. Once they are complete, you will be returned to the lists of users and groups.


4.8 Deleting a Group

You can safely delete a group at any time, but Webmin will only let you do so if there are no users who have selected it as their primary group. To delete, follow these steps:

  1. Click on the name of the group you want to delete from the list of existing groups. This will bring up the group editing form as shown in Figure 4.7.

  2. Click the Delete button at the bottom of the page. A page asking if you really want to delete the group will appear.

  3. Click the Delete Group button to confirm the deletion. A page showing the progress of the deletion will be displayed.


4.9 Viewing Recent and Current Logins

All UNIX systems keep track of recent logins made by users using SSH, telnet, or at the console. Some also track FTP logins as well. You can display recent user logins that include the date, time, and source address by following these steps:

  1. Below the lists of users and groups, enter the username of the one you want to track into the Display logins by field, and click the button. If you want to see logins by ALL users, just leave the field blank.

  2. A page listing recent logins by the user or users will be displayed. The list may not cover all logins from the date your system was first installed, as many operating systems automatically truncate the log file periodically in order to save disk space.

It is also possible to display a list of users who are currently logged in by clicking the Logged In Users button below the lists of users and groups. If a user is logged in graphically at the console, he may be listed multiple times—once for each shell window he has open.


4.10 Reading Users' Email

When editing a user, you can view mail in the user's mailbox by clicking on the Read Email button at the bottom of the page. This will take you directly to the mailbox viewing page of either the Sendmail, Qmail, or Postfix module, depending on what you have chosen for the Display user email from option in the module configuration. For more documentation on using the mail interface, see Chapter 37.


4.11 Creating Users from Batch Files

Sometimes you may want to create a large number of users at once without having to go through the process of filling out the user creation form over and over again. You will often have the details of these users in a text file of some kind containing their usernames, passwords, and real names. Fortunately, Webmin has a feature that automates this task for you.

If you click on the Create, modify and delete users from batch file link above or below the list of existing users, a form will appear that allows you to upload a file containing the details of users to create, as shown in Figure 4.8. Your file must contain one line of text for each user that you want to create, and the format of each line must match the format shown on the batch file page.

Figure 4.8. The batch file execution form.

The exact file format depends on what information your system stores about each user, but on most systems each line must follow this format:

create:username:passwd:uid:gid:realname:homedir:shell:min:max:warn:inactive:expire

An example line to create a user with the user ID automatically assigned by Webmin would be:

create:jcameron:mysecret::3001:Jamie Cameron:/home/jcameron:/bin/bash:::::

As you can see, the line is made up of a series of fields, each separated by a colon (:). When creating a user, the first field must be the create field. The meanings of the other fields are shown in Table 4.1.

Once you have created a file containing the details of users to create, select it using either the Upload batch file or Local batch file fields, and click the Execute batch button. A page displaying each user created and any errors encountered will be displayed. The most common error is a missing field in one of the lines—each must have exactly the right number of fields, and even if a field is blank the colon separator next to it must still be included.

Table 4.1. Batch File Fields and Their Meanings

username

The user's login name. This cannot be left blank.

passwd

The user's password. If this field is left blank, then no password will be needed for the user. If it contains just the letter x, then the user will be locked and no login allowed.

uid

User ID for the new user. This should be left blank, so Webmin can assign one automatically.

gid

ID of the user's primary group. This cannot be a group name, and cannot be left blank. If more than one GID is entered, the user will be added as a secondary member to all of those listed after the first one as well.

realname

The user's real name. Not mandatory, but should not be left blank.

homedir

A directory that is created with ownership assigned to the user. You can leave this blank if the module has been configured to assign home directories automatically.

shell

The user's login shell. This field cannot be left blank.

min

The number of days after the user is created or the password is last changed that the user must wait before changing it again. Can be left blank to allow changing as soon as the user likes.

max

The number of days after the user is created or the password is last changed that the password expires and must be changed again. If left blank, the password will never expire.

warn

The number of days before the password expiry date that the user will be warned at login that his password is about to expire. If left blank, the user will not know that his password has expired until it happens.

inactive

The number of days after the password expires that the entire account will be disabled, if the user has not chosen a new password.

If left empty, the account will never expire.

expire

The date on which this account will expire. Unfortunately, you must enter this as a number of days since January 1, 1970!


4.12 Configuring the Users and Groups Module

Like other Webmin modules, Users and Groups has several options that can be configured by clicking on the Module Config link above the lists of users and groups, as shown in Figure 4.9. The options that you can safely change and their meanings are shown in Table 4.2.

Figure 4.9. Configuration options for Users and Groups.

Table 4.2. Module Configuration Options

Command to run before making changes

Whatever shell command you enter into this field will be run just before any action is performed, such as adding, deleting, or modifying a user or group. It can be useful for doing things like making a backup copy of the /etc/passwd file before Webmin makes any changes.

The command can determine exactly what Webmin is about to do by checking environment variables, as explained in the Section 4.13 "Before and After Commands".

Command to run after making changes

Like the above option, but this command is run after any action is performed. It can be very useful if you want to have a command run after a user is created in order to setup additional files for that user.

Permissions on new home directories

The octal file permissions on newly created home directories, in the same format as used by the chmod command.

Copy files into new home directories from

Directories or files to copy into the home directory of newly created users, assuming the Copy files to home directory? option is turned on. If any of the paths you enter is a directory, all files and subdirectories in that directory will be copied. This option is usually set to /etc/skel by default, which is a system directory containing files like .cshrc and .profile.

Automatic home directory base

The directory under which users' home directories are usually created. If this option is set, an Automatic option will appear for the Home directory field in the user creation form. If chosen, the home directory will be determined by this option and the Automatic home directory style below.

Automatic home directory style

This option controls the path to a new user's home directory under the base. The most common default option of home/username will make it just a subdirectory under the base, with the same name as the username. So if you were creating a user called jcameron and the home directory base was set to /home, then the resulting home directory would be /home/jcameron.

Other options create subdirectories using the first one or two letters of the username. They can be useful if you have a very large number of users on your system, and want to avoid having thousands of entries in /home.

Lowest UID for new users

When Webmin automatically chooses a user ID for a new user, it will never pick one that is lower than specified in this option. On most systems, normal users have user IDs above 500, and system users have IDs below that.

Lowest GID for new groups

Like the option above, but for group IDs.

Create new group for new users?

If this option is set to Yes when creating a new user, the default action is to create a group of the same name and make it the user's primary group.

Assign same ID to new user and group?

This option only works if the previous one is enabled. If set to Yes when a new group is created for a new user, Webmin will make sure that their UID and GID are the same. This doesn't actually make any difference, but some administrators like it.

Don't use MD5 passwords if missing perl MD5 module?

This option should only be changed to Yes if you run into an error when creating a new user caused by a missing MD5 Perl module.

Check for sendmail alias clashes?

If set to Yes when creating or renaming a user, Webmin will check if there is a Sendmail alias of the same name. This can be useful to prevent the creation of users who would be unable to receive mail due to an alias redirecting it all to another address.

Only delete files owned by user?

If set to Yes when deleting a user, files in the user's home directory that do not belong to him will not be deleted.

Maximum user and group name length

The maximum allowed length for a user or group name. If this is set by default, it is not a good idea to adjust it because your operating system will not recognize longer usernames.

Default group for new users

The default primary group on the new user creation form.

Default secondary groups for new users

A space separated list of secondary groups that will be selected by default on the new user creation form.

Default shell for new users

The default shell on the new user creation form.

Default minimum days for new users

The default number of days before which password changing is not allowed.

Default maximum days for new users

The default number of days after which the password must be changed.

Default warning days for new users

The default number of days before password expiry that the user is warned.

Default inactive days for new users

The default number of days after password expiry that the user is disabled.

Maximum number of users to display

If the number of users or groups on the module's main page exceeds this number, the table of users or groups will be replaced by a search form. You may want to adjust this if the number of users on your system is just over the default limit.

Sort users and groups by

This option controls the ordering of users and groups on the module's main page.

Number of previous logins to display

This option limits the number of recorded logins to display so the table does not become too large on systems that keep an unlimited login history.

Display users and groups by

By default, users and groups are shown on the module's main page in a table with one row per user or group. However, if you change this option to Name only then only the username of each appears, saving a lot of screen space if you have a large number of users.

Changing to Primary group categorized also displays users by username only, but categorized by their primary group.

Conceal plain-text password?

If set to Yes when editing or creating a user, the Normal password field will show only stars instead of the actual password that you enter. Useful if you are worried about people looking over your shoulder when creating users.

Get user and group info from

Even though the module reads and edits system user, group, and password files directly, there will in some cases be users and groups on your system that come from another source, such as NIS. When displaying a user's primary group or the users who are members of a group, Webmin will use the getpw family of system calls by default to get a list of users and groups, instead of reading the user and group files directly.

This is normally the right thing to do, but in some cases it will not work properly or will be very slow. You should only change this option to Files if you are sure that you want the module to never use the getpw functions.

Generate password for new users?

If this option is set to Yes when creating a new user, Webmin will generate a random password for you by default.

Show office and phone details?

Normally, a user's Real name field only contains his name. However, it can also contain additional information such as his office location, home phone, and work phone. These extra fields are displayed by the finger command, and are stored by the system in the real name field of the /etc/passwd file separated by commas.

If you want to be able to edit this additional information separately, set this option to Yes. It will not work well if usernames on your system contain commas in them—like Cameron, Jamie.

Display user email from

This option controls which module is used when the Read Email button is clicked on the user editing page. You should make sure it is set appropriately depending on the mail system you are using because Sendmail and Qmail use different locations and file formats for user mailboxes.

Minimum password length

If set, you will not be able to create or edit users whose plain-text passwords are shorter than this length. This option and the three below also effect the Change Passwords and Cluster Users and Groups modules. They can be useful if you want to delegate user management to someone else, and don't trust the quality of his passwords.

Prevent dictionary word passwords?

If this option is set, passwords that exactly match any word from the dictionary will not be allowed.

Perl regexp to check password against

If set, passwords must match this Perl regular expression. For example, you could enter [0-9] for this option to force all passwords to contain at least one digit.

Prevent passwords containing username?

When this option is set to Yes, passwords that exactly match or contain the user's username will not be allowed.

The other options under the System configuration heading control the files Webmin reads and writes user and group information from and to. Because they are set automatically based on the type of operating system you use, they should not be changed unless you know what you are doing.


4.13 Before and After Commands

As Section 4.12 "Configuring the Users and Groups Module" explains, you can specify shell commands to be run before and after any action is taken in the module. Because these commands are called for every addition, modification, or deletion of a user or group, they need some way of telling exactly what action is being performed. They can do this using environment variables that are set before the command is run. The available environment variables are shown in Table 4.3.

If you wanted to send out email when a user is created, for example, you could set the Command to run after making changes option to:

[View full width]

[ "$USERADMIN_ACTION" = "CREATE_USER" ] && echo "Added user $USERADMIN_USER
  ($USERADMIN_REAL)" | mail –s "Added new user" you@yourdomain.com


4.14 Module Access Control

It is possible to grant a Webmin user or group access to only a subset of features in the Users and Groups module. This is most commonly used to allow a subadministrator the right to edit only selected users and groups on the system, and to change their attributes in only limited ways. In a virtual hosting environment, for example, you may want to give a Webmin user the ability to create and edit up to 10 users with UIDs in a limited range, and home directories under a fixed directory. These privileges give the user no way to gain root access and affect users that do not belong to him.

Table 4.3. Environment Variables for Before and After Commands

USERADMIN_ACTION

Indicates which action is being taken. Possible values are:

CREATE_USER
MODIFY_USER
DELETE_USER
CREATE_GROUP
MODIFY_GROUP
DELETE_GROUP

USERADMIN_USER

The username of the user being created, modified, or deleted. Not set when a group action is being performed.

USERADMIN_UID

The user ID of the user being created, modified, or deleted.

USERADMIN_GID

The group ID of the user.

SERADMIN_REAL

The real name of the user, including any office and phone information.

USERADMIN_SHELL

The shell of the user.

USERADMIN_HOME

The home directory of the user.

USERADMIN_PASS

The plain text password of the user, if available.

USERADMIN_SECONDARY

A comma-separated list of any secondary groups to which the user belongs.

USERADMIN_GROUP

The name of the group being added, modified, or deleted. Not set when a user action is being performed.

Chapter 52 explains how to create additional Webmin users and edit their module access control in more detail. The following steps cover just the parts of the process that grant the kind of limited access that is specific to the Users and Groups module:

  1. In the Webmin Users module, click on Users and Groups next to the name of the user that you want to edit. This will take you to the access control form shown in Figure 52.3.

  2. Change the Can edit module configuration? field to No.

  3. The UNIX users who can be edited field controls the users that can be changed by this Webmin user. You would typically set it to Users with UIDs in range and enter maximum and minimum UIDs into the fields next to it, such as 5000 and 5010.

  4. To allow the addition of new UNIX users, set the Can create new users? field to Yes.

  5. Set the Can view batch file form? option to No. This will prevent the Webmin user from creating and editing users from a batch script, which is not normally necessary. Allowing it, however, does not grant the user any additional privileges and is not a security risk.

  6. For the UIDs for new and modified users fields, enter the same UIDs as in Step 4.

  7. Deselect the More than one user can have the same UID option, but leave the UIDs of existing users can be changed option selected. An untrusted subadministrator should not normally be allowed to create multiple users with the same UID due to the problems that this can cause.

    When UID clashes are prevented, the Webmin user will not be able to create any more UNIX users than fit in his allowed UID range.

  8. In the Allowed groups for new or modified users field, you would typically select the Only groups option and enter the names of any groups of which new users can be primary or secondary members. Normally you would just enter a single group like users. Leaving this field set to All groups is a very bad idea, because it would allow the creation of users who are members of the root or bin groups, and who can thus edit important system files and executables. The Groups with GIDs in range option can be useful if this Webmin user is allowed to create multiple groups of his own within the same GID range.

  9. To restrict the shells that a new user can be assigned, set the Allowed shells for new or modifed users to Listed and enter their paths into the text box below. This can be useful to allow the creation of only mail-only users who always have the shell /bin/false.

  10. Set the Home directories must be under field to a directory that will only be used for accounts created by this Webmin user. Setting it to /home is a bad idea, because this would allow the subadministrator to rename or delete directories belonging to other users that are under /home. Instead, enter something like /home/subadmin.

    To force every user's home directory to be based on his username (such as /home/subadmin/username), check the Home directory is always same as username box.

  11. To stop the Webmin user from deselecting some of the options at the bottom of the user creation, editing and deletion forms, deselect the matching Allowed on save options. Any that are not chosen will effectively always be turned on.

  12. Assuming you just want the Webmin user to create and edit UNIX users, set the UNIX groups who can be edited field to No groups.

  13. If you want to restrict the user from viewing recent logins, change the Can display logins by field. Any user who can login with telnet or SSH can run the last command anyway to display logins, so setting this option to No users does not usually make your system any more secure.

  14. Finally, click Save. You will be returned to the module's main page and the new access control restrictions will be immediately applied to the Webmin user.

Be careful when granting a Webmin user access to certain UNIX users, as a mistake may allow him to edit the root user or create a new user who is equivalent to root. There are also many other users like bin, uucp, and httpd that own important system files or are used for running server and daemon processes. Someone who can edit or login as one of these users could gain root privileges on your system or access files that he is not supposed to.

Often the access control in the Disk Quotas and Scheduled Cron Jobs module is set up to allow editing of the quotas and Cron jobs of the same UNIX users as those that can be edited and created in this module. All modules support the UID range and primary group access control options, which can be set in the same way.

It is also possible to use the Users and Groups access control form to allow a user to edit or create selected UNIX groups, though this is not generally as useful. Granting an untrusted user the rights to edit all groups on the system is a bad idea, as he would make himself a member of the root or bin group and so be able to read or write critical files.


4.15 Other Operating Systems

Different operating systems store different information about users than Linux does. This is due to the different files and file formats used for storing user information. Some, for example, do not have an /etc/shadow file, meaning that information about password change and expiry times does not exist. The list below explains the major differences between other supported operating systems and Linux:

FreeBSD, OpenBSD and NetBSD All these operating systems use the /etc/master.passwd file for storing user information, which combines /etc/passwd with some fields from /etc/shadow. When editing or creating a user, you can enter a Password change time which is the date and time after which the password must be next changed, and an Account expiry time after which an account can no longer be used. Each user can also have a Login class, which is used in conjunction with the /etc/login.conf file to determine memory, CPU, and other limits.

Sun Solaris and SCO UnixWare Both these operating systems use the same files and formats as Linux, and so have all the same options.

HP/UX, SGI Irix, and Compaq Tru64/OSF1 Because none of these systems use an /etc/shadow file by default, none of the options related to password and account expiration are available when editing or creating a user.

Apple MacOS X OSX does not store user and group information in files at all—instead, it uses a network database called NetInfo, which Webmin manipulates using the nidump and niutil commands. This database, however, stores the same information as the BSD master.passwd file, so when editing or creating a user the same fields are available as for FreeBSD.

IBM AIX AIX uses the files /etc/passwd and /etc/security/passwd for storing user information. Therefore, when editing or creating users on AIX there are some options that do not exist on other operating systems. The Expiry date field can be used to set the date and time after which the account cannot be used. The Minimum weeks and Maximum weeks fields are very similar to the Maximum days and Minimum days fields on Linux, but deal with weeks instead of days. The Warning days field has exactly the same meaning as on Linux, and deals with days not weeks. The unique Account flags field sets special options whose meanings are explained on the form.

SCO OpenServer OpenServer uses /etc/passwd and /etc/shadow files, but the shadow file stores slightly different information than on Linux. This means that when editing a user, the Expiry date field is replaced with an option to control whether the user is prompted for a password at their next login, and the Warning days and Inactive days fields are not available.

Those few operating systems that are not listed above cannot use the Users and Groups module, as their file formats are not currently know to Webmin.


4.16 Summary

This chapter has explained how to create and manage users and groups on a UNIX system. Because they are used to enforce file security, to protect processes from each other, and as mailboxes, user management is one of the most important tasks on a multi-user server system. This means that the module covered in this chapter is one of the most commonly used in Webmin, and also one of the most powerful.


Chapter 5. Disk and Network Filesystems

The chapter explains how to mount filesystems, either from partitions on your system's hard disks or from other file servers.


5.1 Introduction to Filesystems

On a UNIX system, all files exist in a tree of directories under the root / directory. Drive letters used by other operating systems (like Windows) to identify different hard disks or network drives do not exist. Instead, different hard disks, CD-ROMs, floppy disks, and network drives are attached to the directory tree at different places, called mount points. For example, /home may be a mount point for a different hard disk on your system, and /usr/local may be the mount point for files that are shared from another server. The root directory is also a mount point, almost always for a partition on a hard disk in your machine. The set of files that is actually mounted at a mount point is called a filesystem.

All operating systems divide each hard disk up into partitions, each of which can be a different size. Each filesystem is normally stored on one partition of one disk, so it is possible to have multiple filesystems of different types on the same hard disk—one for Linux and one for Windows, for example. If you have multiple hard disks in your system, you will normally need to mount at least one filesystem from each in order to make use of them.

UNIX systems support many different kinds of filesystems—some for files stored on local hard disks and some for files on networked file servers. On Linux, the filesystems on your hard disks will probably be in ext2 or ext3 format. Many other local filesystem types exist, such as iso-9660 for CD-ROMs, vfat for Windows partitions, and xfs and reiserfs for high performance file access. Every local filesystem type uses a different format for storing data on disk, so if a partition has been formatted as a filesystem of a particular type, then it must be mounted as that type.

There are also filesystem types for different methods of accessing file servers across a network. If the file server is running UNIX, then an nfs filesystem is usually mounted to access its files. However, if it is running Windows, an smbfs filesystem must be used instead. These different filesystem types correspond to different network protocols for accessing files on another system.

Other special filesystem types contain files that do not actually exist on any disk or file server. For example, a proc filesystem contains files that contain information about currently running processes. Different UNIX variants have different types of special filesystems, most of which are automatically mounted by the operating system and do not need to be configured.

No explanation of filesystems can be complete without also covering virtual memory. Often a UNIX system will be running processes that take up more memory than is actually installed. This is made possible by the operating system automatically moving some of those processes out of real memory and into virtual memory, which is stored in a file or a local hard disk. Because filesystems and virtual memory are both stored on disk and can be mounted and unmounted, the Disk and Network Filesystems Webmin module also manages with virtual memory.

Depending on your operating system, the files /etc/fstab or /etc/vfstab contain a list of filesystems that are known to your system and mounted at boot time. It is also possible for a filesystem to be temporarily mounted using the mount command without being stored in the fstab file. Webmin directly modifies this file to manage filesystems that are mounted at boot time, and calls the mount and unmount commands to immediately activate and deactivate filesystems.


5.2 The Disk and Network Filesystems Module

The Disks and Network Filesystems module is found under the System category, and allows you to configure which filesystems are mounted on your computer, where they are mounted from and what options they have set. The main page of the module (shown in Figure 5.1) lists all the filesystems that are currently mounted or available to be mounted.

Figure 5.1. The list of existing filesystems.

For each filesystem, the following information is displayed:

Mounted As The mount point directory for this filesystem, or the message Virtual Memory.

Type A description of the filesystem type, followed by the actual short type name.

Location The disk, fileserver, or other location from which this filesystem was mounted. For nfs mounts, this column will be in the form servername:remotedirectory. For smbfs mounts, it will be similar to \\servername\sharename.

In use? Yes or No, depending on whether the filesystem is currently mounted. For most filesystems, you can click on this field to mount or unmount immediately.

Permanent Yes or No, depending on whether the filesystem is permanently recorded so that it can be mounted at boot time.


5.3 Mounting an NFS Network Filesystem

Before you can mount a filesystem from another UNIX server, that server must be configured to export the directory that you want to mount using NFS. For details on how to export a directory using Webmin, see Chapter 6.

Assuming the directory that you want to mount has been exported properly, you can follow the following steps to mount it on your system:

  1. On the main page of the Disk and Network Filesystems module, select Network Filesystem from the dropdown box of filesystem types, and click the Add mount button. A form will appear, as shown in Figure 5.2.

    Figure 5.2. Mounting a network filesystem.

  2. In the Mounted As field, enter the directory on which you want the filesystem to be mounted. The directory should be either nonexistent or empty, as any files that it currently contains will be hidden once the filesystem is mounted.

  3. If you want the filesystem to be mounted at boot time, select Save and mount at boot for the Save Mount option. If you want it to be permanently recorded but not mounted at boot, select Save. Select Don't save if this is to be only a temporary mount.

  4. For the Mount now? option, select Mount if you want the filesystem to be mounted immediately, or Don't mount if you just want it to be recorded for future mounting at boot time. It makes no sense to set the Save and mount option to Don't save and the Mount now? option to Don't mount, as nothing will be done!

  5. In the NFS Hostname field, enter the name or IP address of the fileserver that is exporting the directory that you want to mount. You can also click on the button next to the field to pop up a list of NFS servers on your local network.

  6. In the NFS Directory field, enter the exported directory on the fileserver. If you have already entered the NFS server's hostname, click on the button next to the field to pop up a list of directories that the server has exported.

  7. Change any of the options in the bottom section of the form that you want to enable. Some of the most useful are as follows:

    Read-only? If set to Yes, files on this filesystem cannot be modified, renamed, or deleted.

    Retry mounts in background? When an NFS filesystem is mounted at boot time, your system will normally try to contact the fileserver forever and ever if it is down or unreachable, which can prevent the boot process from completing properly. Setting this option to Yes will prevent this problem by having the mount retried in the background if it takes too long.

    Return error on timeouts? The normal behavior of the NFS filesystem in the face of a fileserver failure is to keep trying to read or write the requested information until the server comes back up again and the operation succeeds. This means that if the fileserver goes down for a long period of time, any attempt to access files mounted from the server will get stuck. Setting this option to Yes changes this behavior so that your system will eventually give up on operations that take too long.

  8. To mount and/or record the filesystem, click the Create button at the bottom of the page. If all goes well, you will be returned to the filesystems list, otherwise an error will be displayed explaining what went wrong.

Once the NFS filesystem has been successfully mounted, all users and programs on your system will be able to access files on the fileserver under the mount point directory. If users can log in to both your system and the remote fileserver, any files that they own on one machine should be owned on the other because the NFS protocol supports UNIX file permissions and file ownership information. This depends, however, on every user having the same user ID on both servers. If this is not the case, you may end up in a situation in which user jcameron owns a file on the fileserver, but the file appears to be owned by user fred when it is mounted and accessed on your system.

The best solution to this problem is to make sure that user IDs are in sync across all servers that share files using NFS. The best ways to do that are using NIS (as explained in Chapter 17), or Webmin's own Cluster Users and Groups module (as explained in Chapter 49).


5.4 Mounting an SMBFS Windows Networking Filesystem

smbfs is the protocol used by Windows systems to share files with each other. If you have files on a Windows system that you want to be able to access on your Linux system, you must first share the directory and assign it a share name using the Windows user interface.

Once that is done, follow these steps to mount the share on your UNIX system:

  1. On the main page of the Disk and Network Filesystems module, select Windows Networking Filesystem from the drop-down box of filesystem types and click the Add mount button. A form will appear, as shown in Figure 5.3.

    Figure 5.3. Mounting a windows networking filesystem.

  2. In the Mounted As field, enter the directory on which you want the filesystem to be mounted. The directory should be either nonexistent or empty because any files that it currently contains will be hidden once the filesystem is mounted.

  3. If you want the filesystem to be mounted at boot time, select Save and mount at boot for the Save Mount option. If you want it to be permanently recorded but not mounted at boot, select Save. Select Don't save if this is to be only a temporary mount.

  4. For the Mount now? option, select Mount if you want the filesystem to be mounted immediately, or Don't mount if you just want it to be recorded for future mounting at boot time.

  5. In the Server Name field, enter the hostname or IP address of the Windows server. The button next to the field will pop up a list of Windows servers on your network, requested from the domain or workgroup master set in the module configuration.

  6. In the Share Name field, enter the name of the share. This will be something like movies, not the full path on the Windows server like c:\files\movies. If you have entered the server name, clicking on the button next to the field will pop up a list of available shares.

  7. If the Windows server requires a username and password to access the file share, fill in the Login Name and Login Password fields. If no authentication is needed, these fields can be left blank.

  8. Because Windows networking has no concept of UNIX users, all files from the fileserver will be owned by a single UNIX user and group when the filesystem is mounted. That user is root by default, but you can change this by filling in the User files are owned by and Group files are owned by fields.

  9. Click the Create button at the bottom of the page to mount and/or record the filesystem. If all goes well, you will be returned to the filesystems list, otherwise an error will be displayed explaining what went wrong.

Windows networking filesystems can also be exported by UNIX servers using Samba, as explained in Chapter 43. This means that you could share files between two UNIX servers using the Windows file sharing protocol. As you might guess, however, this is not usually a good idea because file permissions and ownership information will not be available on the mounting server.


5.5 Mounting a Local ext2 or ext3 Hard Disk Filesystem

Before you can mount a new filesystem from a local hard disk, a partition must have been prepared and formatted with the corrected filesystem type. For details on how to do this, see Chapter 8. If you have a choice, ext3 (called the New Linux Native Filesystem by Webmin) should be used instead of ext2 (the Linux Native Filesystem) because of its support for journaling. See Section 5.13 "A Comparison of Filesystem Types" for more details on the advantages of ext3.

To mount your local filesystem, follow these steps:

  1. On the main page of the Disk and Network Filesystems module, select Linux Native Filesystem or New Linux Native Filesystem from the drop-down box of filesystem types, and click the Add mount button. A form will appear for entering the mount point, source, and options.

  2. In the Mounted As field, enter the directory on which you want the filesystem to be mounted. The directory should be either nonexistent or empty because any files that it currently contains will be hidden once the filesystem is mounted.

  3. If you want the filesystem to be mounted at boot time, select Save and mount at boot for the Save Mount option. If you want it to be permanently recorded but not mounted at boot, select Save. Select Don't save if this is to be only a temporary mount.

  4. For the Mount now? option, select Mount if you want the filesystem to be mounted immediately, or Don't mount if you just want it to be recorded for future mounting at boot time.

  5. If the Check filesystem at boot? option exists, it controls whether the filesystem is validated with the fsck command at boot time before mounting. If your system crashes or loses power, any ext2 or ufs filesystems that were mounted at the time will need to be checked before they can be mounted. It is generally best to set this option to Check second.

  6. For the Linux Native Filesystem field, click on the Disk option and select the partition which has been formatted for your new filesystem. All IDE and SCSI disks will appear in the menu.

    If any of the partitions on your system are labeled, you can mount one by selecting the Partition labeled option and choosing the one you want. Labels are explained further in Chapter 8.

    If your system has any RAID devices configured (as also explained in Chapter 8), you can select the RAID device option and choose the one you want to mount from the menu.

    If you are using LVM (Logical Volume Management, covered in Chapter 8), a list of all available logical volumes will appear next to the LVM logical volume option for you to select from.

    You can also click on the Other device option and enter the path to the device file for your filesystem, like /dev/hda2.

  7. Change any of the options in the bottom section of the form that you want to enable. Some of the most useful are:

    Read-only? If set to Yes, files on this filesystem cannot be modified, renamed, or deleted.

    Use quotas? If you want to enforce disk quotas on this filesystem, you must enable this option. Most filesystem types will give you the choice of user quotas, group quotas, or both. To complete the process of activating and configuring quotas, see Chapter 7.

  8. Click the Create button at the bottom of the page to mount and/or record the filesystem. If all goes well, you will be returned to the filesystems list, otherwise an error will be displayed explaining what went wrong.


5.6 Mounting a Local Windows Hard Disk Filesystem

If your system has a Windows partition on one of its hard disks, you can mount it using Webmin so that all the files are easily accessible to UNIX users and programs. Windows 95, 98 and ME all use the older vfat format by default, called a Windows 95 filesystem by Webmin. Windows NT, 2000, and XP, however, use the more advanced ntfs filesystem format (called Windows NT filesystem) which only a few Linux distributions support.

  1. On the main page of the Disk and Network Filesystems module, select either Windows 95 Filesystem or Windows NT Filesystem from the drop-down box of filesystem types, and click the Add mount button. A form will appear for entering the mount point, source, and options.

  2. In the Mounted As field, enter the directory on which you want the filesystem to be mounted. The directory should be either nonexistent or empty because any files that it currently contains will be hidden once the filesystem is mounted.

  3. If you want the filesystem to be mounted at boot time, select Save and mount at boot for the Save Mount option. If you want it to be permanently recorded but not mounted at boot, select Save. Select Don't save if this is to be only a temporary mount.

  4. For the Mount now? option, select Mount if you want the filesystem to be mounted immediately, or Don't mount if you just want it to be recorded for future mounting at boot time.

  5. For the Windows 95 Filesystem or Windows NT Filesystem field, click on the Disk option and select the partition that has been formatted for your new filesystem. All IDE and SCSI disks, RAID devices, and LVM logical volumes will appear in the list.

    You can also click on the Other device option and enter the path to the device file for your filesystem, like /dev/hda2.

  6. Select any options that you want to enable. Some useful ones are:

    User files are owned by Because the vfat filesystem format has no concept of users and groups, all files in the mounted filesystem will, by default, be owned by root. To change this, enter a different UNIX username for this option.

    Group files are owned by Like the previous option, this controls the group ownership of all files in the mounted filesystem.

    File permissions mask The binary inverse in octal of the UNIX permissions that you want files in the mounted filesystem to have. For example, entering 007 would make files readable and writable by their user and group, but totally inaccessible to everyone else. This option is not available for Windows NT filesystems.

  7. Click the Create button at the bottom of the page to mount and/or record the filesystem. If all goes well, you will be returned to the filesystems list, otherwise an error will be displayed explaining what went wrong.

Because Windows 95 filesystems have no concept of file ownership, and Windows NT filesystems have ownership information that is unsupported by Linux, it is impossible to change the user, group, or permissions on files in a mounted filesystem.


5.7 Adding Virtual Memory

As explained in the introduction, virtual memory is used when the processes running on your system need to use more memory than is physically installed. Because not all processes run at the same time, those that are inactive can be safely swapped out to virtual memory and then swapped back in again when they need to run. Because disks are far slower than RAM, however, the constant swapping in and out (known as thrashing) will slow the system to a crawl if processes on your system use up too much memory.

Files in an existing local filesystem as well as entire partitions can be used for virtual memory. Using a partition is almost always faster, but can be inflexible if you have no free partitions on your hard disk. A system can have more than one virtual memory file or partition, so if you are running out of virtual memory it is easy to add more.

The steps for adding additional virtual memory are:

  1. On the main page of the Disk and Network Filesystems module, select Virtual Memory from the drop-down box of filesystem types, and click the Add mount button. A form will appear for entering the source and other options.

  2. If you want the virtual memory to be added at boot time, select Save and mount at boot for the Save Mount option. Otherwise, select Don't save if this is to be only a temporary addition.

  3. For the Mount now? option, select Mount if you want the virtual memory to be added immediately, or Don't mount if you just want it to be recorded for future addition at boot time.

  4. If you want to add an entire partition as virtual memory, select Disk for the Swap File option and select the partition from the list. Otherwise, select Swap File and enter the path that you want to use as virtual memory. If you enter a path to a file that already exists, that file will be overwritten when the virtual memory is added.

  5. Click the Create button at the bottom of the page. If you are adding a swap file which does not exist yet, you will be prompted to enter a size for the file, and Webmin will create it for you. If all goes well, the browser will return to the list of filesystems on the main page.

Once the new virtual memory has been added, your system's available memory should increase by the size of the partition or swap file. Use the memory display of the Running Processes module (explained in Chapter 11) to see how much real and virtual memory is available.


5.8 Automounter Filesystems

Before you can access files on any filesystem using Linux, it must first be explicitly mounted. This is fine for hard disks that are mounted at boot time, but is not so convenient for removable media like CD-ROMs, floppy disks, and Zip disks. Having to mount a floppy before you can read or write files on it, and then unmount it when done, is not very user friendly—especially compared to other operating systems like Windows.

Fortunately, there is a solution—the automounter filesystem. This system does not contain any files of its own, but automatically creates temporary directories and mounts filesystems when needed. An automounter filesystem mounted at /auto would normally be configured to mount a floppy disk at /auto/floppy as soon as a user tries to cd into that directory. When the floppy's filesystem is no longer being used, it will be automatically unmounted so that the floppy can be safely ejected.

Automounter filesystems can be created, viewed and edited in Webmin. Each has a configuration file that specifies which devices it will mount and which subdirectories on which they will be mounted. The editing of these configuration files cannot be done within Webmin, however—you can only choose which one to use. Most modern Linux distributions come with an automounter filesystem at /auto or /media set up by default, and configured to allow access to floppy and CD-ROM drives.

Another common use for the automounter is to provide easy access to NFS servers. Often an automounter on the /net directory is set up so that accessing the /net/hostname directory will mount all the exported directories from hostname under that directory. This is all done using another automounter configuration file.


5.9 Editing or Removing an Existing Filesystem

After mounting a filesystem, you can go back and change the mount directory, source, and options at any time. Even most filesystems that were set up as part of your operating system's installation process can be edited. Some special filesystem types like proc and devfs, however, cannot be edited though Webmin because changing them would probably break your system.

The only catch is that filesystems currently in use cannot be immediately edited. If any user or process is accessing any file or is in any directory on a filesystem, it is considered busy and cannot be unmounted and remounted by Webmin in order to change it. Because the root filesystem is always in use, making immediate changes to it is impossible. Fortunately, there is an alternative—changing only the permanent record of a filesystem so the new options are applied when your system reboots.

The steps to follow for editing a filesystem are:

  1. From the list of filesystems on the main page, click on the mount point directory in the Mounted as column. A form containing the current settings will appear, as shown in Figure 5.4.

    Figure 5.4. Editing an existing filesystem.

  2. Change any of the settings, including the Mounted As directory, the device or server from which the filesystem is mounted, or the mount options.

  3. If you want to unmount the filesystem while still keeping it recorded for future mounting, change the Mount now? option to Unmount. If you want to mount a filesystem that is permanently recorded, however, change the option to Mount.

  4. Click the Save button to make your changes active. If all goes well, the browser will return to the list of filesystems on the main page.

    If you are changing a mounted filesystem that is busy, you will be given the option of having your changes applied to the permanent list only. If you are trying to enable quotas on a Linux native filesystem, having the option applied to the permanent list is usually all that is needed.

To totally remove a filesystem, just edit it and set the Save Mount? option to Don't save, and the Mount Now? option to Unmount. Assuming it is not in use, it will be unmounted and removed from the list of recorded filesystems and will no longer show up in the list on the module's main page.


5.10 Listing Users of a Filesystem

If you cannot unmount or edit a filesystem because it is busy, you may want to kill the processes that are currently using it.

To find which processes are using a filesystem, follow these steps:

  1. From the list of filesystems on the main page, click on the mount point directory in the Mounted as column. The form shown in Figure 5.4 will appear.

  2. Click the List Users button in the bottom-right corner of the page. This will display a list of all processes that are reading, writing, or in any file or directory in the filesystem.

  3. To kill them, click the Kill Processes button at the bottom of the page. You should now be able to return to the Disk and Network Filesystems module and unmount successfully.


5.11 Module Access Control

A Webmin user can be given limited access to this module so he can only edit the settings for certain filesystems or only mount and unmount. Allowing an untrusted user to mount any filesystem is a bad idea because he can gain complete control of your system by mounting an NFS or floppy disk filesystem containing setuid-root programs. Giving someone the rights to only mount and unmount certain filesystems that have their options set to prevent the use of setuid programs, however, is quite safe. This can be useful if your system has a floppy or CD-ROM drive and you are not using an automounter.

Once a user has been given access to the module (as explained in Chapter 52), you can limit him to just mounting or unmounting selected filesystems by following these steps:

  1. In the Webmin Users module, click on Disk and Network Filesystems next to the user's name to bring up the access control form.

  2. Change the Can edit module configuration? field to No to stop him from configuring the module to use a different fstab file or mount commands.

  3. In the Filesystems that can be edited field, select Under listed directories and enter a list of mount points into the adjacent text box. For example, you might enter /mnt/floppy /mnt/cdrom. It is also possible to enter a directory like /mnt to allow access to all filesystems under it.

  4. Change the Can add new filesystems? field to No.

  5. Change the Only allow mounting and unmounting? field to Yes, so that the user cannot actually edit filesystem details.

  6. Hit the Save button to activate the new restrictions.

On Linux systems, the Allow users to mount this filesystem? field can be used to allow the use of the command-line mount and unmount programs. Other tools like the Gnome mount panel applet and Usermin also make use of this feature, which may be a better way to give normal users mount and unmount privileges.


5.12 Configuring the Disk and Network Filesystems Module

Like other modules, this one has a few options that you can change. To see them, click on the Module Config link in the top-left corner of the main page. This will take you to the standard configuration editing page, on which the options shown in Table 5.1 are available under the Configurable options header.

Table 5.1. Module Configuration Options

Server to request browse list from

When mounting an smbfs filesystem, the button next to the Server name field will pop up a list of Windows servers on your network. This list is fetched from the server specified by this option, which should be the domain or workgroup master.

Show long filesystem type names

If this option is set to No, the main page will display only short filesystem type names (like EXT2). By default, it is set to Yes and long filesystem types are displayed (like Linux Native Filesystem).

None of the other options on the configuration page should be changed, as they are set automatically by Webmin based on your operating system type.


5.13 A Comparison of Filesystem Types

Unlike other operating systems, Linux supports several different types of filesystems that fully support UNIX file permissions and ownership information. Originally, ext2 was the only choice, but newer kernel versions and distributions have added support for ext3, reiserfs, and xfs. This list explains the benefits of each of these alternative filesystem types.

New Linux Native Filesystem (ext3) Very similar to ext2, but with support for journaling. This means that if your system crashes or loses power without having a chance to properly unmount its filesystems, there is no need for the lengthy fsck check of the entire ext3 filesystem that would be needed with ext2.

Because ext3 filesystems are so similar to ext2, they are stored on disk in almost exactly the same format. This means that it is relatively simple to convert an existing filesystem to ext3 by creating a special journal file.

Rieser Filesystem (reiserfs) ReiserFS is a totally new filesystem designed to be faster and more efficient than ext2. It supports journaling like ext3 does, and deals much better with large numbers of small files than other filesystems. It is probably not as mature as ext3 or xfs, however, and does not support quotas.

SGI Filesystem (xfs) XFS was originally developed by SGI for its IRIX operating system, and if you are running Webmin on IRIX you can mount xfs filesystems as well. It supports journaling and includes native support for ACLs (access control lists) and file attribute lists. The ACL support in particular is very useful, because it allows you to grant access to files in ways that would be impossible with the normal UNIX user/group permissions. XFS has been used for several years on IRIX, so it should be reasonably mature and reliable.

IBM Journaling Filesystem (jfs) JFS was originally developed by IBM for use on its AIX and OS/2 operating systems, but has recently been ported to Linux. It supports journaling and large (64-bit) file sizes, but does not current support quotas or ACLs. Because JFS has been used for years on IBM operating systems, it should be reasonably mature. It is quite new on Linux, however, and so may not be as well tested.

To see which of these filesystem types are supported by your system, go into the Partitions on Local Disks module (covered in Chapter 8) and select an unused partition of type Linux. At the bottom of the page will be a form that you can use to create a new filesystem on the partition in one of the types that is available on your system. Most new Linux distributions will support ext3, some will support reiserfs, but only a few include xfs support.

Linux also supports several older filesystem types such as ext, xiafs, and minix. You will never need to use these unless you have an old disk formatted with one of them.


5.14 Other Operating Systems

The Disk and Network Filesystems module supports several other operating systems in addition to Linux, using basically the same user interface. The main differences lie in the filesystem types supported by each operating system, and the type used for hard disk UNIX filesystems. Only Linux, Solaris, and Irix display a drop-down menu of available partitions when adding a hard disk filesystem—on other systems, you must enter the IDE or SCSI controller and drive numbers manually.

The operating systems on which the module can be used, and the major differences between each of them and Linux, are:

Sun Solaris Solaris uses ufs (called the Solaris UNIX Filesystem by Webmin) as its standard filesystem type for local hard disks. It has many of the same options as ext2 on Linux, but does not support group quotas, only user quotas. Adding virtual memory is also supported, in exactly the same way as on Linux.

The NFS filesystem type on Solaris is also similar to Linux, but supports mounting from multiple NFS servers in case one goes down. When entering servers into the Multiple NFS Servers field, they must be comma separated like host1:/path,host2:/path,host3:/path. Solaris systems can only mount Windows Networking Filesystems if the rumba program has been installed. They can only be mounted temporarily, however, not recorded for mounting at boot time.

One interesting filesystem type that only Solaris supports is the RAM Disk (tmpfs). Files in a filesystem of this type are not stored on disk anywhere, and so will be lost when the system is rebooted or the filesystem is unmounted. By default, Solaris uses tmpfs for the /tmp directory.

FreeBSD FreeBSD also uses ufs as its standard local hard disk filesystem type, although it is called the FreeBSD UNIX Filesystem by Webmin. It has most of the same options as Linux, and supports user and group quotas. Virtual memory is also supported on FreeBSD, but with the catch that once added it cannot be removed without rebooting. NFS is supported with similar options to Linux, but Windows networking filesystems are not.

OpenBSD OpenBSD uses the ffs filesystem type for local hard disk, which is called the OpenBSD UNIX Filesystem by Webmin. Like FreeBSD, it supports virtual memory and NFS, but not Windows networking filesystems.

HP/UX HP's UNIX variant uses hfs (HP UNIX Filesystem) as its standard local hard disk filesystem type, but also supports the superior, journaled vxfs, called HP Journaled UNIX Filesystem by Webmin. Both have an option for disk quotas, but for users only. Virtual memory is supported and can be added and removed at any time, but is always mounted at boot if permanently recorded. NFS is also available, with similar options to Linux, but there is no Windows networking filesystem type.

SGI Irix Newer versions of Irix use xfs (SGI Filesystem) as their standard hard disk filesystem type, which supports all the same options as xfs on Linux, including user quotas, ACLs, and file attributes. The efs (Old SGI Filesystem) type is also available, but should only be used if you have old partitions that are already formatted for it, or are running an old version of Irix. Irix supports NFS with similar options to Linux, but does not support Windows networking. AppleTalk and Netware filesystems can also be mounted using command-line tools, but they can not yet be mounted or edited from within Webmin.

The operating system also has standard virtual memory support, but with the peculiarity that the first swap partition on the first hard drive is always added as virtual memory automatically, using the special /dev/swap device file.

SCO UNIXWare UNIXWare has very similar filesystem support to Solaris, but also adds support for the hard disk based vxfs (Veritas Filesystem) type.

If your operating system is not on the list above, then it is not supported by the Disk and Network Filesystems module. In some cases, this is because the code has not yet been written, such as with AIX or Tru64/OSF1. MacOS X, on the other hand, mounts all hard disk partitions at boot time and automatically mounts network filesystems when requested by the user through the GUI. It therefore has no need for a Webmin module for managing filesystems.


5.15 Summary

Unlike other operating systems, Linux and other variants of UNIX do not automatically make files on hard disks and removable media available to you. This chapter has explained what filesystems and partitions are and how to mount them to gain access to the data that they contain. It has also covered the client-side part of file sharing between two or more systems over a network.


Chapter 6. NFS File Sharing

This chapter explains how to export files to other UNIX systems by setting up an NFS server.


6.1 Introduction to File Sharing with NFS

NFS is the most common protocol for sharing files between UNIX systems over a network. NFS servers export directories from their local hard disks to NFS clients, which mount them so that they can be accessed like any other directory. Unlike other file sharing protocols, such as Windows networking, Netware, and AppleShare, NFS was designed to support client systems that have multiple users. This means that a client never logs into a server, and that the server almost completely trusts the client to authenticate users. The down side is that NFS is not a good protocol for sharing files with client systems that are not fully trusted.

Instead of using usernames and passwords for authentication, NFS uses the IP address of the client. Only trusted clients are allowed to mount directories from the server so that it is not vulnerable to unauthorized file access from any client on the network. Some additional security can be gained by restricting the access of particular UNIX users on a client, or treating all requests from a client as a single user.

On Linux, the /etc/exports file contains a permanent list of directories exported by NFS and the clients to which they are exported. Typically, this file is read at boot time by the nfsd and mountd programs that run in the background to service NFS requests. When you change or create exports using Webmin, the exports file is directly updated.

This chapter covers only the sharing of directories from a server using NFS. For details on how to mount an NFS exported directory on a client, see Chapter 5. If you want to share files with Windows clients, you should read Chapter 43 (which covers Samba) instead, as NFS support is not widely available for Windows.


6.2 The NFS Exports Module

On Linux, NFS server configuration is done using the NFS Exports module, which can be found under the Networking category. After entering the module, the main page will display a list of exported directories and the clients that are allowed to access them, as shown in Figure 6.1.

Figure 6.1. The NFS Exports module.

Most Linux distributions come with the programs required for NFS file sharing installed by default. If Webmin detects that they are missing from your system, however, an error message will be displayed when you enter the module. If that happens, you will need to install the nfs-server or nfs package from your distribution CD or website.


6.3 Exporting a Directory

Only directories on local filesystems can be exported via NFS, so it is not possible to re-export files that have been mounted from another NFS server. It is also not possible to export directories from non-UNIX filesystems such as vfat, ntfs or iso9660. If an exported directory has mount points under it, files under those mount points will not be accessible by NFS clients. So if you exported the root directory / and it has a separate filesystem mounted at /home, you would need to also export /home and clients would need to mount it in order to see the files under it.

The steps for exporting a directory are:

  1. Click on the Add a new export link on the main page of the module. This will take you to a form for entering the details of the export, as shown in Figure 6.2.

    Figure 6.2. The new NFS export form.

  2. Enter the directory that you want to share in the Directory to export field.

  3. Unless you want the export to be unavailable, make sure the Active? option is set to Yes.

  4. The Export to option allows you to choose which clients will have access to the directory. The possible choices are:

    Everyone Any system that can connect to yours over the network will be able to mount the directory. Be very careful with this choice, as it may allow anyone on the Internet to access your files.

    Host(s) Only the single specified host or IP address will be allowed. You can also enter a wildcard hostname like *.foo.com for this option to allow all hosts from a domain. However, if you want to export a directory to several specific client hosts then the only solution is to create multiple exports of the same directory, each with a different hostname in this field.

    WebNFS clients WebNFS is a rarely used protocol for accessing NFS exports over the Internet. Don't use this option unless you know what you are doing, as it may allow anyone to access your files.

    Netgroup A netgroup is a list of hosts that is defined on an NIS server. Unfortunately, your system must be an NIS client for this to be useful.

    Network and Netmask All hosts on the specified network will be allowed to connect. To allow all hosts with IP addresses from 192.168.1.0 to 192.168.1.255, you would enter 192.168.1.0 for the network, and 255.255.255.0 for the netmask.

  5. If you want to prevent clients from modifying or creating files in the exported directory, set the Access mode option to Read only.

  6. If exporting only to trusted systems, set the Trust remote users option to Everyone.

    If you want to ensure that clients only have the permissions of a single UNIX user, however, set Trust remote users to Nobody and enter the user and his primary group into the Treat untrusted users as and Treat untrusted groups as fields respectively. This can be very useful if exporting to a client workstation that is used by single user.

  7. Click the Create button to save the export. If you have made any mistakes in any of the fields, an explanatory error message will be displayed. Otherwise, the browser will return to the list of exports.

  8. Click the Apply Changes button to make your new export active.

Allowed clients should now be able to mount the exported directory. If not, check your system's error logs for messages from the NFS server processes that explain why the client is being rejected.


6.4 Editing or Deleting an NFS Export

All the details of any existing NFS export can be edited at any time by following these steps:

  1. On the main page of the module, click on the client under the Exported to column that you want to edit. If a single directory is exported multiple times to different clients, each one must be edited individually.

  2. On the export editing form (which is almost identical to Figure 6.2), change any of the options including the directory to share.

  3. If you want to delete the export, click the Delete button at the bottom right of the page. Otherwise, click Save to save your changes. Either way, your browser will return to the module's main page.

  4. Click the Apply Changes button to make the changes active.


6.5 NFS on Solaris

On Solaris, NFS exports are managed by the separate NFS Shares module. Because Solaris uses a different file (/etc/dfs/dfstab) and file format for storing exports, the module's user interface is different to that of the Linux module. Figure 6.3 shows the main page of the NFS Shares module. As you can see, exports are configured by directory instead of by client.

Figure 6.3. The Solaris NFS Shares module.

To add a new NFS export on Solaris, follow these steps:

  1. Click on the Start sharing a new directory link, which will take you to a form for entering the details of the new export.

  2. Enter the directory that you want to share in the Directory field.

  3. Fill in the Read-only access and Read-write access fields with the hostnames of clients to which you want to grant access. As the names suggest, a host in the Read-only field will not be able to write to or modify files on the server.

    In addition to hostnames, you can also enter networks using the format @192.168.1 or @192.168.1/24, NIS netgroups or even DNS domains like .foo.com (the leading dot indicates an entire domain).

  4. By default, the root user on clients will have only limited access to files on the server. To give root on some clients' full file access privileges, enter their hostnames, networks, netgroups, or domains into the Root access field.

  5. Click the Save button at the bottom of the page to create the export. Unless you have made a mistake on the form, your will be returned to the list of exported directories.

  6. Click the Apply Changes button to make your new export active.

Existing NFS exports can be edited by simply clicking on a directory on the main page of the module. The same form used for creating an export will appear, allowing you to change any of the options. If you want to delete the export, click the Delete button at the bottom of the page. Be sure to click Apply Changes again after making any changes so that they will become active.


6.6 NFS on BSD, MacOS X, and OpenServer

FreeBSD, NetBSD, OpenBSD, OS X, and OpenServer all use the /etc/exports file for storing NFS exports, but its format is different in different operating systems. This means that they use a different NFS Exports module that has its own unique user interface, as shown in Figure 6.4. Exports are configured by directory instead of by client, and you can specify options and allowed clients for multiple directories at once.

Figure 6.4. The BSD NFS Exports module.

To add a new NFS export on one of these operating systems, follow these steps:

  1. Click on the Add a new export link on the main page of the module. A form for entering the details of the new NFS export will appear.

  2. Enter the directories that you want to share into the Directories to export field. Be aware that multiple directories on the same filesystem cannot be exported to the same client separately.

  3. If you want to allow clients to mount subdirectories as well, select the Export subdirectories? option. If this is enabled, however, only one directory can be entered in the Directories to export field and it must be the root of a filesystem.

  4. To give all clients read-only access, set the Read only? option to Yes.

  5. To limit access to a single host or list of hosts, select Hosts / netgroups for the Clients option and enter the hostnames, IP addresses, or netgroups that you wish into the field.

    To limit access to an entire network, select the Network option and entire network address (like 192.168.1.0) and netmask (like 255.255.255.0) into the respective fields.

  6. Click the Save button to create the export and you will be returned to the list of exports on the main page.

  7. Click the Apply Changes button to make your new export active.

Existing NFS exports can be edited by simply clicking on a directory on the main page of the module. The same form as is used for creating an export will appear, allowing you to change any of the options, or click the Delete button to get rid of it. Be sure to click Apply Changes again after making any changes so that they will become active.


6.7 NFS on Irix

Irix has its own unique format for the /etc/exports file that is similar to the BSDs, but not quite the same. It therefore also has its own special version of the NFS Exports module with a slightly different user interface. The main page of the module lists the directories being exported and the hosts they are exported to, in a very similar layout to the BSD NFS Exports module shown in Figure 6.4.

To add a new NFS export on Irix, follow these steps:

  1. Click on the Add a new NFS export link on the main page, which will take you to a form for entering the new export's details.

  2. Enter a directory into the Directory to export field.

  3. Enter the hostnames, IP addresses, and netgroups of clients that you want to grant access to into the Export to hosts/netgroups field. If this field is left empty, any host will be allowed to mount the exported directory.

  4. To prevent all clients for modifying exported files, set the Read-only? option to Yes.

  5. If you want to give read/write access to some clients and read-only access to others, enter the hostnames or IP addresses of the read/write clients into the Read/write access field.

  6. By default, the root user on clients will have only limited access to files on the server. To give root on some clients full file access privileges, enter their hostnames or IP addresses into the Root file access field.

  7. Click the Save button to create the export and you will be returned to the list of exports on the main page, as long as there are no errors in the form.

  8. Click the Apply Changes button to make your new export active.

Existing NFS exports can be edited or deleted by clicking on their directory on the module's main page. If you make any changes, you must click the Apply Changes button to make them active.


6.8 Summary

In this chapter the NFS file sharing protocol has been explained, and the steps to take to share files from one system to others have been documented. You should now know how to export data from a system running any of the supported UNIX variants to any client that can mount NFS filesystems. You should also understand the security implications of sharing files with NFS, and know that it should not generally be used to share files with untrusted clients.


Chapter 7. Disk Quotas

In this chapter, the use of disk quotas to limit the amount of space that individual users can consume is explained.


7.1 Introduction to Disk Quotas

On a system with multiple users, it is often necessary to limit how much disk space each user can take up. Quotas are the mechanism used by UNIX systems to enforce limits on the amount of disk space and the number of files each user (and possibly group) can own. Each file counts towards the quota of the user who owns it, and if group quotas are being used the file counts towards the quotas of its group owner as well. Once a user exceeds his quota, he will not be able to create or enlarge any files until some are deleted.

Quotas are set up on a per-filesystem basis, so that you can have different quotas for different directories on your system. This means, however, that if two directories are both on the same filesystem then they must share the same quotas. Only UNIX filesystems like ext2, ext3, and xfs on local hard disks support quotas—although if your system NFS mounts a remote directory that has quotas enabled, they will be enforced on the server.

Each user or group has two different quotas, one for blocks and one for files. The blocks quota controls how much disk space the user can use and is specified in disk blocks that are typically 1 kB in size. The files quota controls how many separate files the user can create, and is necessary because UNIX filesystems often have a limit on how many files can exist at one time. Without a files quota, a user could create millions of empty files until the filesystems limit was reached and so prevent other users from creating any files at all.

Both the blocks and files quotas have what are called soft and hard limits. The soft limit is the point at which the user is warned that he is close to exceeding his quota, but is still allowed to continue using up disk space. The hard limit is the number of blocks or files that can never be exceeded, and any attempt to do so will result in an error. Both limits are optional, so that you can have only a hard limit and give the user no warning that he is approaching his quota, or only a soft limit and only warn users of quota violations instead of actually enforcing them.

If a user stays above his soft limit but below the hard limit for more than a set period of time (called the grace period), the system will treat him as though he has exceeded the hard limit and prevent the creation or enlargement of any files. Only when the user deletes enough files to drop his usage below the soft limit will it revert to just a warning level.

At the shell prompt, quotas can be viewed using the repquota and quota commands, and edited using the edquota command. The files aquota.user and aquota.group in the mount directory of each filesystem contain the actual records of how much disk space is allocated to each user or group and how much they are currently using. When displaying and setting quotas, Webmin calls the quota commands and parses their output. It does not use system calls or attempt to edit the quota files directly.


7.2 The Disk Quotas Module

Webmin's Disk Quotas module is found under the System category. When you enter the module, a list of all filesystems on which quotas could be or are active is displayed, along with their current active status and whether quotas are configured for users, groups, or both. See Figure 7.1 for an example.

Figure 7.1. The Disk Quotas module.

On most systems that have never used quotas before, none of your filesystems will be listed. This is because quotas must first be enabled in the Disk and Network Filesystems module, as explained in Chapter 5.

If your system does not have the quota manipulation commands installed, Webmin will display an error message on the main page of the module and you will not be able to activate or edit any quotas. All Linux distributions should have a package on their CD or website containing the quota commands.


7.3 Enabling Quotas for a Filesystem

If the main page of the module shows User Quotas Active (or Group Quotas Active) under the Status column for the filesystem, then quotas have already been enabled. If not, to configure and turn on quotas for an ext2 or ext3 filesystem, follow these steps:

  1. If the filesystem already appears in the list on the main page of the module, quotas have already been configured and you can skip to Step 5.

  2. Go to the Disk and Network Filesystems module and click on the filesystem on which you want to enable quotas.

  3. Change the Use Quotas? option to either User only, Group only, or User and Group depending on which kinds of quota you want to enforce.

  4. Click the Save button. If an error appears saying that the filesystem is already in use, just click the Apply to Permanent List button. Quotas can usually be enabled without needing to reboot, and will be automatically reenabled when the system is next rebooted. However, if the next step fails you will need to reboot your system to activate them—this is necessary on some newer versions of Linux.

  5. Back in the Disk Quotas module, your filesystem should now be visible. Click on the Enable Quotas link to activate quotas now.

  6. Assuming all goes well, the browser will return to the list of quotas after a short delay and the Status column will change to User Quotas Active.

For an xfs filesystem, the procedure is slightly different. You must first enable user and/or group quotas in the Disk and Network Filesystems module, and then either reboot or unmount and remount the filesystem. Quotas will be automatically activated at mount time, so there is no need to enable them in the Disk Quotas module.


7.4 Disabling Quotas for a Filesystem

To permanently deactivate quotas for an ext2 or ext3 filesystem, follow these steps:

  1. On the main page of the module, click on Disable Quotas under the Action column for the filesystem.

  2. To prevent quotas from being reactivated at boot time, go to the Disk and Network Filesystems module and click on the filesystem from the list.

  3. Change the Use Quotas? option to No.

  4. Click the Save button. If an error saying that the filesystem is already in use appears, just click the Apply to Permanent List button.

For an xfs filesystem, Step 1 is not necessary (or possible) as quotas are only enabled when the filesystem is mounted. In Step 4, however, when saving the quota settings for the filesystem, it must be unmounted and remounted cleanly for the deactivation to take effect.


7.5 Setting Quotas for a User or Group

The quotas for a user or group can be set or changed at any time on a filesystem that currently has quotas enabled of the correct type. By default, any user or group whose quotas have not yet been set will have no limits at all and thus be able to use up all the disk space on the filesystem.

To set quotas for a user, follow these steps:

  1. From the list of filesystems on the main page of the module, click on the mount point of one on which you want to edit quotas. This will take you to a page listing the quotas for all users on the filesystem, as shown in Figure 7.2.

    Figure 7.2. The list of users and their quotas.

  2. Click on the name of the user you want to edit under the User column, or enter the username into the Edit Quota For field and press the button. Both will take you to a form containing the user's current quota settings and blocks and files used, as shown in Figure 7.3.

    Figure 7.3. The user quota form.

  3. Set the Soft Block Limit and Hard Block Limit fields to the number of blocks to which you want to limit the user, or select Unlimited to not impose any limit. On most filesystems, each block will be 1 kB in size, but this not necessarily always the case.

  4. Set the Soft File Limit and Hard File Limit fields to the number of files that you want to limit the user to owning.

  5. Click the Update button. The new quota settings will take effect immediately.

The procedure for setting group quotas is almost identical. If a filesystem has both user and group quotas enabled, the main page of the module will have two links for each filesystem—one for users, and one for groups.


7.6 Copying Quotas to Multiple Users

If you have a large number of users on your system and want them to all have the same quotas, there is an easier solution than setting each user individually. Instead, you can set the quotas that you want for one user and duplicate his settings to as many other users as you want. The only down side is that quotas are copied on all filesystems, not just a single one.

The steps for copying quotas like this are:

  1. Set the quotas for a single source user, as explained in Section 7.5 "Setting Quotas for a User or Group".

  2. On the main page of the module, enter the username of the source user into the Edit User Quotas page and press the button.

  3. On the page that appears listing the user's quotas on all filesystems, click the Copy Quotas button. This will take you to a form for choosing to which users the quota settings will be copied.

  4. Choose which target users to copy quotas to by selecting one of the options on the form:

    All users on your system Every single user on your system will have the same quota settings. You may want to set quotas for root back to unlimited after doing this.

    Selected users Only the users entered into the field next to this option will have their quotas set.

    Members of selected groups All primary and secondary members of the groups entered into the field next to this option will have their quotas set.

  5. Click the Copy button to copy the quotas for the source user on all filesystems to all target users.

If you are using group quotas, it is also possible to copy the settings for one group to multiple other groups. The options for choosing which groups to copy to, however, are slightly different. The Selected users option is replaced with Selected groups, and the Members of selected groups option is replaced with Groups containing users. The latter option will copy to all groups that have one of the entered users as a member.


7.7 Setting Grace Times

When a user exceeds his soft blocks or files limit, he will still be able to use up disk space up to the hard limit for a certain period of time—the grace period. There are separate periods for the blocks quota and the files quota on each filesystem. Once the period has expired, it will be as though he had reached the hard limit. No more blocks of disk space can be used if it was the blocks quota that was exceeded, or no more files can be created if it was the files quota. Grace periods can also be set for group quotas, and if a filesystem has both user and group quotas enabled, each has their own separate periods.

To set the grace periods for all users on a particular filesystem, follow these steps:

  1. Click on the mount point from the list of filesystems on the main page of the module. This will take you to the list of all users and their quotas, as shown in Figure 7.2.

  2. Click the Edit Grace Times button, which will bring up a form for editing the periods.

  3. For both the blocks and files quotas, select the period and units. When done, click the Update button to save your settings and put the grace periods into immediate effect.

The process for editing the group grace times on a filesystem is almost exactly the same. If a filesystem has both user and group quotas enable, the main page of the module will have two links for each filesystem—one for users and one for groups.


7.8 Setting Default Quotas for New Users

If a filesystem has user quotas enabled, you can configure the blocks and files quotas that will be assigned to new UNIX users created using Webmin's Users and Groups module. As explained in Chapter 4, any time a user is added other modules will be notified so that they can perform additional actions. In the case of the Disk Quotas module, that action can be the setting of an initial quota for the user on multiple filesystems.

To set the default quota for new users on a particular filesystem, follow these steps:

  1. On the module's main page, click on the mount point of the filesystem for which you want to set the default. This will take you to the list of users and their quotas, as shown in Figure 7.2.

  2. At the very bottom of the page is a form in which you can set the default hard and soft blocks and files quotas. When you are done filling it in, click the Apply button.

The same options can be set for UNIX groups created in the Users and Groups module on the group quotas page.


7.9 Other Operating Systems

As disk quotas work in a very similar way across all versions of UNIX, this module appears almost identical on all supported operating systems. The biggest difference is that some UNIX variants do not support group quotas. Some (like Solaris) do not need quotas to be enabled in the Disk and Network Filesystems module before activating them in this module. If there is a quotas option for the filesystem, it determines whether they are enabled at boot time or not.


7.10 Configuring the Disk Quotas Module

The Disk Quotas module has only a few options that can be changed to configure its user interface. To edit them, click on the Module Config link on the main page, which will take you to the standard configuration editing page. The available settings under the Configurable options header are displayed in Table 7.1.

Table 7.1. Module Configuration Options

Maximum number of users or groups to display

When you click on a filesystem on the main page of the module, a full list of users or groups with quotas will be displayed. However, if the number of users exceeds this option, a text box for entering a username to view and set quotas for will be displayed instead.

Sort users and groups by

Normally the list of users with quotas on a filesystem is ordered by disk usage, but by changing this option you can have them ordered by username or just displayed in the order that the repquota command uses.

None of the other options on the configuration page should be changed, as they are set automatically by Webmin based on your operating system type.


7.11 Module Access Control

As described in Chapter 52, it is possible to give a Webmin user access to only part of the functionality of a module. In the case of the Disk Quotas module, you can limit which users and groups quotas can be edited, and on which filesystems they can be edited. This can be useful if there is a person in your organization who is allowed to edit some or all quotas, but not perform any other administrative tasks.

Assuming you have already created a user with access to the module, the steps to follow to set this up are:

  1. In the Webmin Users module, click on Disk Quotas next to the name of the user that you want to restrict.

  2. Set the Can edit module configuration? field to No, so that the user cannot change the commands used for setting and getting quotas.

  3. To restrict the filesystems on which quotas can be assigned, change the Filesystems this user can edit field to Selected and choose them from the list below.

  4. Set the Can enable and disable quotas? field to No, unless the user is responsible for all user and group quotas on the allowed filesystems—otherwise he will be able to turn off quotas for users that he is not allowed to edit.

  5. Change the Can configure quotas for new users? field to No, so that he cannot change the quotas that are assigned to users created in the Users and Groups module. Only if the Webmin user is allowed to edit all quotas on a filesystem should this be left set to Yes.

  6. If you do not want this Webmin user to change grace times, set the Can edit user grace times? and Can edit group grace times? fields to No.

  7. To stop the user from handing out massive disk quotas, set the Maximum grantable block quota and Maximum grantable file quota fields to the maximum blocks and files that can be granted to any one user, respectively. There is nothing, however, to stop him granting quotas to multiple users that add up to more than these limits.

  8. To restrict the UNIX users whose quotas can be edited, change the Users this user can edit quotas for field from All users to one of the other options. The most useful is Users with UID in range, which restricts access to those users whose UIDs lie within the minimum and maximum numbers entered into the fields next to it. It is usually a bad idea to allow the editing of the root user's quotas, as setting it too low may prevent the system from creating important PID, mail, and lock files. You can prevent this by selecting All except users and entering root into the field next to it, assuming that you want to allow the editing of every other user. To stop the Webmin user editing any user quotas at all, select the Only users option and enter nothing into the field next to it.

  9. Similarly, you can limit the groups whose quotas can be edited by changing the Groups this user can edit quotas for field. Naturally, this only has an effect on filesystems that have group quotas enabled.

  10. When done, click the Save button to have the restrictions applied immediately.


7.12 Summary

After reading this chapter you should understand what disk quotas are useful for, and how to enable them on any UNIX system. You should also know the difference between block and file quotas, the connection between quotas and filesystems, and the effects of this on a server with multiple filesystems containing user data. Finally, the differences between and effects of user and group quotas should be clear.


Chapter 8. Partitions, RAID, and LVM

This chapter explains how hard disks are partitioned and how filesystems are created on those partitions. It also covers the use of RAID and LVM to combine multiple partitions into one large filesystem.


8.1 Introduction to Hard Disk Partitions

All hard disks used by Linux and other operating systems on PC hardware are divided into one or more non-overlapping regions called partitions. Sometimes an entire hard disk will be taken up by one partition, but usually your system will have at least two partitions on the primary disk—one for the root filesystem, and one for virtual memory (also known as swap space). As explained in Chapter 5, each partition can be used for either a single filesystem or for virtual memory.

Every partition has a type which identifies the kind of data that it stores. There is a type for Linux filesystems, a type for Linux swap space, a type for Windows filesystems, and many more. Almost every kind of operating system that runs on PC hardware has its own partition type for its own filesystems. When adding new partitions on your system, however, you will very rarely use any types other than those specifically for Linux.

On PC systems, each hard disk can only contain four primary partitions. Because this is often not enough, it is possible for one of those four to be a special extended partition that can contain an unlimited number of logical partitions. If you make use of an extended partition, there is effectively no limit on the number that your hard disk can contain.

Every hard disk is divided into equal-sized cylinders, which represent concentric circles on the surface of the disk. Larger hard disks generally have more cylinders, but due to different drive geometries this is not always the case. Each partition has a starting and ending cylinder and occupies all the space on the disk between them.

Be very careful when changing or reformatting any existing partitions on your system. Because they contain filesystem data, deleting or modifying one could wipe out all your files or make your system unbootable. Webmin tries to prevent this, but it is still possible to do a lot of damage with only a few mouse clicks! Normally you should only need to create or edit partitions when adding a new hard disk to your system.


8.2 The Partitions on Local Disks Module

All disk partition management in Webmin is done using the Partitions on Local Disks module, which can be found under the Hardware category. When you enter the module, a page showing all hard disks and partitions found on your system will be displayed, as shown in Figure 8.1.

Figure 8.1. The Partitions on Local Disks module.

All IDE and SCSI disks are shown, along with their manufacturers and model numbers. If your system has a hardware RAID controller that is supported by the module, the RAID devices will be shown instead of the actual underlying hard disks that make them up. Disks and partitions used for software RAID will be shown, but not the logical or virtual drives that they have been combined into.

For each disk, all partitions on it will be listed showing their type, start and end cylinders and current mount point, or other use. If the partition contains a filesystem, the amount of free disk space will be displayed as well. If a partition is being used for software RAID, the raid device that it is part of will be shown. Similarly, if a partition is part of an LVM volume group, the group name will be displayed under the Use column.


8.3 Adding and Formatting a New Partition

If you have just added a new hard disk to your system and want to make use of it with Linux, you must first partition it and then format the partition as the filesystem type of your choice. The steps for this process are:

  1. Locate your new hard disk in the main page of the Partitions on Local Disks module. It will probably not have any partitions on it, but it may have been set up with one large partition by the manufacturer.

  2. Assuming no partitions exist yet, click the Add primary partition link next to your new hard disk. This will take you to the creation form shown in Figure 8.2 for entering the details of the new partition.

    Figure 8.2. The partition creation form.

  3. If the new partition takes up the entire hard disk, the Extent fields can be left unchanged as they are always automatically filled in to cover all the free space left on the disk. If you want to create more than one partition, however, adjust the extent so that it takes up only part of the disk.

  4. If this partition is for an ext2, ext3, reiserfs, or xfs filesystem, set the Type field to Linux.

    If it is to be for virtual memory, set the Type to Linux swap.

    If it is for software RAID, set the Type to Linux raid.

    If it is for LVM, set the Type to Linux LVM.

    If you are creating the filesystem for some other operating system to use, set the Type field to whatever is appropriate for that OS.

  5. Click the Create button to add the partition. Assuming no errors were detected, you will be returned to the list of disks and partitions on the main page of the module, which should now include the new partition.

  6. If the new partition is to have a Linux filesystem created on it, you must follow the steps in Section 8.4 "Creating a New Filesystem". Virtual memory partitions can be added immediately in the Disk and Network Filesystems module. Partitions for use with RAID can be also be used immediately in the Linux RAID module but you must have created all the partitions that will make up a RAID device before creating it. Partitions that will be part of an LVM volume group can be added immediately using the Logical Volume Management module.


8.4 Creating a New Filesystem

Before a newly created partition can be used to store files, it must first have a filesystem created on it. Filesystems can also be created on partitions that have been used before, perhaps by another operating system. However, be very careful when formatting a partition with a new filesystem, as any files that it used to contain will be lost forever.

The steps for creating a new filesystem are:

  1. On the main page of the module, click on the number of the partition that you want to reformat. This will take you to the partition editing form, as shown in Figure 8.3.

    Figure 8.3. The partition editing form.

  2. Near the bottom of the page is a button labeled Create Filesystem with a menu of supported filesystem types next to it. See Section 5.13 "A Comparison of Filesystem Types" for information on the pluses and minuses of each type. When you have made a selection, click the button and it will take you to a form for selecting options for the new filesystem.

  3. Depending on the type of filesystem chosen, different creation options are available. For ext2 or ext3 filesystems, the only one that you might want to change is Reserved blocks, which determines the amount of disk space reserved for the exclusive use of the root user. The default is 5 percent, which I think is rather wasteful.

  4. Click the Create Filesystem button to format the partition. A page showing the progress of the new filesystem's creation will be displayed, which can take some time for large hard disks.

  5. Assuming that the formatting is successful, you can now use the Disk and Network Filesystems module to mount the new filesystem.


8.5 Partition Labels

Labels are a feature of newer versions of Linux that allow a partition to be identified in the /etc/fstab file by a short name rather than its IDE or SCSI device file, such as /dev/hdb3. Device files can change if you change an IDE drive from one controller to another, change the ID of a SCSI drive, or even add a new SCSI drive with an ID lower than an existing drive. Any of these changes could cause a partition to fail to mount at boot time—possibly making your system unbootable. Partitions with labels can be referred to be label name, however, which does not change even if the device file does.

Some newer Linux distributions use labels by default for filesystems that you create at install time. If you use the Disk and Network Filesystems module on such a system, the Location column for these filesystems will be something like Partition labeled /home.

Only partitions with ext2, ext3 or xfs filesystems on them can be labeled, as the label is stored in the filesystem rather than the partition table. To label an existing filesystem, follow these steps:

  1. On the main page of the module, click on the number of the partition that you want to label. This will take you to the partition editing form, as shown in Figure 8.3.

  2. Assuming the partition is not currently in use, you will be able to enter the new label into the Partition label field. It must be at most 16 characters long—for example /home or root.

  3. After you have entered the label, click the Save button. It will be stored in the filesystem, and the browser will return to the module's main page.

  4. At this point, the Disk and Network Filesystems module can be used to mount the labeled filesystem by label name, as explained in Chapter 5.


8.6 Deleting or Changing a Partition

Once a partition has been created, its size or position on the hard disk cannot be changed using Webmin. The only things you can do are change its type or delete it. Neither are possible, however, if a filesystem on the partition is listed in the Disk and Network Filesystems module—that is, if it is currently mounted or recorded for mounting at boot time.

Changing the type of a partition will not harm the data on it in any way. It may, however, make it unusable by some operating systems or for some purposes.

The steps to change its type are:

  1. On the main page of the module, click on the number of the partition that you want to change. This will take you to the partition editing form.

  2. As long as the partition is not in use, you will be able to select a new type from the Type field and click the Save button.

  3. Once the change has been made, the browser will return to the list of disks and partitions.

Deleting a partition should be done only if you are sure that you want to lose all the data on it. It is the only way to make some changes to the partition table in Webmin, however, such as replacing two small partitions with one larger one. If you are sure that you want to go ahead with the deletion, use the following process:

  1. On the main page of the module, click on the number of the partition that you want to delete, which will take you to the partition editing form.

  2. Click the Delete button, which will only appear if the partition is not in use. This will take you to a page for confirming the deletion.

  3. If you are really sure you want to go ahead, click the Delete Now button. Once the job is done, you will be returned to the main page of the module.

It is theoretically possible to restore a deleted partition by creating a new one with the exact same size and extents.


8.7 Module Access Control

Surprisingly, it is possible to limit the access that a Webmin user has to certain disks in the Partitions on Local Disks module. This could be useful if your system has a removable drive (like a Zip or Jaz drive) that you want users to be allowed to partition with Webmin, while preventing them from reformatting the primary hard disk.

Once a user has been granted access to the module, the process to restrict the disks that he can access includes the following steps:

  1. In the Webmin Users module, click on Partitions on Local Disks next to his username. This will bring up the module access control form.

  2. Change the Disks this user can partition and format field to Selected, and choose the disks that the user should be allowed to partition and create filesystems on from the list below.

  3. To stop the user seeing disks on the main page that he cannot manage, change the Can view non-editable disks? option to No.

  4. Finally, click the Save button to activate the access control restrictions.

Just being able to partition and format a disk is not particularly useful, unless it can be mounted as well. The Disk and Network Filesystems module has no support for access control restrictions, because giving a user the rights to mount a filesystem would open up several security holes. A better solution is to set up an automounter filesystem so that removable devices can be mounted by just entering a special mount-point directory.


8.8 Other Operating Systems

Solaris is the only other operating system that has a module for managing disks and partitions, however there are several differences between Linux and Solaris:

  • Every Solaris disk has exactly 8 partitions, some of which may have no extent if they are not being used. Partitions never need to be created or deleted and there are no extended or logical partitions.

  • When editing a Solaris partition, its extents can be changed without needing to delete and recreate it. This will, however, almost certainly result in the loss of data on the partition.

  • Every partition has a type that indicates what it is used for. The root type is usually for the root directory filesystem, the swap type is for virtual memory, the usr type is for other filesystems, and the unassigned type is for empty partitions.

  • Each partition has two flags—Mountable and Writable—which indicate whether it can be mounted or written to, respectively.

  • The only filesystem supported on Solaris partitions is ufs—the native UNIX filesystem type.

  • Partition labeling is not supported on Solaris.

  • When editing the module access control, there is no Can view non-editable disks? option.

The RAID and LVM modules explained below are not available on Solaris or any other operating system.


8.9 Introduction to RAID

RAID (which stands for Redundant Array of Inexpensive Disks) is a method for combining multiple partitions on different disks into one large virtual device, also known as a RAID array. This has several advantages:

  • You can create a single filesystem that is as big as all your existing hard disks, instead of needing to mount each one separately at a different mount-point directory.

  • In most cases, reading to and writing from a RAID device is faster than accessing a single disk, because the data being read or written is spread across multiple drives.

  • With the right configuration, data on a RAID device can survive even if any one of the hard disks fails. This is done by spreading redundant information across all drives, and comes at the cost of some disk space.

The different types of RAID configuration are called levels. The levels supported by Linux are:

Concatendated or Linear In this mode, all the partitions in the RAID array are combined end-to-end into one large virtual device. Data written to the device will fill up the first disk and then go on to the second disk, and so on. Linear mode does not generally make data access any faster, as all the blocks of a file being read or written are likely to be next to each other on the same disk.

RAID 0 or Striped As in linear mode, multiple partitions in striped mode are also combined into one large device. Data written to the array, however, will be spread evenly across all disks so that reading or writing a single large file is much faster. Ideally, if you had 5 disks in your striped RAID array, then accessing data would be 5 times faster. The only problem with this mode is that it does not deal well with disks that are not all the same size—any space on a disk that is larger than the rest will still be used, but only at its normal speed.

RAID 1 or Mirrored In mirrored mode, every partition in the array contains exactly the same data. This means that in the event of a disk failure, your data is safe even if only one disk survives. The down side is that under normal conditions most of the disks are wasted and the usable space on the array is only as big as the smallest partition. Reading from a mirrored array is as fast as reading from a striped array, but writing will be as slow as the slowest disk due to the need to write all data to all disks simultaneously.

RAID 4 or Parity Parity mode is rarely used, as it offers no real advantage over RAID 5. It provides protection against a single disk failure and increases read speed but not write speed. A RAID 4 array can survive the loss of any one disk because it dedicates one disk to the storage of parity information, which can be used to re-construct data on other disks if one of them fails. Because all writes to the array cause a write to this disk, it becomes a bottleneck that slows done the entire array.

RAID 5 or Redundant This is the most useful RAID mode as it provides protection against a disk failure, increases read and write speeds, and combines multiple partitions into one large virtual device. A RAID 5 array can survive the loss of any one disk without the loss of all data, but at the expense of sacrificing some space on all the disks for storing redundant information. It is faster than linear mode, but not quite as fast as striped mode due to the need to maintain redundancy.

This chapter only covers the RAID configuration software on Linux. If your system has a separate RAID controller card or external array, you will need special software to set it up. Virtual RAID devices on hardware controllers will show up in the Partitions on Local Disks module for partitioning, just like any real hard disk would. They will not be visible or configurable in the Linux RAID module.


8.10 The Linux RAID Module

This module allows you to create, format, and delete RAID arrays on your Linux system. Like the other hard-disk related modules, it can be found under the Hardware category. When you enter the module, the main page will display existing RAID devices (if any), as shown in Figure 8.4.

Figure 8.4. The Linux RAID module.

If Webmin detects that the commands used to set up RAID are missing from your system, an error message will be displayed on the main page of the module. Most Linux distributions, however, should have a package on their CD or website containing the RAID commands. A different error will be displayed if your Linux kernel has not been compiled with RAID support. In this case, you may have to recompile the kernel with RAID supported turned on.

Assuming all the necessary packages have been installed, adding a new RAID device is relatively easy. The steps to follow are:

  1. In the Partitions on Local Disks module, create a partition on each disk that you want to use for RAID. Existing partitions can also be used, as long as they do not contain any data that you do not want overwritten. A disk that is partially used for some other purpose can also have a new partition added for RAID use, although this may negate some of the performance benefits.

    Every partition that is going to be part of the RAID array should have its type set to Linux raid. Unless you are using linear mode, all partitions should be the same size so that space on the larger partitions is not wasted.

  2. At this point, it may be necessary to reboot your system. Some Linux kernels can only detect new partitions at boot time. If you do not reboot and the partition is not detected, the creation of the RAID device will fail.

  3. On the main page of the module, select the RAID level that you want to use and click the Create RAID device of level button. This will take you to a form for selecting the partitions to be part of the array and other options, assuming Webmin detects at least one unused partition on your system.

  4. The Partitions in RAID option will list all hard disk partitions that are not currently in use for possible inclusion in your RAID device. It will also list any other RAID devices that are not in use, allowing you to theoretically create an array that contains other arrays. Select all the partitions that you want to be part of your new RAID device.

  5. The Force initialization of RAID? option should be set to Yes if any of the selected partitions have been used before for other purposes. Otherwise, the creation of the new array will fail if a filesystem is detected on any of the partitions.

  6. Click the Create button to set up the new array. If everything is successful, you will be returned to the main page of the module, which should now include your new RAID device.

  7. If you want to create a filesystem on the new device so that it can be mounted, click on its icon to go to the device status page. If the RAID device is to be used for virtual memory, as part of an LVM volume group or as part of another RAID array, then this is not necessary.

  8. Select the type of filesystem you want to create from the menu at the bottom of the page and click the Create filesystem of type button.

  9. Select any options for the new filesystem, as explained in Section 8.4 "Creating a New Filesystem". When done, click the Create button. A page showing the progress of the new filesystem's creation will be displayed, which can take some time for large arrays.

  10. Assuming that the formatting is successful, you can now use the Disk and Network Filesystems module to mount the new filesystem.

Existing RAID devices that are not in use can be deleted or deactivated by clicking on their icon on the main page of the module, and pressing the Delete button. Deleting a device will cause any data stored on it to be lost forever.


8.11 Introduction to LVM

LVM (Logical Volume Manager) is a powerful Linux feature that adds a layer of abstraction between the physical partitions on your system and the filesystems that they store. Partitions managed by LVM are called a physical volumes, which are combined together to form volume groups. From each volume group logical volumes can be created, on which filesystems are actually stored. The size of each volume group is the sum of the sizes of all its physical volumes. This space can be handed out to as many logical volumes as will fit into it, so that it could contain many small logical volumes or one huge one that spans multiple physical volumes (and thus partitions).

At first glance, LVM may not seem any more powerful than RAID, which can also combine multiple partitions into one large filesystem. It does, however, give you far more freedom to carve up disks into separate filesystems that may take up part of a disk, several disks, or anything in between. The only down side is that LVM does not support redundancy as RAID does in Levels 1 and 5.

The most useful feature of LVM is the ability to resize logical volumes and the filesystems within them up to the amount of free space in the volume group. Additional physical volumes (such as newly installed hard disk partitions) can be added to an existing volume group, subsequently increasing the amount of free space. For example, if your system has two hard disks whose partitions are combined to form a volume group, you might have a filesystem on a logical volume that is as big as both disks combined. If you begin to run out of disk space and want to enlarge the filesystem, you can install a new hard disk, add it to the volume group, and then enlarge the logical volume to make use of all the new free space! This is far more convenient than mounting the new hard disk as a subdirectory somewhere under the existing filesystem.

Figure 8.5. An overview of the logical volume manager.

Physical volumes can also be removed from an LVM volume group, as long as there is enough free space in the group to store data that used to be on the physical volume. This means that you could theoretically remove a small hard disk from your system and replace it with a larger one, without having to manually copy files around.


8.12 The Logical Volume Management Module

Webmin's Logical Volume Manager module allows you to perform almost all of the tasks that can be done using the command-line LVM tools. When you enter the module from the Hardware category, the main page shows all existing volume groups and their physical and logical volumes, as shown in Figure 8.6.

Figure 8.6. The Logical Volume Management module.

Because the module depends upon the LVM tools such as vgcreate, the main page will display an error message if they are not found. They should, however, be available on your distribution CD or website if you are running a reasonably recent version of Linux. It also checks to see if your kernel supports LVM by looking for the /proc/lvm directory. If support is missing, you will need to load the lvm-mod kernel module with the command modprobe lvm-mod or recompile your kernel with LVM support.


8.13 Creating a New Volume Group

Assuming you have at least one partition free for use by LVM, setting up a new volume group is easy. The process to follow is:

  1. In the Partitions on Local disks module, change the types of any partitions that you want to include in the volume group to Linux LVM. Trying to use partitions of any other type will fail.

  2. Back in the Logical Volume Manager module, click on the Add a new volume group link, which will take you to the volume group creation form.

  3. Enter a name for your new volume group in the Volume group name field. This should be short and contain no spaces, like data_vg.

  4. Select the initial partition to be included in your volume group with the Initial physical device field. Only partitions or RAID devices that Webmin determines are not in use will appear in the list. You also specify a partition by device file name by selecting the Other option and entering the file name into the field next to it.

    If Other is the only option available, Webmin has not detected any partitions free for use by LVM.

    Be aware that any data on the partition or device that you select will be lost forever, even if the volume group is not actually used.

  5. Click the Create button. If all goes well, you will be returned to the main page of the module and your volume group with its initial physical volume will be displayed.

  6. To add more physical volumes to your new volume group, see Section 8.14 "Adding and Removing a Physical Volume".


8.14 Adding and Removing a Physical Volume

Once a volume group has been created with its initial physical volume, you can add new partitions or RAID devices to it at any time. This will increase the amount of free space in the volume group, and allow you to create more logical volumes or extend existing ones. To add a physical volume, follow these steps:

  1. If you are adding a disk partition, use the Partitions on Local Disks module to change its type to Linux LVM.

  2. On the main page of the Logical Volume Management module, click on Add a physical volume to the group inside the section for the appropriate volume group. This will take you to a page for selecting the partition or RAID device to add.

  3. Choose the one that you want to add from the list in the Disk device field, or select the Other option and enter a device file manually. Only partitions that Webmin thinks are not in use elsewhere will be available for selection.

    Be aware that any data on the partition or device that you select will be lost forever.

  4. Click the Add to volume group button to add the physical volume. If successful, you will be returned to the main page of the module.

It is also possible to remove a physical volume from a volume group, as long as there is enough free space in the group to store all the data that was previously on the physical volume. The steps for doing this are:

  1. On the main page, click on the icon for the physical volume that you want to remove.

  2. Click the Remove from volume group button. Assuming that removal is possible, there may be a delay as data is shifted to other physical volumes.

  3. Once the removal is complete and the browser returns to the list of volume groups, you can immediately use the partition for some other purpose. It can be formatted with a filesystem and mounted, included in a RAID group, or even added to another volume group.


8.15 Creating and Deleting a Logical Volume

As long as a volume group has some free space, you can add a logical volume to it at any time. A logical volume can be any size, but the size will always be rounded up to a multiple of the allocation block size used by the volume group (4 MB by default). You can see the current block size, blocks allocated, and total blocks by clicking on a volume group's icon on the main page of the module.

The steps for adding a new logical volume are as follows:

  1. On the list of volume groups, click on the Create a new logical volume link next to the volume group to which you want to add it.

  2. In the Volume name field, enter a name for your new logical volume. This should be short and contain no spaces, like data_lv.

  3. For the Volume size field, enter the number of kilobytes to allocate to this volume. Whatever you enter will be rounded up to the nearest Allocation block size shown below.

    By default, this field will be set to the total amount of free space in the volume group.

  4. If the Allocation method option is set to Contiguous, all space reserved for this logical volume will be in one large block on disk. This can speed up access to the data but is inflexible if you are adding and removing logical volumes causing the volume group to become fragmented. Therefore, it is usually best to leave the option set to Non-contiguous.

  5. The Volume striping option controls how data for the logical volume is laid out on disk. The Disabled option is similar to linear mode in RAID, while the Stripe across option is similar to striped mode. See Section 8.9 "Introduction to RAID" for a more detailed explanation.

  6. When all the fields are set to your satisfaction, click the Create button. As long as all fields have been filled in properly and there enough free space in the volume group, the browser will return to the main page of the module and a new icon for your logical volume should be visible.

  7. Assuming you want to mount the new logical volume somewhere, you will first need to create a filesystem on it. To do this, click on its icon on the main page of the module that will take you to the logical volume editing page.

  8. Select the type of filesystem you want to create from the menu at the bottom of the page, and click the Create filesystem of type button.

  9. Select any options for the new filesystem, as explained in Section 8.4 "Creating a New Filesystem". When done, click the Create button. A page showing the progress of the new filesystem's creation will be displayed, which can take some time for large volumes.

  10. Assuming that the formatting is successful, you can now use the Disk and Network Filesystems module to mount the new filesystem.

Existing logical volumes can be deleted from their volume group to free up space or reduce the volume group size. Before you can delete a logical volume, it must have been unmounted in the Disk and Network Filesystems module. When it is deleted, any data that it contained will be lost forever.

To remove a logical volume, follow these steps:

  1. Click on its icon on the main page of the module, which will take you to the logical volume editing form.

  2. Click the Delete button. This will bring up a page asking if you are really sure about deleting it.

  3. Click Delete Now to confirm. Once it has been removed from the volume group, your browser will return to the main page of the module. The space freed up can be reused for another logical volume immediately.


8.16 Resizing a Logical Volume

One of the most powerful features of LVM is its ability to enlarge or reduce existing logical volumes, even if they contain a filesystem. Webmin, however, only supports the resizing of ext2, ext3, reiserfs and jfs filesystems at the moment—logical volumes formatted with other filesystem types (such as xfs) cannot be resized without losing data. You must also unmount a logical volume before resizing it, and then remount afterwards—there is no way to resize a filesystem that is currently in use.

As would be expected, a logical volume can only be enlarged by the amount of free space in its volume group. When shrinking a logical volume containing a supported filesystem, its size cannot be reduced to less than the space occupied by files on the filesystem. Currently, jfs filesystems cannot be shrunk at all—they can only be enlarged.

The steps to follow for resizing a logical volume are:

  1. In the Disk and Network Filesystems module, make sure the logical volume is unmounted.

  2. On the main page of the Logical Volume Management module, click on its icon. This will take you to the volume editing form.

  3. Enter a new size in kB in the Volume size field. The size cannot be increased by more than the amount of free space in the volume group, or reduced to less than the space occupied by files on the filesystem, unless you plan to recreate the filesystem.

  4. Click the Save button. When resizing a volume containing an ext2, ext3, reiserfs, or jfs filesystem, you will be returned to the main page of the module as long as no problems are encountered.

    If the filesystem could not be shrunk below the amount of space occupied by its files, however, an error page will appear offering you the option of resizing anyway. Clicking the Resize Logical Volume button will force a resize, but any files on the volume will be lost and you will need to re-create the filesystem.

    If you are resizing a logical volume containing some other type of filesystem (such as xfs), or one whose contents are unknown to Webmin, a page asking you to confirm the resize will appear. If you click the Resize Logical Volume to go ahead, any filesystem on the volume will be lost and need to be created again.

  5. If the filesystem was resized successfully, you can remount it in the Disk and Network Filesystems module. Otherwise, you will need to recreate it as explained in Section 8.15 "Creating and Deleting a Logical Volume".


8.17 Creating a Snapshot

A snapshot is a special kind of logical volume that is actually a temporary, read-only copy of another volume. When a snapshot is created, it appears to contain a copy of all the data in the source volume, so that if the source is changed, the snapshot remains the same. In order to save on disk space, the snapshot really only stores data that has changed on the original logical volume since it was created. This makes it possible to create a snapshot copy of a 100 MB of volume even if the volume group has less than 100 MB of free space.

Snapshots are useful for quickly freezing a filesystem at some point so that it can be safely backed up. A snapshot can even act as a kind of backup itself, to which you can revert if something goes wrong with files on the original volume. The only down side is that a snapshot can only be safely created when the source logical volume is unmounted, as a mounted filesystem will not be in a valid state for copying.

To create a snapshot, follow these steps:

  1. In the Disk and Network Filesystems module, unmount the filesystem on the original logical volume, if necessary.

  2. Back in the Logical Volume Management module, click on the Create a new snapshot link in the same volume group as the original volume.

  3. On the snapshot creation form, enter a short name without spaces into the Volume name field—data_snap, for example.

  4. For the Volume size, enter the amount of disk space (in kB) that you want to allocate to this snapshot for storing differences made to the original logical volume after the snapshot was created. If the amount of space is too small and too many changes are made to the logical volume, I/O errors will start to occur when reading files in the snapshot filesystem.

  5. For the Snapshot of logical volume field, select the logical volume of which you want to make a copy.

  6. Click the Create button to create the snapshot and return to the main page. An icon for your new snapshot will appear among the other logical volumes in its volume group.

  7. In the Disk and Network Filesystems module, remount the filesystem on the original logical volume. You can mount the filesystem on the snapshot separately here as well.

Once created, a snapshot can be resized in the same way that you would resize a normal logical volume. This does not, however, resize the filesystem on the snapshot—instead, it changes the amount of space available for storing differences between the snapshot and original volume group. A snapshot can also be deleted, assuming the filesystem on it has been unmounted first. Any data in the snapshot will be lost, but since it is just a copy of another volume this isn't likely to matter much.


8.18 Summary

This chapter has covered the three low-level devices that can be used by Linux systems to store filesystems. The simplest are regular disk partitions, which are just a single section of a hard disk. RAID devices are more complex, as they combine multiple partitions into single, large virtual partitions. LVM, the most complex and powerful of all, can be used to create volumes that cover multiple partitions and that contain filesystems that can be expanded as more space is added. All of these device types appear the same to users when they have been initialized with a filesystem and mounted on a directory somewhere.

After reading this chapter, you should understand the differences between them in terms of simplicity, reliability, and flexibility. You should be able to choose the best one to use for your own system based on the number of hard drives that you have and the importance of your data.


Chapter 9. Bootup and Shutdown

This chapter explains methods for starting servers and services at boot time, and tells you how to use Webmin to run your own commands at startup.


9.1 Introduction to the Linux Boot Process

The very first thing that happens when a PC starts up is the loading of the BIOS from ROM. The BIOS (Basic Input/Output System) performs memory and other hardware checks, and then loads a tiny piece of code from the first part of one of the system's hard disks—known as the master boot record or MBR. This piece of code is called a boot loader, and is responsible for displaying a menu of operating systems to the user and loading one of them. There are several boot loaders available for Linux, such as LILO and GRUB, but they all do basically the same thing.

Once the kernel has been loaded, it mounts the root filesystem and runs the init program, which is responsible for managing the rest of the boot process. It reads the /etc/inittab file and executes the commands it specifies—the most important of which begins execution of bootup scripts. Each of these scripts is responsible for a single task, such as initializing network interfaces, starting a web server, or mounting other filesystems. The scripts have a fixed order in which they must execute because some of the later scripts are dependant on earlier ones. For example, network filesystems cannot be mounted until network interfaces have been enabled.

At shutdown time, a series of scripts is also run to shut down servers and unmount filesystems. These scripts also have a fixed order so that the deactivation of networking and other basic services happens last. If requested and supported by the hardware, the last step in the shutdown process will be the powering off of the system by the kernel.

When a Linux system starts up, different scripts are executed depending on the runlevel in which it is starting. The runlevel can be set by the boot loader or by the /etc/inittab file.

The commonly used runlevels are:

5 – Graphical mode All servers and services will be started, and X started to display a graphical login prompt on the console.

3 – Multi-user mode All servers and services are started, but only the normal text login is available on the console.

2 – Multi-user mode without NFS Almost all servers and services are started, but NFS filesystems are not mounted.

1 – Single user mode Only the most basic system initialization is done, and a root shell opened on the console. This runlevel is useful if some bootup script is failing and making your system unbootable.

See Section 9.9 "The SysV Init Configuration Module" for information on how to change the bootup runlevel.

The directory /etc/rc.d/init.d is usually used to store the actual bootup shell scripts. The scripts that are started or stopped in each runlevel are determined by symbolic links from the /etc/rc.d/rc X.d directory, where X is the runlevel number. Each symbolic link has a name like S YY scriptname, in which YY is the order that the script is started in the boot process—the lower the number, the earlier the script starts. So /etc/rc.d/rc5.d/S10network would be run in runlevel 5 before /etc/rc.d/rc5.d/S80sendmail.

Not all Linux distributions use these directories for their bootup scripts. Some use /etc/init.d for the actual script files, while others (such as older versions of SuSE) put everything in the /sbin directory. Fortunately, /etc/rc.d seems to be becoming the standard base directory in newer distributions. Of course, if you are using Webmin you don't have to worry about the locations of any of these directories as it always knows where they are.


9.2 The Bootup and Shutdown Module

This module allows you to create and edit the scripts that are run at bootup and shutdown, called actions by the module. It can be found under the System category in Webmin, and when you enter it, the main page will display a list of all available actions, whether or not they are started at boot, and a short description for each. See Figure 9.1 for an example.

Figure 9.1. The Bootup and Shutdown module.

Each Linux distribution has its own set of standard action scripts, so on one system the script httpd may start the Apache Web server, but on another in may be called apache. You should, however, be able to get a good idea of what each script does from its description.


9.3 Configuring an Action to Start at Bootup

If some server on your system such as Apache or Squid is not currently being started at boot time, you can use this module to change that. On most Linux distributions, every server that comes with the distribution will have its own bootup action script, but not all will be enabled by default. To configure an action to start at boot time, the steps to follow are:

  1. On the main page of the module, click on the name of the action that you want to enable. This will take you to the action editing page, as shown in Figure 9.2.

    Figure 9.2. The action editing form.

  2. Change the Start at boot time? option from No to Yes.

  3. Click the Save button, and your browser will return to the list of actions on the main page.

If there is a server that is currently being started at boot time that you want to disable, just follow the same steps but set the Start at boot time? option to No instead.


9.4 Starting and Stopping Actions

Even though action scripts are normally started at boot time and stopped at shutdown, you can start or stop them at any time using Webmin. Many action scripts can also perform additional functions, such as showing the status of a server or reloading its configuration. To start or stop an action, do the following:

  1. On the main page of the module, click on the name of the action. This will take you to the action editing form shown in Figure 9.2.

  2. At the bottom of the page (in the middle) will be a row of buttons, each for running an action script to perform some function. Depending on the script there may be different buttons available, but some of the most common are:

    Start Now Immediately starts the server or service. On some versions of Linux, this will do nothing if the action has already been started and the server is already running.

    Stop Now Stops the server or service. In some Linux versions, this will do nothing unless the action has already been started.

    Restart Now Stops and restarts the server. In many cases, this will do nothing if the action has not been started yet.

    Reload Now Where available, this function tells the server started by the action to reread its configuration files.

    Show Status Just displays a message telling you if the server is running or not, and if so what its PID is.

  3. After you click the button for the function that you want to perform, a page showing the output from the action script will appear. This should indicate whether the action was performed successfully or not.


9.5 Adding a New Action

If you have a command that you want run at boot time, creating a new action script is the best way to set it up. Servers like Apache or Qmail that have been compiled and installed manually do not have actions, so you will need to create one that runs whatever command is necessary to start the server.

To create your own action, follow these steps:

  1. On the main page of the module, click the Create a new bootup and shutdown action link above or below the list of existing actions. This will take you to the form shown in Figure 9.3 for entering the code for your new action script.

    Figure 9.3. The action creation form.

  2. In the Name field, enter a short name for the action like qmail. Every action must have a unique name.

  3. In the Description field, enter a few lines of text to describe your action—maybe something like Start the Qmail mail server. This will show up on the main page of the module under the Description column.

  4. The Bootup commands field must be filled in with the shell commands that you want to run when your action is started at boot time. For example, if you wanted to start Qmail you might enter /var/qmail/rc.

  5. The Shutdown commands field should be filled in with commands that you want to run when your action is stopped. For example, to stop Qmail you might enter killall –9 qmail-send.

  6. Assuming you want your action to run at boot time, set the Start at boot time? option to Yes.

  7. Finally, click the Create button to save the new action. Webmin will create a script in the /etc/rc.d/init.d directory combining the commands you entered with a standard wrapper to make a valid action script. Your action will be set to run in the current runlevel, with order number 99 so that it is run last. If you want to control exactly which runlevels and in what order your action is run, see the Allow selection of individual runlevels option in Section 9.7 "Configuring the Bootup and Shutdown Module".

After an action has been created, you can edit the start and stop commands by following this process:

  1. On the main page of the module, click on the name of your action. This will take you to the action editing form shown in Figure 9.2.

  2. In the Action script text box, look for a line like 'start'). The commands that are run at boot time will come after it, down to the a line containing just ;;. Edit them as you wish, but leave the surrounding code alone.

    Similarly, the commands that are run when the action is stopped are between 'stop') and ;;. Changing any other part of the script is a bad idea unless you know what you are doing.

  3. Click the Save button to apply your changes.

Any of the existing action scripts can be edited using Webmin, not just your own creations. Be careful editing them, as they may have a format totally different to the scripts created by Webmin.


9.6 Rebooting or Shutting Down Your System

Linux systems should always be rebooted or shut down using the appropriate commands, rather than simply turning off the power or hitting the reset button. If not, you may lose data on your local hard drives and will certainly have to wait through a lengthy filesystem check with fsck at boot time if using a non-journaling filesystem.

To reboot, simply do the following:

  1. At the bottom of the main page of the Bootup and Shutdown module, click the Reboot System button. This will take you to a page confirming if you really want to reboot.

  2. Click the Reboot System button on the confirmation page. The shutdown process will start immediately, and if you are logged in at the console your session will be logged out. After all the shutdown scripts have been run, the system will bootup again as explained in the introduction.

The process for shutting down is almost identical—just use the Shutdown System button at the bottom of the page instead.


9.7 Configuring the Bootup and Shutdown Module

Like most modules, Bootup and Shutdown can be configured by clicking on the Module Config link on the main page. This will take you to the standard configuration editing page, on which the settings in Table 9.1 are available under the Configurable options header.

None of the other options on the configuration page should be changed, as they are automatically set by Webmin based on your operating system type.


9.8 Other Operating Systems

Many other UNIX operating systems—but not all of them—use the system of bootup scripts used by Linux. Even those that do use it have some slight differences in their implementation, and almost all use different directories for storing the actual scripts and links.

Sun Solaris, HP/UX, SCO UnixWare, SCO OpenServer, CompaqTru64/OSF1, and SGI Irix All these operating systems use action scripts that are very similar to Linux, but are stored in different directories. Because those that come with the system do not have descriptions, the main page of the module will just display action names by default.

Table 9.1. Module Configuration Options

Allow selection of individual runlevels

If set to Yes when editing or creating an action, you will be able to enter the exact order number for the action in each runlevel. Because this is rather complex, this option is set to No by default so that Webmin only displays a single Start at boot? option when creating or editing an action.

Display actions with descriptions

If this option is set to Yes, and show all runlevels, the main page will show exactly which runlevels each action is started in, along with the description.

If set to Yes, each action will only show whether it is started at boot or not, and its description. This is the default on most systems.

If set to No, the main page will display only a table of action names with no descriptions or boot information. This can be useful if you have a lot of actions or your operating system does not include descriptions in the action scripts.

Show boot order of actions?

If Yes is selected, the main page will include the boot order of each action in the current runlevel, or in some other runlevel. The default No option hides this information.

Show current status of actions

On some Linux distributions, the standard action scripts can report the status of the servers that they start. This option allows Webmin to display this status information in various places.

If set to No, the status of actions is never displayed unless you click the Show Status button when editing an action.

If set to On action page only, Webmin will display the current status of an action when you edit it by selecting it from the main page of the module.

If set to On index and action pages, the main page of the module will display the current status of every single action. This provides a lot of information, but can be very slow.

Sort actions by

When Boot order is chosen, actions on the main page are listed in the order that they will be started by your system in the current runlevel. The default of Name causes them to be sorted by name instead.

FreeBSD, NetBSD and OpenBSD The BSD family of operating systems does not use action scripts at all, relying instead on a fixed set of scripts that are run at boot time. One of these scripts (/etc/rc.local) allows system administrators to add their own commands to be run at boot time.

On any of these operating systems, the main page of the module will just display a form for editing the rc.local file, above the Reboot System and Shutdown System buttons. To add any commands that you want run at boot time, just enter them into the text box and click the Save button.

IBM AIX AIX is very similar to the BSD operating systems in that it does not have action scripts. Instead, the file /etc/rc can be edited to add additional commands to be run at boot time, using the form on the main page of the module.

Apple MacOS X Apple's version of UNIX uses a totally different set of files for storing actions to be run at boot time than any other supported operating system. Separate action scripts still exist, but the user interface in this module for viewing and editing them is quite different.

If your operating system is not in this list, then the Bootup and Shutdown module does not support it at all, therefore the module icon will not appear in Webmin.


9.9 The SysV Init Configuration Module

As explained in the introduction to this chapter, the very first file read by the system to determine which commands to run at boot time is /etc/inittab. It is read by the init program, which is the first process to be run after the Linux kernel finishes loading, and remains running until the system is shut down. The inittab file specifies which runlevel to boot into, the commands to be run to start all of the action scripts, processes to begin displaying text and graphical login prompts, and commands to run in the case of an impending power failure.

The SysV Init Configuration module, found under the System category in Webmin, can be used to edit any of these commands. As they are critical for ensuring that your system boots up properly, however, editing them is a bad idea unless you really know what you are doing. The only thing that you might want to change is the bootup runlevel so your system does not display an unnecessary graphical login prompt if it is not needed.

To change the initial runlevel, follow these steps:

  1. Enter the SysV Init Configuration module. The main page will display a list of commands and the runlevels and situations in which they are executed, as shown in Figure 9.4.

    Figure 9.4. The SysV Init Configuration module.

  2. Click on the entry in the ID column for the row in which the Action is After system boot. This will take you to a form for editing the inittab file entry.

  3. For the Bootup runlevel option, de-select whichever level is currently selected and choose a new one. Make sure that you choose exactly one level, such as 3 (for text login mode) or 5 (for graphical login mode). See the explanation in the introduction to this chapter for details on what each runlevel means.

  4. Click the Save button to have your change written to the inittab file. The browser will return to the main page of the module.

  5. If you like, you can reboot the system now using the Bootup and Shutdown module.

The module is also available on the Solaris, HP/UX, UnixWare, OpenServer, AIX, and Irix operating systems. Its basic structure and purpose is the same on all systems, but the actual default commands will differ significantly. The previous instructions for changing the bootup runlevel, however, will work on all operating systems.


9.10 Summary

This chapter has covered the bootup scripts used on Linux and many other UNIX variants, and shown how to manage them using Webmin. It has also explained where they fit into the overall Linux boot process along with the BIOS, boot loader, and init program. Finally, it has covered runlevels and the use of the SysV Init Configuration module to select the runlevel into which your system boots.


Chapter 10. Scheduled Commands

In this chapter, you can learn about the UNIX Cron and At facilities, used for running commands on a regular schedule or once at some future time.


10.1 Introduction to Cron Jobs

A Cron job is a UNIX term for a command that is run on a regular schedule by the cron daemon. Each job is owned by a UNIX user, and runs with the permission of that user. Each has a set of minutes, hours, days, months, and days of weeks on which it runs, allowing considerable flexibility in scheduling. For example, a job may run every 10 minutes, or at 3 a.m. every day, or at 5 p.m. Monday to Friday in January, February, and March.

Cron jobs are very useful for performing regular system tasks, such as cleaning up log files, synchronizing the system time, backing up files, and so on. Most Linux distributions will have several Cron jobs that were set up by default as part of the operating system install process for doing things like removing unneeded kernel modules, updating the database used by the locate command, and rotating log files.

The actual Cron job configuration files are stored in different places, depending on whether they are part of a package included in your Linux distribution or created by a user. The /var/spool/cron directory is for jobs created manually by users, and contains one file per UNIX user. The /etc/crontab file and the files under the /etc/cron.d directory contain jobs that are part of packages, such as those that are part of your distribution.


10.2 The Scheduled Cron Jobs Module

The Webmin module for editing Cron jobs can be found under the System category. When you enter it, the main page displays a table of all the existing jobs on your system, as shown in Figure 10.1. For each action, the owner, active status, and command are listed. If the command for a job is too long, it will be truncated for display on the page.

Figure 10.1. The Scheduled Cron Jobs module.

    [ Team LiB ]


10.3 Creating a New Cron Job

Using Webmin, you can easily create a new Cron job that will execute as any UNIX user on your system. To achieve this, follow these steps:

  1. On the main page of the module, click on the Create a new scheduled cron job link above or below the list of existing jobs. This will take you to the job creation form shown in Figure 10.2.

    Figure 10.2. The Cron job creation form.

  2. In the Execute cron job as field, enter the name of the UNIX user you want the job to execute as. The command executed by the job will run in the user's home directory with his full permission.

  3. The Active? field can be set to No if you don't want this new job to actually be executed. This is useful for creating jobs to be enabled at a later date.

  4. In the Command field, enter the shell commands that you want the Cron job to run. Just as at the shell prompt, multiple commands can be entered separated by a semicolon (;), and all the normal shell operators such as >, <, and && can be used.

    By default, any output from the command will be emailed to the owner of the Cron job. If you don't want this to happen, make sure that output is redirected to a file or /dev/null.

  5. Anything that you enter into the Input to command field will be fed to the command as input when it is run. If for example your command was mail foo@bar.com, anything entered into the field would be sent to that email address.

  6. In the When to execute section, choose the times and dates on which you want the command to execute. For each of the Minutes, Hours, Days, Months, and Weekdays options you can choose multiple times or dates, or select the All option.

    For example, to have a job executed at 3:15a.m. every Monday and Friday, you should change the Minutes option to Selected and select 15, change the Hours option to Selected and select 3, and the Weekdays option to Selected and select Monday and Friday. The Days and Months options would remain on All.

  7. Click the Create button to add the new Cron job. Assuming there are no errors in your selections, you will be returned to the main page of the module and your new job should appear next to its owner.


10.4 Editing a Cron Job

Existing Cron jobs, including those created by users through Webmin or included with your operating system, can be edited and rescheduled using this module. Be careful when editing jobs that came as part of your distribution though, as some perform important tasks like truncating web server, mail, and login log files so that they do not use up all of your disk space.

To edit an existing job, follow these steps:

  1. On the main page of the module, click on the command for the job that you want to edit. This will take you to the module editing form, which is similar to Figure 10.2.

  2. Change any of the details of the job, including the user, command, active status, and execution times and dates.

  3. When done, click the Save button, and you will be returned to the main page of the module.

Existing Cron jobs can be deleted by following these steps, but clicking the Delete button instead of Save. You can also force the immediate execution of a job by clicking the Run Now button on the edit page, which will execute the command and display any output that it produces.


10.5 Controlling Users' Access to Cron

The Scheduled Cron Jobs module can also be used to control access to the crontab command by UNIX users at the command line. This can be useful if you allow untrusted users to log in to your system, and want to prevent some of them from setting up Cron jobs to run commands and take up CPU time when they are not logged in. Usually by default, all users have the ability to create Cron jobs, but you can change that by following these steps:

  1. At the bottom of the module's main page, click on the Control user access to cron jobs link. This will take you to a form for entering the usernames of users who can or cannot use Cron.

  2. To grant access to all users, select the Allow all users option.

    To grant access to only some users, select the Allow only listed users option and enter their usernames into the text field.

    To give access to all but a few users, select the Deny only listed users option and enter the usernames of the people to whom you want to deny access into the text field.

  3. When done, click the Save button.

If a user has been denied access to Cron, you will no longer be able to use the module to create, edit, or delete jobs belonging to him. Existing jobs, however, may continue to execute!


10.6 Module Access Control Options

As described in Chapter 52, it is possible to use the Webmin Users module to control for which UNIX users a Webmin user can edit Cron jobs. To set this up, you must first grant the user access to the module, then follow these steps:

  1. In the Webmin Users module, click on Scheduled Cron Jobs next to the name of the user that you want to restrict.

  2. Change the Can edit module configuration? field to No, so the user cannot edit the commands that Webmin calls to create and edit jobs.

  3. Switch the Can edit cron jobs for field from All users to one of the other options. The most commonly used is Users with UID in range, which allows you to enter a minimum and maximum UID into the fields next to it.

    Never allow an untrusted user access to the Cron jobs of system users like root or bin, as this will clearly give him full access to your system and defeat any other Webmin access control.

  4. Set the Can control user access to cron? field to No, so that the Webmin user cannot stop users outside his control using Cron.

  5. Click the Save button at the bottom of the page to make the access control active.


10.7 Configuring the Scheduled Cron Jobs Module

Most of the module settings that you can view by clicking on the Module Config link on the main page are set by default to match the installed operating system, and vary rarely need to be changed. However, there is one field that effects the module's user interface, shown in Table 10.1.

Table 10.1. Module Configuration Options

Maximum command length to display

This field determines how many characters of each Cron job command will be shown on the module's main page. You can either select Unlimited to show them all (which may cause lines to be wrapped), or enter a maximum number of characters. The default is 80.


10.8 Other Operating Systems

Cron is available on almost all UNIX systems, with very similar capabilities. That means that this module appears almost identically on all operating systems, with only a couple of minor differences. On some, there is no Input to command field available for when creating or editing a job. On others, when controlling which users have access to Cron, the default Allow all users option will be replaced with Allow all users except root or Deny all users.

Internally, other operating systems use different directories for storing Cron jobs—Solaris for example uses /var/spool/cron/crontabs instead of /var/spool/cron on Linux. Most other systems do not have an /etc/crontab file or /etc/cron.d directory, either. When using Webmin, however, you do not have to bother about these differences as it knows about the paths used by other UNIX variants and displays all Cron jobs using the same interface, no matter which file they are stored in.


10.9 The Scheduled Commands Module

At jobs (called Scheduled Commands by Webmin) are similar to Cron jobs, but instead of executing repeatedly on a schedule, they run only once at a specified date and time. Unlike Cron jobs, they can be configured to execute in a specific directory instead of the user's home directory. Scheduled commands also keep track of the environment variables that were set when they were created, and make them available to the command when it runs.

Normally the at command is used to create At jobs, the atq command is used to list them, and the atrm command is used to remove them. On Linux, the directory /var/spool/at is used to store jobs—one per file. The daemon process atd, which runs all the time in the background, checks these files and runs them at the appropriate times. If the At daemon is not running, no commands will be run, which may be the case if it is not configured to start in the Bootup and Shutdown module. After a job is run, it is automatically deleted, as it is no longer needed.

The Webmin module for creating and deleting At jobs is called Scheduled Commands, and can be found under the System category. When you enter it, the main page will display a list of commands that are waiting to be run (assuming there are any), and a form for adding a new command. Figure 10.3 shows an example.

Figure 10.3. The Scheduled Commands module.

Any of the commands shown on the main page can be viewed in more detail by clicking on its Job ID. This will take you to a page that shows the full shell script that will be run when the command executes, including all environment variables. For this page, you can cancel the command before it gets a chance to run by clicking the Cancel this command button.


10.10 Creating a New Scheduled Command

A new command that executes at the time and as the user of your choice, can be created by following these steps:

  1. Enter the name of the user that you want the command to run as into the Run as user field on the main page of the module in the New scheduled command form.

  2. Fill in the Run on date and Run at time fields with the date and time on which the command is to run.

  3. Set the Run in directory field to whatever directory in which you want the command to run.

  4. In the Commands to execute text box, enter as many shell commands as you want—one per line.

  5. When done, click the Create button. The page will be refreshed and your new command will appear on the list at the top of the page.

Scheduled commands created from within Webmin will use environment variables set by Webmin itself, which are not be the same as the variables that would have been set if the command was created by its owner at the shell prompt.


10.11 Summary

Cron and At are the two services used by UNIX systems to schedule tasks to be run in the future. This chapter has explained how they work, what the differences between them are, and how to use Webmin to configure them. It has also covered the use of Webmin's access control features to restrict access to the modules for managing these services, and the limitations of this kind of access control.


Chapter 11. Process Management

This chapter explains how to manage running processes on your system using Webmin.


11.1 Introduction to Processes

Every program, server, or command running on a Linux system is a process. At any time, there are dozens of processes running on your system, some for programs that you are interacting with graphically, some for commands that you have started at a shell prompt, some for servers running in the background, and some that perform system tasks. Every time you type a command like ls or vi at the shell prompt, a new process is created, only to exit as soon as its job is done.

Each process is identified by a unique ID known as the PID, or process ID. Each is owned by a single user and is a member of multiple groups, which determine the privileges that the process has. And each has a priority (also known as the nice level), which controls how much CPU time the process can use up on a busy system. Almost every process has a parent, which is the process that started it, and from which it inherits ownership, priority, and other settings.

A process will run until it chooses to exit, or until it is killed by a signal from another process.


11.2 The Running Processes Module

This module can be used to view, kill, re-prioritize and run processes on your system. When you enter it for the first time from the System category, the main page will display a tree of processes as shown in Figure 11.1.

Figure 11.1. The Running Processes module tree display.

The module has several different ways of viewing all the processes on your system, selectable by the Display links at the top of the main page. They are:

PID In this display mode each process is shown indented under its parent, forming a tree of all the processes running on your system. At the top of the tree is the init command, which is started by the kernel at boot time and so has no parent.

User This mode groups processes by their owner. It can be useful on systems with many users for seeing at a glance what each user is running.

Memory In this mode, processes are ordered by the amount of memory they are using up, with those using the most memory shown at the top of the page. A process's memory usage is not always indicative of the amount of memory it is really using, because processes often share memory with each other.

In addition, the total and free amount of real and virtual memory on your system is displayed above the process list.

CPU This display mode orders processes by their current CPU usage, with the heaviest user appearing first. Sometimes the Webmin command that generates the page will appear near the top of the list, but it can be safely ignored.

The system load averages will be displayed at the top of the page, to give some idea of how busy the system has been over the last 1, 5, and 10 minutes. An average of 0 means no activity at all, 1 means the CPU is fully utilized, and anything above 1 means that there are more processes wanting to run than the system has CPU time for.

The Search and Run options are for searching for processes and running new ones, respectively. See the following sections for more details.


11.3 Viewing, Killing, or Reprioritizing a Process

You can see the full details of any running process by clicking on its Process ID column entry in any of the displays on the main page. This will take you to the process information page, shown in Figure 11.2.

Figure 11.2. Detailed information on a process.

The page displays all available information about the process, including its full command line, parent command, and any sub-processes. You can go to the information page for the parent by clicking on its command, or to the page on any of the sub-processes by clicking on its process ID. A list of files that the process has open and network connections that it is currently using can be viewed by clicking the Files and Connections button.

The process can be stopping using a TERM signal by clicking the Terminate Process button. Because this can be ignored by some commands, the Kill Process button can be used to send a KILL signal if the termination fails. Unless the process is hung inside a kernel system call, killing it is guaranteed to succeed.

Other signals can be sent by selecting the type of signal from the list next to the Send Signal button before pressing it. Some of the more useful signals are:

HUP For many server processes, this signal will cause them to reread their configuration files.

STOP Suspends the process until a CONT signal is received.

CONT Resumes a process that has been suspended by a STOP signal.

The information page can also be used to change the nice level of a running process, giving it a higher or lower priority. To change a process's priority, select a new level from the Nice level list, and then click the Change button. Lower levels mean higher priorities, so a process with a nice level of –10 will get more CPU time than one with level 5.

On a system with multiple users, long-running processes that take up a lot of CPU time should be given a higher nice level so that they do not slow down processes that are interacting with users. Alternately, you can speed up a process at the expense of others by giving it a lower nice level. You should be careful when setting an extremely low level (such as –20), as all other processes may become starved of CPU time, making the system unresponsive.


11.4 Searching for Processes

If you have a large number of processes running on your system and want to find one or more to kill or view, the Running Processes module's search feature makes it easy. To find processes, follow these steps:

  1. On the main page of the module, click on the Search display mode link. This will take you to a search form as shown in Figure 11.3.

    Figure 11.3. The process search form.

  2. The form shows several different criteria for finding processes, of which you can choose one by selecting the radio button next to it. The criteria are:

    Owned by Processes owned by the user whose name you enter next to this option will be found.

    Matching Finds processes whose command or arguments contains the text that you enter next to this option.

    Using more than Finds processes using more than the specified percentage of CPU time.

    Using filesystem Processes whose current directory is on the chosen filesystem or are accessing any file on it will be found. Useful if you cannot unmount a filesystem because it is busy.

    Using file Finds processes that have the entered file open for reading or writing. If you enter a directory, any process that has it as its current directory will be found.

    Using port Finds processes that are sending, receiving, or listening for network traffic on the entered port using the chosen protocol. Useful if you know the port number a server is listening on, and want to find the server process.

  3. To filter the Webmin search processes from the results, select the Ignore search processes in result option. This can be useful when searching by CPU usage, as the Webmin processes use up a lot of CPU time.

  4. After you have selected the search criteria, click the Search button. Any matching processes will be displayed below the form.

  5. If you want to see additional information about a process, change its priority, or send it alone a signal, click on its Process ID in the results.

  6. To kill all matching processes, click the Terminate Processes or Kill Processes button. You can also send any signal to all processes by selecting it from the list next to the Send Signal button. A page will be displayed listing each process ID and whether it was signaled or killed successfully.


11.5 Running a Process

The module can also be used to run simple commands, either in the foreground so that their output is displayed, or in the background as daemons. This can be useful if you just want to run a command without having to log in via telnet or SSH (or if a firewall is preventing a telnet or SSH login). The steps to follow are:

  1. On the main page of the module, click on the Run link next to the display mode options. This will take you to the form for starting a new process.

  2. Enter the command that you want to run into the Command to run field. Shell operators and special characters like ;, <, >, and & can be used.

  3. If the command is something that will take a long time to run, you can set the Run mode option to Run in background to have Webmin automatically put it in the background. However, if you want to see the output from the command, leave the option set to Wait until complete.

  4. Enter any input that you want fed to the command into the Input to command field.

  5. Click the Run button to run it. If the Wait until complete option was selected, any output from the command will be displayed.


11.6 Module Access Control Options

By default, any Webmin user with access to this module can manage all processes running on the system, as though he were logged in as root. However, using the Webmin Users module, you can limit a user's access so that he can only kill or re-nice processes owned by a particular UNIX user. It is also possible to restrict a user to read-only mode, allowing him only to see processes but not change them in any way or start new ones.

You should read Chapter 52 first to learn more about module access control and how to grant a user access to the Running Processes module. Once you have done that, the steps to follow to edit a Webmin user's access to this module are:

  1. In the Webmin Users module, click on Running Processes next to the name of the user or group that you want to restrict.

  2. Change the Can edit module configuration? field to No.

  3. To give the Webmin user access to only those processes owned by a particular UNIX user, enter the username into the Manage processes as user field. If the UNIX and Webmin users have the same name, you can select Current Webmin user instead. This can be useful when setting up module access control for a group in which you want each member to be able to manage only his own processes.

  4. To put the user into read-only mode, set the Can kill and re-nice processes? and Can run commands? fields to No. If this is done, it doesn't really matter what username you enter in Step 3 because no process management can be done.

  5. Click the Save button to have your changes activated.

To restrict the processes that a Webmin user can manage, the module code simply switches to run as the UNIX user specified in Step 3. Because a UNIX user cannot kill or re-prioritize any process that he does not own, switching users like this causes the operating system to automatically enforce process access control for Webmin.


11.7 Other Operating Systems

Because processes exist on all versions of UNIX with almost identical attributes, this module appears almost exactly the same on all supported operating systems. The only minor differences are:

  • When viewing detailed information about a process, different information may be available on other operating systems. The range of nice levels may also be different, but lower levels still mean a higher priority and vice-versa.

  • When searching for a process, the Using filesystem, Using file, or Using port criteria may not be available. These options depend on the fuser and lsof commands that are not available for or installed by default on all systems.


11.8 Summary

After reading this chapter you should have a good understanding of what processes are, and their importance on a UNIX system. You should also understand how to use Webmin to view processes running on your system, search for those matching some criteria, and kill, signal, or reprioritize one or more of them. Finally, you should know how to configure the module to restrict the capabilities of certain Webmin users, if required for your system.


Chapter 12. Software Packages

This chapter covers the installation and management of software on your system using packages. It also overs the differences between the various UNIX package formats, such as RPM, DPKG, and Solaris.


12.1 Introduction to Packages

All Linux systems use some kind of software packaging system to simplify the process of installing and removing programs. A package is a collection of commands, configuration files, man pages, shared libraries, and other files that are associated with a single program like Apache or Sendmail, combined into a single package file. When it is installed, the package system extracts all the component files and places them in the correct locations on your system. Because the system knows which package every file came from, when you want to remove a package it knows exactly which files to delete.

On almost all versions of Linux, packages generally contain compiled programs that will only work on the CPU architecture that they were compiled for. Because Linux supports many different CPU types (x86, Alpha, and IA64 to name a few), some programs have packages compiled for several different CPUs. A package can only be installed on a system with the right CPU architecture—unless it is architecture-independent, in which case it will install on any system type. Programs written in languages like Perl (such as Webmin) or packages that contain only documentation are usually CPU-independent.

When a Linux distribution is installed, almost every file that is placed on the hard disk is a member of one of the distribution's packages. This makes it easy to remove unwanted software that was installed by default, or add additional software from the distribution CD or website.

Because some programs depend on other programs to operate, packages can have dependencies as well. Certain packages may fail to install unless you have installed another package first, and some packages may not be removable if others depend upon them. This system of dependencies protects the user from installing software that will not work due to a missing shared library or command.

Because the package system knows exactly which files are in each package, it can use that information to validate the files after installation. All package systems also keep track of the MD5 checksum for each file, so that any manual modifications to files in a package can be detected. This can be very useful for detecting unauthorized modifications, such as by an attacker who has cracked your system and replaced important commands like ls and find with modified versions. Unfortunately, on Linux there is more than one package system. The most common is RPM, which stands for Red Hat Package Manager. It is used by Red Hat, Caldera, SuSE, Mandrake, MSC, and a few other Linux distributions. It works well, and there is more software available in RPM format than any other package system. Installation, querying, and deletion of RPM packages is done using the rpm shell command.

The biggest competitor to RPM is Debian's DPKG package format. It is technically superior in many ways, particularly when it comes to dependencies—however, only Debian and a few other distributions use it. The dpkg and deselect commands are used at the shell prompt to manage Debian packages.

Another packaging system is Gentoo's Emerge, which is only available on Gentoo Linux. The biggest difference between Emerge and other package systems is that almost all packages contain source code, which is compiled when the package is installed. All Gentoo package installation and management is done using the emerge command.

Even though these package systems are internally different and use incompatible file formats, they all offer basically the same features. All allow multiple files related to the same program to be combined into one package file for easy installation and removal, and all support dependencies. Unfortunately, once you have chosen your Linux distribution it is very difficult to change to another packaging system, so you are stuck with what the distribution uses.

On most distributions that use RPM, packages are either installed from a distribution CD or downloaded from various sites on the Internet. Debian Linux, however, includes a command called apt-get that can automatically download and install packages from a repository run by the distribution maintainers. If the package depends on others that are not yet installed on your system, they will be automatically downloaded and installed as well. Because all packages in the repository are created and maintained by the same people, incompatibilities between them are reduced and dependencies easily resolved. The repository also contains a package for almost every free software program that you might want to install, so there is no need to search the Internet for the package that you want.

The Debian repository can also be used to update all the packages on your system to the latest version. Because new versions of packages come out frequently (especially when using the unstable or testing Debian releases), an update is an easy way of ensuring that you are running the latest version of everything. This can take a long time if you do not have a fast connection to the Internet though, as many new packages may be downloaded for each update.

Gentoo Linux's Emerge system also has a repository from which packages can be automatically downloaded and installed using the emerge command. Like Debian's apt-get, it automatically downloads and installs packages needed to fulfill dependencies.

Red Hat systems also have access to a package repository as part of the Red Hat Network. This allows updated packages to be selected on the Red Hat website and installed automatically or on request on multiple systems. Unlike the Debian and Gentoo repositories, it is not generally used for installing new packages.


12.2 The Software Packages Module

The Software Packages module provides a consistent interface for installing, searching, and removing packages, independent of the actual packaging system being used. Its icon can be found under the System category, and clicking on it will take you to the main page shown in Figure 12.1.

Figure 12.1. The Software Packages module main page.

Depending on your Linux distribution, the page may look slightly different—additional buttons and fields for installing from a repository may be visible. However, the top section for finding packages, the middle section for installing a package, and the lower section for identifying a file will always be there.


12.3 Installing a New Package

Before you can install a new program using this module, you first have to locate a package file for it that is in the correct format. For RPM-based distributions like Red Hat, the best places to look are the distribution CDs or the rpmfind.net website. If you are using Debian Linux, it is best to try installing from the APT repository as it contains almost all available packages. Either way, the steps for installing a package are similar:

  1. On the main page of the module, scroll down to the Install a New Package form, which will be used to select the package and start the install process.

    If the package file is on the system running Webmin, select the From local file option and enter the full path to the package file. If your system uses RPM packages, you can enter a directory containing multiple .rpm files or a wildcard like /tmp/*.rpm as well. This can be used to install several packages at once.

    If the package is on the computer your browser is running on, select the From uploaded file option and click on the Browse button to select the package file. If you are running your browser at the console of your Webmin system, there is no difference between this option and the previous one.

    If the package is on a website somewhere, select the From ftp or http URL option and enter or paste the URL into the text field next to it. Webmin will do the download for you before starting to install. If your system uses RPM packages and you have the rpmfind command installed, the Search rpmfind.net button next to the URL field can be clicked to pop up a window for searching the RPM database at rpmfind.net/.

    If running Debian Linux, you can select the Package from APT option and enter the package name into the text field next to it. Click the Search APT button to find the package name if you don't know exactly what it is called.

    If running Red Hat Linux, the Package from Red Hat Network option can be used to install one of the packages that you have available for downloading. The Search RHN button can be used to display all those that are available.

    If you are running Gentoo Linux, the From Portage repository option and Search buttons can be used to install from the repository. In fact, very few Gentoo packages can be found outside the repository.

  2. Once the package source has been entered, click the Install button.

    If you chose to install from a repository (such as APT, Red Hat Network, or Portage), the download and installation process will start immediately. Webmin will display output from the install command, and if successful, a list of packages that were installed. No other steps are necessary to complete the install process.

    If any other install source was chosen, the package will be downloaded if necessary and the installation options form displayed.

  3. The installation options available differ depending on your package system, but the defaults will work fine for upgrading or installing a package with no dependency problems. RPM-based systems have several options, the most useful of which are:

    Ignore dependencies? If a package is failing to install due to dependency errors that you know are incorrect, set this option to Yes. It can also be useful if you are going to install packages to solve the dependency problems later.

    Replace new version with old? If you want to downgrade a package to an older version, this option must be set to Yes.

    Overwrite files? If a package cannot be installed due to conflicts with files from another package, enable this option.

  4. When you are done selecting install options, click the Install button. If everything goes well, a page showing the details of the new package and all the files that it contains will be displayed. However, if the install fails, an error message explaining why will be displayed. In that case, you can use the browser's back button to return to the install options form and try again with different choices.


12.4 Finding and Removing a Package

A typical Linux system has hundreds of installed packages, most of which were added as part of the distribution install process. Because there are so many, it is difficult to simply browse through them to find one that you want to remove or view the details of. To find a package or packages, follow these steps:

  1. On the main page of the module, enter a search keyword into the Search For Package field. This will be matched against the names and descriptions of all packages, so you can enter something like apache to find all that are related to Apache.

  2. Click the Search For Package button, which will either display a list of all matching packages, take you to the details of the package if only one is found, or show an error message if none were found. If a list appears, click on one of the package names to see its full details.

  3. The package details page (shown in Figure 12.2) will display all available information, including a full description. If you want to see all the files that it contains, click the List Files button. This will take you to a page showing the path, type, owner and group, and validation status for each file. The status is particularly useful, as it allows you to see if a file has been changed manually since the package was installed.

    Figure 12.2. The package details page.

Packages can also be browsed manually by clicking on the Package Tree button on the main page. On most operating systems, each package is a member of a class such as Development or Administration/Networking. The package tree page uses this class information to display all installed packages in a hierarchy, much like a directory tree. You can open classes by clicking on their folder icons until you get to the package level. Clicking on a package icon will take you to the same details page as described in the steps above.

If you know the name of a command or file and want to find the package that it belongs to, the Identify a File form on the main page can be used. Enter either a full path (like /etc/rc.d/init.d/httpd) or a command (like apachectl) into the Search For field, and hit the button. If the file or command is known to the package system, information on it will be displayed along with a list of packages that it belongs to. Clicking on one of the package names will take you to the information page described above.

Once a package has been found by searching or browsing the tree, you can delete it from your system by following these steps:

  1. On the package details page, click the Uninstall button. This will take you to a confirmation page showing the number of files in the package and the amount of disk space that they occupy.

  2. If using the RPM packaging system, the Ignore dependencies? option can be set to Yes to force an uninstall even if some other packages depend upon the one being removed.

  3. Click the Delete button to remove the package. If something goes wrong, an error message will be displayed. If successful, the browser will return to the module's main page or to the package search results list, if you found the package using a search.


12.5 Updating on Debian Linux

If you are running Debian Linux, at the bottom of the main page of the module there will be a form headed Upgrade All Packages. This form has three options, which are:

Resynchronize package list If this option is set to Yes, the Debian package repository will be queried to retrieve the latest list of packages available for download. This should be done before any upgrade, so that your system knows which URLs to download from when installing packages from the APT repository.

The actual command used to synchronize the package list is apt-get update.

Perform distribution upgrade When this option is set to Yes, your Debian system will be upgraded to the latest distribution release when the form is submitted. With the default No selection, it will simply be updated so that all packages installed are the latest version. Unless you have a fast network connection and really want to upgrade, it is advisable to leave this option set to No.

When Yes is selected, the command apt-get upgrade-dist will be run. For No, apt-get upgrade will be used instead.

Only show which packages would be upgraded If set to Yes, nothing will actually be installed when the form is submitted—instead, a list of packages that would be updated or installed will be displayed. This can be useful if you want to see exactly what would happen when doing an update before going ahead for real.

After you have made your choices, click the Upgrade Now button. Webmin will run the appropriate apt-get commands and display their output, so that you can see which packages are downloaded and updated.


12.6 Updating on Red Hat Linux

Red Hat offers a service to users of its Linux distribution, called the Red Hat Network. One of its features allows you to have updated RPM packages automatically installed on your system, to fix bugs or security holes that are found in the packages supplied with the distribution. If you are running Red Hat Linux, there will be a form at the bottom of the main page under the heading Red Hat Network Options that you can use to configure the automatic installation of updated packages. Before it can be used, you must have signed up with the Red Hat Network and registered the system you are running Webmin on.

The form actually serves two purposes—changing the settings for the update daemon that periodically checks for new packages and forcing an immediate update. The fields on the form are:

Automatically check for updates? If this option is set to Yes, the rhnsd daemon that checks for updates will be configured to start at boot time. It will also be started immediately when the Save and Apply button is clicked, if it is not currently running. Setting it to No will stop the daemon and prevent it from being started at boot time.

Checking interval When the automatic update daemon is enabled, the number of minutes between checks for new packages is determined by this option.

Proxy server URL for downloading If your system cannot connect directly to the Red Hat website, you will need to set this option to the URL of a web proxy server. It must be formatted like this: http://proxy.company.com:8000/.

Skip packages matching This option is for entering a list of patterns for package names that you do not want automatically updated. By default it prevents kernel updates from being automatically installed.

The Save and Apply button will save your settings and start or stop the rhnsd daemon as necessary. The Save and Check Now button will do the same thing, but will also run the up2date –u command to immediately check for and download new packages. All output from the command will be displayed so that you can see which packages are being updated.


12.7 Other Operating Systems

Linux is not the only version of UNIX that uses packages to simplify the process of installing and removing software. The operating systems listed below can also use the Software Packages module, with an almost identical user interface. However, each has its own packaging format that is incompatible with Linux or any other variety of UNIX.

The differences between each UNIX's package system and RPM are explained below:

Sun Solaris, SCO OpenServer, and SCO UNIXWare

  • All of these operating systems use the same basic System V package format, but packages from one cannot be installed on any of the others.

  • Package files are usually named something.pkg or something.pkg.gz. If a package file is compressed, Webmin will uncompress it automatically.

  • Files can contain multiple packages, all of which will be installed when using Webmin.

  • No package repository or search service exists for System V packages.

  • Directories like /usr/bin are often shared between multiple system packages.

FreeBSD, NetBSD, and OpenBSD

  • Package files have names like something.tgz, and are actually just specially formatted tar files.

  • Webmin does not support any repository for BSD packages.

HP/UX

  • HP/UX uses its own unique Depot package format.

  • Package files are usually named like something.depot or something.depot.gz. If a package is compressed, Webmin will automatically uncompress it for you.

  • Webmin does not support any repository for HP/UX packages.


12.8 Summary

Package management is one of the most useful features of Linux and the other UNIX variants that support it. This chapter has explained what packages are, what kinds of package management systems exist, and how you can use Webmin to install and manage packages on your system. It also covered other package-related services, such as automatic updates and repositories.


Chapter 13. System Logs

In this chapter, the UNIX syslog service that controls where logs are written to is explained, and the Webmin module for configuring it is documented.


13.1 Introduction to Logging

Many Linux servers and daemons generate log messages for errors, warnings, requests, and diagnostic information. In most cases, these logs are not written directly to a file—instead, they are passed to the UNIX logging program syslog which decides what to do with each log message. Logs can be written to a file, sent to another server, passed to another program via a pipe, or even broadcast to all users logged into the system. Different types of messages from different servers can be logged using each of these methods.

Normally logs are written to files in the /var/log directory. On most Linux distributions the file /var/log/messages contains general information, error and warning messages, the file /var/log/mail records incoming and outgoing mail, and /var/log/secure records successful and failed logins. However, your system may have a totally different syslog configuration and so use different logfiles.

Each log message that is sent to syslog has three attributes—the program that it comes from, a facility, and a priority. The facility classifies the message, indicating which part of the system it is coming from. Facilities that are recognized on Linux are seen in Table 13.1.

The priority or log level associated with each message indicates how serious it is. Many servers generate messages with low priorities that contain only diagnostic or debugging information, which can safely be ignored. However, messages with higher priorities indicate a serious problem with a server or possibly the entire system. The recognized priorities on Linux (in order from least to most serious) are seen in Table 13.2.

Table 13.1. System Logging Facilities and Their Sources

auth or authpriv

All messages related to successful or failed authentication attempts will use this facility.

cron

Used for log messages from the Cron and At daemons.

daemon

Used for messages from other daemons, such as the NFS, NIS, and DHCP servers.

kern

For error, warning, and informational log messages that come from the kernel.

lpr

For messages from the printer server and print commands.

mail

For email delivery logs, and error messages from Sendmail or Postfix.

news

For messages from news servers like INN.

syslog

Used for log messages generated by the syslog daemon itself.

user

For generic user-level messages. Not often used.

uucp

For messages from the UUCP (UNIX to UNIX Copy) server programs, which are hardly ever used anymore.

local0 to local7

These facilities are reserved for local use, such as by a server that can be configured to use a different facility.

Table 13.2. System Logging Priorities and Their Meanings

debug

Debugging information only, which can be safely ignored.

info

An information message indicating that something has occurred, but nothing serious.

notice

Indicates a normal but significant event.

warning

A warning about some potential problem.

err

An error message indicating that something has failed.

crit

Indicates a critical problem of some kind.

alert

An extremely serious problem that must be looked into immediately.

emerg

Indicates imminent or actual system failure.

The file /etc/syslog.conf contains the syslog configuration that controls which messages are logged to which files and destinations. Webmin reads and modifies this file directly to change your system's logging settings, and reads from the files in /var/log to display log messages.

Not all logs generated by all programs are controlled by syslog. For example, the Apache Web server writes directly to a log file that records every HTTP request that it receives. Other programs like Squid and Qmail also have their own private log files that are not under the control of syslog and so cannot be configured using the System Logs Webmin module. Some of these servers can be configured to log via syslog, but this is never the default and is usually a bad idea for programs that generate large numbers of log messages, such as Apache. See Chapters 29, 38, and 44 for more information on configuring logging in these servers.


13.2 The System Logs Module

If you want to view log files on your system and configure where log messages are recorded, the System Logs module under the System category is the place to go. The main page of the module lists all files and other destinations that syslog is currently logging to, as shown in Figure 13.1. For each log destination, its active status and the facilities and priorities that are logged to it are displayed.

Figure 13.1. The System Logs module.

Even if you don't want to change existing logging settings, you can use the module to view a log file by clicking on its View link. This will take you to a page showing the last 20 lines of the file, with a Refresh button at the bottom to reload the page or increase the number of lines displayed. You can also limit the display to only certain types of log messages with the Only show lines with text field. Only logs written to normal files can be viewed—those sent to another server, to users, to a named pipe, or to a device file cannot be read by Webmin.


13.3 Adding a New Log File

Because the messages written to each log destination have no effect on other destinations, you can add a new log file without affecting any of the existing ones. This can be useful if there is some information which you want to see but which is not currently being recorded, or if you want to separate out messages of a particular facility or priority into a different file from the one that they are currently being logged to.

To add a new log file or destination, the steps to follow are:

  1. On the main page of the System Logs module, click on the Add a new system log link above or below the list of existing log files. This will take you to the form shown in Figure 13.2 for entering the details of the new log destination.

    Figure 13.2. The new log destination form.

  2. Select one of the five choices in the Log to field, which controls where messages are written to. The choices are:

    File If this option is selected, you must enter into the text field the name of a file to write logs to. Log lines will be appended to the file, which will be created if it does not exist. To ensure that syslog forces each line to be written to disk after adding it, select the Sync after each message? option. Unless you are trying to reduce hard disk activity on your system (such as on a laptop), it is wise to leave this option selected.

    It is possible to create more than one log that writes to the same file. This can be done safely without worrying that messages from one will overwrite another.

    Named pipe A named pipe is a special file that can be written to by one program and read by another. If you want log messages to be written to a pipe, first create it and then enter its path into the field next to this option.

    Syslog server on This option can be used to pass some or all of the log messages from your system to another server, assuming it is running syslog as well. If selected, the hostname or IP address of the remote server must be entered into the text field next to the option. Unlike local log files, logs written to a remote server are safe from attackers who break into your system.

    Local user If this option is selected, log messages will be broadcast to any of the users listed in the text box next to the option. Users must be logged in via SSH, telnet, or at the console to receive log messages.

    All logged-in users This is like the previous option, but messages will be sent to all logged-in users. In order to avoid annoying people, this option should only be used for logging really serious errors.

  3. The Logging active? field determines whether this log is enabled or not. If set to No, the syslog.conf entry for the log will be commented out and nothing will be sent to the chosen destination.

  4. The Message types to log section controls which messages are written to the log destination. It is composed of two parts: Facilities and Priorities. A message will only be logged if it matches both the selected facilities and the selected priorities.

    For the Facilities, you can either select a single facility from the menu, select the All option to include all of them, or enter a list of facilities separated by spaces into the Many text field.

  5. For the Priorities, you can select None to indicate that no messages of the select facilities will be logged, select All to log messages of any priority, or choose one of the range options from the menu (At or above, Exactly, Below or All except) and choose a priority from the final menu. This last option limits logging to messages of one or more priorities depending on your range type and priority selection.

    When creating a new log, you can select only one set of facilities and one range of priorities. However, after saving, if you re-edit the log you can add an additional row specifying facilities and priorities so that more than one type of message is logged. It is even possible to use the None option under Priorities to exclude some facilities that were included by a previous row.

  6. When done making your selections on the form, click the Create button. As long as there are no errors, you will be returned to the main page of the module.

  7. Click the Apply Changes button to make your new log destination active.


13.4 Editing or Deleting a Log File

Any of the existing logs shown on the main page of the module can be edited or deleted using Webmin. However, you should be careful when changing destinations that were included in the system's default configuration, as important messages may no longer be logged. Even changing the filename that logs are written to could cause problems, as many Linux distributions include software to automatically truncate the standard log files to prevent them from taking up too much disk space.

To change a log, the steps to follow are:

  1. On the main page of the module, click on the destination of the log that you want to edit. This will take you to an editing form that is almost identical to the creation form shown in Figure 13.2.

  2. Change any of the existing settings, such as the destination type, log file, or active status. You can also change which facilities and priorities are logged by adding to or editing the rows in the Message types to log section. There will always be one blank row for selecting new facilities and a new priority range, as explained in Section 13.3 "Adding a New Log File".

  3. When done, click the Save button. As long as you have made no errors in the form, your browser will return to the module's main page.

  4. Click the Apply Changes button to make your changes active.

To delete a log, follow these steps:

  1. On the main page of the module, click on the destination of the log that you want to delete.

  2. Click the Delete button at the bottom of the page. This will stop logging to the destination, but it will not delete any log files that have already been written—you can do that manually if you wish.

  3. Back on the main page, click the Apply Changes button to make the change active.


13.5 Module Access Control

The System Logs module can be restricted so that a Webmin user can use it only to view log files instead of being able to create and edit them. As explained in Chapter 52, you must first create or edit a user who has access to the module. Once that is done, follow these steps to limit him to viewing log files only:

  1. In the Webmin Users module, click on System Logs next to the name of the user that you want to restrict.

  2. Change the Can edit module configuration? option to No, so that he will not be able to reconfigure the module to use a fake syslog.conf file.

  3. Change the field Can only view logs? to Yes. When this is set, the only thing that the user will be able to do on the module's main page is click on the View link next to a log file entry.

  4. To limit the log files that the user can view, select Only listed files and those under listed directories in the Can view and configure log files field and enter a list of filenames into the adjacent text box. This can be useful if some of the logs on your system contain sensitive or secure information.

  5. Click the Save button to make the changes active.


13.6 Other Operating Systems

Almost all versions of UNIX use syslog to control the destinations that log messages are written to, so the System Logs module is available on most operating systems. It has similar capabilities on all systems, so the user interface is generally the same. However, there are some differences, as explained below:

Sun Solaris, Apple MacOS X, HP/UX, SCO UNIXWare, SCO OpenServer, and IBM AIX

  • On Solaris, the first time you use the module, Webmin may ask if you want to convert syslog.conf from M4 format. Unless you have made manual changes that use M4 macros, this is safe to do.

  • Logging to named pipes is not supported.

  • There is no option to sync after each write to a log file.

  • When selecting the priorities of messages to write to a log, the At or above, Exactly, Below, and All except range types are not available. Instead, all messages with priorities at or above the one you select will be logged.

FreeBSD, OpenBSD, and NetBSD

  • On FreeBSD, logging to named pipes is not supported.

  • On OpenBSD and NetBSD, logs can be sent directly to the input of a command instead of to a named pipe.

  • There is no option to sync after each write to a log file.

  • When selecting the priorities of messages to write to a log, the At or above, Exactly, Below, and All except range types are replaced with >=, =, <, <>, which have similar meanings.

  • Each log destination can be associated with a program, set using the optional Only for program field. If set, only log messages from the entered server or daemon will be written to this log file.

SGI Irix

  • Logging to named pipes is not supported. Instead, logs can be sent directly to the input of a command.

  • There is no option to sync after each write to a log file.

  • Logs can be written to a UNIX domain socket file.

  • When selecting the priorities of messages to write to a log, the At or above, Exactly, Below, and All except range types are not available. Instead, all message with priorities at or above the one you select will be logged.

If your operating system is not on the list above, then it is not supported by the System Logs module.


13.7 Summary

The log files on a UNIX system contain a wealth of useful information, such as the details of email received, attempted and successful logins by users, hardware error reports from the kernel, and much more. This chapter explains how to configure the files and other destinations that are used for various types of messages, and how to view those files though Webmin. An important part of system administration is keeping a look out for log messages indicating serious errors or potential security violations.


Chapter 14. Filesystem Backups

This chapter explains how to backup and restore files with the dump command, using Webmin's Filesystem Backup module.


14.1 Introduction to Backups with Dump

There are many ways of backing up a UNIX system—you can just copy files to another directory, use the tar command to create an archive file or write to a tape device, or use the dump family of commands. Although copying or using tar is easier, only dump can preserve all file types (such as named pipes and symbolic links) and file information (such as ACLs and attributes). It can do this because it has a more sophisticated knowledge of the underlying filesystem than other backup programs.

Another unique advantage of the dump program is its support for backup levels. If you are regularly backing up the same directory, instead of writing all files to the backup device every time, you can choose to save only those files that have changed since the last backup of a lower level. For example, you could do a full backup (level 0) every week, and a much faster partial backup (level 9) each day. The only down side is that if data needed to be restored, the weekly backup and all the daily backups for the week so far would need to be read.

Using dump to make backups has some problems that other backup tools do not. The data that it writes to a file or tape device is not compressed, although this is not a problem with most tape drives as they compress data automatically. Another problem is that it cannot backup files mounted via NFS from another server, as it reads directly from the disk, unlike the tar and cp commands.


14.2 The Filesystem Backup Module

This module allows you to backup directories on your local filesystems, either on demand or on a fixed schedule. The appropriate command for the filesystem type being backed up is used—for example, xfsdump on xfs filesystems or dump on ext2 or ext3. The module also supports the restoration of backups, either to their original location or to a different path.

When you enter the module from the System category, the main page will display all backups that you currently have configured, as shown in Figure 14.1. Of course, if this is the first time you have used the module there will be none to display.

Figure 14.1. The Filesystem Backup module main page.

If Webmin detects that you do not have any of the necessary backup commands installed on your system, an error message will be displayed on the main page instead. All Linux distributions should include a package containing the dump program on their CD or website.


14.3 Adding a New Backup

If you want to backup a directory, either just occasionally or on a regular schedule, you first need to add a new backup configuration. This specifies a directory to backup, a set of options to use, and the times at which it should be scheduled to run. The steps to follow to create a new configuration are:

  1. On the main page of the module, enter the path to the directory that you want to backup into the field next to the Add a new backup of directory button. When you click the button, Webmin will determine what type of filesystem the directory is in (ext2, ext3, or xfs) and display a backup creation form with options for that filesystem type. Figure 14.2 shows the form for an ext2 or ext3 backup.

    Figure 14.2. The new backup configuration form.

  2. The path you entered will appear in the Directory to backup field. You can still change it if you wish, as long as the new directory that you enter is still on the same filesystem.

  3. If backing up to a local file, set the Backup to field to the File or tape device option and enter the file that you want the backup written to into the text field next to it.

    Backing up to a tape drive is similar to writing to a file, but instead of entering a filename into the File or tape device field you must enter the device file for the tape drive. For example, /dev/st0 would be the device file for the first SCSI tape drive on your system.

    If backing up to another server, you must select the Host option for the Backup to field and enter a hostname, remote username, and file or device name on the remote server. The server must have the shell service enabled in its Internet Services module, as explained in Chapter 15. An appropriate .rhosts file must also be set up for the target user, to allow the dump command to connect without needing to supply a password.

  4. If your backup is being written to a local file that you do not want to be larger than a certain size, set the Split across multiple files? option to Yes and enter the maximum size in kilobytes into the Tape size field. This can be useful if the backup is going to be later saved to multiple CDs or Zip disks.

  5. If you are doing multiple backups at different levels as explained in the introduction, change the Dump level field to something other than Full backup. However, if you want each backup to contain all files in the source directory, leave it unchanged at level 0.

  6. If you are backing up to a tape, it is a good idea to set the Tape size field to the number of kilobytes that can fit on your tape. Otherwise, the dump command may underestimate the amount of data that can be written and fail to complete the backup.

  7. The chattr command can be used to mark a file to be skipped when making backups, which can be useful if the directory contains huge and useless files that you would rather not save. However, when doing a level 0 backup such files will be included, unless the Always exclude marked files? field is set to Yes.

  8. If you are familiar with the dump command used on your operating system, the Extra command-line parameters field can be used to enter extra options to be passed to the program, such as – A /tmp/archive. Otherwise, leave it blank.

  9. To have commands run before and after the dump command is executed, fill in the Command to run before backup and Command to run after backup fields. These commands will be run as root when the backup is made, either as scheduled or manually through Webmin. They can be useful for loading and unloading tapes, or copying files into the backup directory before it is saved.

  10. If you want the backup to be run on a regular schedule, set the Scheduled backup enabled? option to Enabled and select the times and days for it to run from the lists at the bottom of the page. The user interface for date and time selection is exactly the same as the one used by the Scheduled Cron Jobs module, explained in Chapter 10.

  11. To have a status report of the scheduled backup emailed to you, enter your email address into the Email scheduled output to field.

  12. By default, the subject of the backup email will be something like Dump of /etc. If you are using this module on multiple systems, you may want to customize the subject line so that the host the email is coming from and the data that has been backed up is more obvious. To do this, de-select the Default option for the Email message subject field, and enter a new subject line into the text field next to it.

  13. Finally, click the Create button to save the details of the new backup configuration. If there are no errors in the form, you will be returned to the modules main page.

    Alternatively, you can begin a backup immediately by clicking Create and Backup Now. This will take you to the page showing its progress, as explained in Section 14.4 "Making a Backup".

Apart from ext2 and ext3, the only other filesystem type that has a similar backup command is xfs. Because its xfsdump command has slightly different options, the fields on the new backup form are not quite the same as described above. One important difference is that the Directory to backup must be the mount point of a filesystem, not just any directory within it.


14.4 Making a Backup

Once you have created a backup configuration that appears on the main page of the module, you can use Webmin to manually execute it at any time. To do this, the steps to follow are:

  1. From the list of configurations on the module's main page, click on the directory you want to backup. This will take you to a form showing all the details of the backup configuration.

  2. Click the Backup Now button at the bottom of the page. Webmin will execute the appropriate dump command and display its output as it writes to the backup file or tape device. The output from any commands that are run before or after the backup will be shown as well.

  3. If all goes well, the message backup complete will be displayed at the bottom of the page. However, if something goes wrong, backup failed will be displayed instead—check the output of the dump command to see exactly what the problem was.

One limitation of the Filesystem Backup module is that it cannot create backups that span multiple tapes. Usually the dump command would prompt the user to load a new tape when necessary, but that is not possible when it is being run from Webmin.


14.5 Editing or Deleting a Backup

The backup configurations shown on the module's main page can be edited at any time. To change one, do the following:

  1. Click on the directory of the backup configuration that you want to change. This will take you to the editing form, which is similar to the creation form shown in Figure 14.2.

  2. Change any of the options, including the directory to backup, destination, or schedule. You cannot change the directory to a path on a different type of filesystem though, as it may have different options or not be supported at all.

  3. Click the Save button to record your changes, or click Save and Backup Now to immediately begin a backup with the new options.

To delete an existing backup configuration, the steps to follow are:

  1. On the main page, click on the directory of the backup configuration that you want to delete, which will take you to the editing form.

  2. Click the Delete button at the bottom of the page. The backup configuration will be immediately removed and you will be returned to the main page of the module. The actual backup files created by the configuration will not be touched though.


14.6 Restoring a Backup

Backups made using Webmin (or by running the dump command manually) can be restored using this module as well. If you have been creating backups of different levels, they must be restored in ascending level order starting with the complete backup (level 0). A backup can be restored to any directory, not just the one that it was originally saved from. However, some file information such as ACLs and attributes will be lost if the restore directory's filesystem does not support them.

To restore a backup, the steps to follow are:

  1. On the main page of the Filesystem Backup module, select the type of filesystem that the backup was made from, using the list next to the Restore backup of filesystem type button. Because there are different programs for restoring different types of filesystems, the restore options will vary depending on the type you choose.

  2. Click the Restore backup of filesystem type button, which will take you to the restore options page. Figure 14.3 shows the page for restoring an ext2 or ext3 filesystem backup.

    Figure 14.3. The backup restoration form.

  3. If restoring from a local file, set the Restore from file or device field to the File or tape device option and enter the file that you want the backup read from into the text field next to it.

    Restoring from a tape drive is similar to reading from a file, but instead of entering a filename into the File or tape device field you must enter the device file for the tape drive: /dev/st0, for example.

    If restoring from another server, you must select the Host option and enter a hostname, remote username, and file or device name on the remote server. As explained in Section 14.3 "Adding a New Backup", the server must have been configured correctly to allow remote access.

  4. By default, everything in the backup will be restored. To extract only some files, set the Files to restore option to Listed files and enter paths to the files you want to restore into the field next to it. To restore multiple files, the filenames must be separated by spaces.

    Because the paths used in the backup are sometimes relative to the mount point of the filesystem that they were originally on, it is often a good idea to use the Only show files in backup? option to see what the correct filenames are.

  5. In the Restore to directory field, enter the base directory under which you want the restored files to be saved.

  6. If the original backup spanned multiple files, set the Backup is split across multiple files? option to Yes.

  7. If you just want to view the contents of the backup without extracting any files, set the Only show files in backup? option to Yes.

  8. If you are familiar with the restore command used on your operating system, the Extra command-line parameters field can be used to enter extra options to be passed to the program, such as –A /tmp/archive. Otherwise, leave it blank.

  9. When you are ready to restore, click the Restore Backup Now button. If extracting files for real, a page showing the output of the appropriate restore command will be displayed. If you chose to just view the files in the backup, the page will display a list produced by the restore command instead.

When restoring a backup from an xfs filesystem, different options are available on the restore form. The Files to restore option does not exist, so all files in the backup will be extracted. However, there is an Overwrite existing files option that can be set to Never to protect existing files, or Unless newer than backup to protect files that have been modified since the backup was made.

One problem with using Webmin to restore is that it cannot cope with backups that span multiple tapes. Normally the restore command would prompt the user to eject the first tape and insert the second, but that is not possible when it is being run by Webmin.


14.7 Configuring the Filesystem Backup Module

Clicking on the Module Config link in the top-left corner of this module's main page will bring up a form for setting options that control how it behaves. The available settings and their meanings are see in Table 14.1.

Table 14.1. Module Configuration Options

Do strftime substitution of backup destinations?

If Yes is selected in this field, the backup destination path will have any special codes starting with % replaced with components of the current time and date. For example, %m will be replaced with month number, %d with the day of the month and %y with the year. These are the same substations that the standard UNIX strftime function uses. This option is useful if you want the backup to be written to a different file each day, instead of over-writing the same file every time.

The default option is No, which turns off this behavior.

Send mail via SMTP server

When Local sendmail executable is selected, the output from scheduled backups will be sent by running the sendmail command on your system, the path to which is taken from the Sendmail Configuration module. However, you can tell the module to send email by making an SMTP connection to some other host instead, which may be necessary if your system does not run a mail server at all, or runs one other that Sendmail. Just select the second radio button and enter a hostname into the text box.


14.8 Other Operating Systems

Many UNIX operating systems have similar dump and restore commands to Linux, and several of them are supported by this Webmin module. However, the options available differ slightly, so the backup and restore forms on different systems will not be exactly the same as Linux.

The currently supported systems and their differences are:

Sun Solaris On Solaris, ufs filesystems can be backed up and restored using the ufsdump and ufsrestore commands. When creating a backup, the Split across multiple files? and Tape size options are not available—instead, there are Verify data after backup? and Eject tape after backup? options whose meanings should be obvious. Solaris also supports the backing up of multiple directories at once, by entering multiple paths separated by spaces into the Directory to backup field.

For restoring on Solaris, the options are essentially the same as on Linux.

FreeBSD and Apple MacOS X Both these operating systems have almost identical dump commands and available options in Webmin, due to the BSD ancestry of MacOS X. When making a backup, the Split across multiple files? and Dump label fields are not available, but Tape size is. The only filesystem type that can be backed up is ufs and a backup must be of an entire filesystem, not just any directory. Unfortunately, on MacOS X almost all filesystems are in Apple's native hfs format.

When restoring, the only difference is an additional Just test backup? option which when set causes the restore command to do everything except write to disk.

SGI Irix On Irix, the only filesystem type that can be backed up with Webmin is xfs, even though there is a dump command for older efs filesystems. As with the xfs filesystem on Linux, only entire filesystems can be backed up, not arbitrary directories. The Tape size option is not available, but instead you can limit the size of files to include with the Maximum file size to include option, and turn off the backing up of attributes with the Include file attributes? option.

When restoring a backup on Irix, there is no option to specify which files to extract—instead, everything in the backup will be restored. However, there is an Overwrite existing files? option to protect existing files, or existing files that are newer than the backup, from being overwritten.

Due to the low-level nature of backups made using the dump family of commands, a backup created on one operating system will not be restorable on any other.


14.9 Summary

After reading this chapter, you should be able to use Webmin to create backups of data on your system's local hard disks, and restore those backups if needed. You should also understand the difference between the dump backup format used by the module covered here, and those created by commands like tar and cpio. On a system running important servers or hosting vital data, proper backups are vital—and Webmin can help you create them.


Chapter 15. Internet Services

This chapter covers the super servers inetd and xinetd, which are responsible for starting servers for protocols like telnet and FTP when needed.


15.1 Introduction to Internet Services

Heavily used network services such as email, proxying, and web serving are handled by server processes that run continually and have their own complex configuration files and Webmin modules. However, there are other services like telnet, finger, and POP3 that do not need any configuration and do not need their own permanent server process. Instead, their servers are run when needed by a super server like inetd or xinetd which listens for network connections on multiple ports. Only when it receives a connection does it start the appropriate process to communicate with the client, which exits when the connection is closed. This saves memory by limiting the number of processes running at any one time, but makes the handling of new connections slightly slower.

Every service has a short name like telnet or pop3, a port number like 23 or 110 and a protocol like TCP or UDP. The file /etc/services lists all the service names and their corresponding ports numbers that your system knows about, only a few of which may have a super server or other server listening on them.

The most commonly used super server is inetd, which is used by almost all Linux distributions and UNIX variants. All server settings are stored in the configuration file /etc/inetd.conf. In addition to starting servers in response to the TCP and UDP connections, it can also handle RPC (remote procedure call) function calls in a similar way. One major shortcoming of inetd is its inability to reject connections depending on the client IP address. However, this can be overcome by using an intermediate TCP-wrappers server program, which has its own IP access control configuration file.

Another super server that is gaining in popularity and has more features is xinetd, which uses the /etc/xinetd.conf configuration file and sometimes other files under the /etc/xinetd.d directory. Like inetd, it can launch server processes in response to TCP and UDP connections, but does not support RCP. Its major advantage is built-in support for restricting connections to certain client IP addresses without the need for a separately configured program. It can also re-direct an incoming connection on certain ports to another host and port by making its own client connection and forwarding data back and forth.

Because inetd and xinetd have totally different configuration files and file formats, there is a separate Webmin module for configuring each of them. Most Linux distributions will ship with one or the other, but in some cases both can be installed and co-exist peacefully. The only limitation is that they cannot both listen on the same port at the same time.


15.2 The Internet Services and Protocols Module

This module deals with the configuration of inetd, and can be found under the Networking category in Webmin. If the icon is not visible, Webmin has detected that it is not installed. This could be because your distribution is using xinetd instead, in which case you should skip down to Section 15.8 "The Extended Internet Services Module". If neither module is visible, check your distribution CD or website for an inetd or xinetd package.

The module's main page (shown in Figure 15.1) displays two tables, one for Internet Services that respond to TCP or UDP connections, and one for RCP Programs. In the Internet Services section, the names and protocols of all services are shown—in some cases, the same service may be recognized for more than one protocol. Each service can be in one of three states, indicated by the font its name is shown in:

Enabled (bold) A server program has been assigned to this service, and it is currently active.

Disabled (bold-italic) A server program has been assigned, but it is not active. This corresponds to a commented-out entry in the inetd.conf file.

Unassigned (normal) No server program has been assigned to this service, meaning there is no inetd.conf entry for it.

Figure 15.1. The Internet Services and Protocols module main page.

If the module configuration option Show services with no program has been set to No, services in the unassigned state will not be displayed. This is the default on some operating systems, due to the large number of services that the system knows about.

Most Linux distributions ship with almost all services in the disabled state by default. This limits the number of unnecessary services that your system allows connections to, and thus reduces the chance of a security hole in one of the server programs being exploited by an attacker.

Because each service is shown with only a short name like telnet or chargen, it is not obvious to an inexperienced administrator what each of them do. Some of the more commonly used services and their purposes are seen in Table 15.1.

The daytime, echo, and chargen services for both TCP and UDP protocols are handled internally by inetd when enabled, not by a separate server program.

Table 15.1. Common Services and Their Purposes

Service name

Protocol

Purpose

telnet

TCP

Remote login using the telnet command. Because a telnet connection is unencrypted, any username or password sent over it can theoretically be captured by an attacker. On modern systems, the secure SSH protocol is usually used instead.

pop3

TCP

Mail retrieval using almost any mail client program, such as Outlook, Eudora or Netscape. If you want users to be able to pick up mail from your system, this protocol should be enabled.

imap

TCP

A superior mail retrieval protocol that supports folders and server-side mail storage. However, fewer mail clients support it.

finger

TCP

Remote user lookup using the finger command.

ntalk

TCP

Person-to-person chat using the UNIX talk program.

ftp

TCP

File upload or download using an FTP client. There are several different FTP server programs available, the most common being wu-ftpd and proftpd. Because they have many options that are configured separately, each has its own Webmin module as covered in Chapters 40 and 41.

shell

TCP

Unauthenticated remote login using the rsh command. Because the shell protocol validates users by client IP address only, it is not considered secure—ssh is a far better alternative. However, you may have to enable it for remote backups from the Filesystem Backup module.

login

TCP

Remote login using the rlogin command. Because this can be configured to validate users by client address only, it is considered insecure and rarely used.

exec

TCP

Remote command execution using the rexec program. Rarely used on modern systems, due to the superiority of ssh.

daytime

TCP

Upon connection, displays the server time in a human-readable format.

daytime

UDP

Like the TCP daytime service, but sends the human-readable time back in a UDP packet.

time

TCP

Up connection, displays the system time as a 4-byte binary number.

time

UDP

Like the TCP time service, but sends the binary time back in a UDP packet.

echo

TCP

Sends back any data that is sent to it.

echo

UDP

Sends back any packets that it receives.

chargen

TCP

Produces an endless stream of data containing printable ASCII characters for as long as a client is connected.

chargen

UDP

Like the TCP chargen service, but sends back a single UDP packet of ASCII characters in response to each one received from a client.


15.3 Enabling an Internet Service

If you want to allow users to fetch mail from your system using the POP3 protocol or login via telnet, it is necessary to turn on the appropriate Internet service if it is not currently enabled. To do this, the steps to follow are:

  1. On the main page of the module, click on the name of the service that you want to enable in the Internet Services table. This will take you to the page shown in Figure 15.2 for editing its details.

    Figure 15.2. Editing an Internet service.

    If unassigned services are not displayed on your system, you can enter the service name and select the protocol in the fields next to the Edit service button. Clicking the button will take you to the editing form, assuming the service name is recognized.

  2. The Service name, Port number, Protocol, and Aliases fields should be left unchanged unless you want to rename the service or change the port it is listening on. For services that you did not create yourself, changing any of these fields is a bad idea, as it may prevent programs on your system connecting to other servers.

  3. To enable the service in the Server program section, select the Program enabled option. If Program disabled was selected previously, then all the other settings in the section should be correct and will not need to be changed.

    However, if No program assigned was selected before, then you will need to choose a server program and a user for the server to run as. Select the Program field Command option and enter the full path to the server program into the field next to it, such as /usr/sbin/in.ftpd for an FTP server. In the Args field, enter the server command again and any arguments that it needs, such as in.ftpd –l –a. Even though the program path is in the Command field, the program name must appear in the Args field as well.

    You will need to enter into the Execute as User field a username for the server program to run as. For almost all servers, this will be root. One of the Wait Mode options must be set as well—unless the server runs and executes very quickly, choose Don't wait.

    Some services such as daytime, echo, chargen, and discard are handed internally by inetd. If you are enabling one of them, just select the Internal to inetd. No program or arguments need to be entered, and the user the server executes as is irrelevant.

  4. When you are done, click the Save button. As long as there are no errors and the chosen server program actually exists, the browser will return to the list of services on the main page.

  5. Click the Apply Changes button at the bottom of the page to make your changes active.

In some cases, you will not be able to enable a service because the corresponding server program is not installed yet. If this is the case, use the Software Packages module to install it from your Linux distribution CD or website.

If you want to disable a service, just follow the same steps but select the Program disabled option instead. This is better than choosing No program assigned as it is easy to turn the service back on again without having to re-enter the server program details.


15.4 Creating Your Own Internet Service

In some situations, you may want to add a new server to your system that listens on a port not assigned to anything else. You might want to run a telnet server on some non-standard port, or redirect traffic from one port on your system to another server using a program like nc. If you are just trying to turn on some standard service like ftp or imap, the instructions in this section are not for you—see Section 15.3 "Enabling an Internet Service" instead.

The steps to follow to create a new service are:

  1. On the main page of the module, click the Create a new internet service link. This will take you to the service creation form, which is similar to the editing form in Figure 15.2.

  2. Fill in the Service Name field with a unique name for your service.

  3. Enter the port number you want the service to be associated with into the Port Number field.

  4. Select the protocol from the Protocol list. This will almost always be TCP, but in some cases you may need to use UDP.

  5. In the Aliases field, enter any alternate names that you want the service to be referred to by.

  6. Assuming you want to have a server program associated with this service, choose the Program enabled option in the Server Program section. Otherwise all that will be created is an association between a service name and port number.

  7. For the Program field, select the Command option and enter the full path to the server program into the field next to it—for example /usr/local/bin/someserver. In the Args field, enter the program name and any command line arguments that it should be run with, such as someserver –foo.

    To give another example, if you wanted to create a service that displayed all the processes running on your system to anyone who connected via telnet, you could set the Command to /bin/ps and the Args to ps auxwww. (This would be a bad idea from a security point of view, though.)

  8. If the server program is going to take more than a second to run, or if it accepts any input, set the Wait mode field to Don't wait. Otherwise inetd will stop handling new network connections until the program has finished. The only advantage of this Wait until complete mode is a slight reduction in memory usage.

  9. In the Execute as User field, enter the username of the UNIX user that the server program should run as. This is usually root, but can be anyone.

  10. To limit the rate at which inetd will accept connections for your service, enter a number into the Max per Minute field. If the limit is exceeded, subsequent connections will be refused until the next minute.

  11. By default, the group that the server program runs as is the primary group of the user set in the Execute as User field. To change this, enter a group name into the Execute as Group field.

  12. Click the Create button to create your service. As long as there are no errors in the form, you will be returned to the list of services on the main page.

  13. Click the Apply Changes button to make the service active.

Once a service has been created, you can test it by running telnet localhost portnumber at the shell prompt on your system. You can edit your service at any time by clicking on its name on the main page, and changing any of the options before clicking Save—or Delete if you want to get rid of it. After making any modifications, the Apply Changes button must be used to make them active.


15.5 Creating and Editing RPC Programs

RPC is a protocol and data format that is the basis for other protocols like NFS and NIS. RPC clients make function calls to RPC servers, passing parameters and getting back results. To the client or server, making a remote procedure call is no more difficult than calling a normal library function, which makes writing programs that use RPC much easier than creating your own protocol from scratch.

An RPC program is a set of functions that are handled by a server. Each program has a unique number, similar to the port of an Internet service. Programs are not associated with a particular protocol, as they can generally accept connections and function calls via UDP or TCP. Nor do they have a fixed port, as they are assigned dynamically when needed.

RPC servers (like the NIS and NFS servers) that handle a large amount of traffic have their own processes that run all the time. However, some servers that need to be run only occasionally can be executed by inetd only when needed—just like infrequently used Internet services. Some of the more commonly used RPC programs are:

On some systems, these RPC programs may be handled by servers that are not run from inetd but instead as stand-alone processes. In that case, the Bootup and Shutdown module (explained in Chapter 9) is the place to activate or de-activate them. Due to the small number of common RPC programs and their limited usefulness, many Linux distributions do not have any programs enabled or disabled in the inetd configuration by default. However, this is not the case on other operating systems like Solaris.

Table 15.2. Common RPC Programs and Their Purposes

Program name

Purpose

rquotad

Remote disk quota retrieval. If a system is NFS-exporting a filesystem with quotas, this program can be used by the quota command on the client to display used and available blocks and files on the NFS-mounted filesystem.

rusersd

Requesting the list of users logged into a system. The rusers command can be used to display users logged into one or more servers.

walld

Broadcasting a message to users on a server. Like the wall command for sending a message to local users, the rwall command sends to users on another system by calling this RPC program.

If you want to make use of an RPC protocol which is not currently enabled, you can use this module to turn it on. Of course the appropriate RPC server program must be installed first, and the inetd on your system must support RPC programs. If so, the steps to follow are:

  1. On the main page of the module, click on the program name from the RPC Programs table. This will take you to the program editing form shown in Figure 15.3.

    Figure 15.3. The RPC program editing form.

  2. Under the Server Program section, select the Program enabled option. If Program disabled was selected previously, then all the other settings in the section should be correct and will not need to be changed. However, if No program assigned was checked, you will need to fill in several other fields.

    The RPC Versions field should be set to the range of versions that the server program supports, such as 1-3.

    The Socket Type field should be set to Datagram, and the Protocol field set to only the udp option.

    For the Server Program field, enter the full path to the RPC program, such as /usr/sbin/rpc.rusersd. For the Command field, enter the program name and any arguments, such as rpc.rusersd –a.

    For the Wait Mode, select Don't wait.

    For the Execute as User field, enter the username you want the server program to run as—usually root.

  3. When done, click the Save button. As long as there are no errors in your input, you will be returned to the main page of the module where the RPC program should appear as enabled.

  4. Click the Apply Changes button to make the program active.


15.6 Configuring the Internet Services and Protocols Module

To access the configurable options of the Internet Services module, click on the Module Config link in the top left corner of its main page. This will take you to the standard configuration form, on which you can change the options shown in Table 15.3.

Table 15.3. Module Configuration Options

Show services with no program

If set to Yes, the main page will show only Internet services that have an enabled or disabled server program assigned. On most distributions the default is No, but some have so many known services that this option has to be turned on to limit the size of the services list.

Sort services and programs by

Controls the ordering of Internet and RPC services on the main page.

If Name is selected, they will be ordered by service name.

If Assignment is selected, all those that have an enabled server program will be listed first, followed by those with a disabled program and finally those that are unassigned.

If Order in file is chosen, the services will be displayed in the same order as they are stored in /etc/services, which is usually by port number.

The rest of the module configuration options under System configuration are set automatically by Webmin based on your operating system type, and so should not be changed.


15.7 Other Operating Systems

Almost all versions of UNIX include inetd as standard, and use it to launch infrequently run server programs in the same way that Linux does. However, its configuration file format and capabilities are slightly different on other operating systems, which means that the module's user interface will not be exactly the same. The main page will always show lists of Internet and RPC services, but when editing or creating a service, different fields and options will be available depending on the UNIX variant you are running:

Sun Solaris

  • When editing an Internet service, the Max Per Minute and Execute as Group fields are not available.

  • Solaris versions 8 and above support IPv6 TCP and UDP protocols, as well as the standard IPv4 that Linux uses.

  • Many RPC services exist in the disabled state by default, for things like NFS quotas and locking.

FreeBSD

  • RPC services cannot have programs assigned. All you can do is edit the service names and program numbers.

  • When editing or creating a service, you can control the number of server programs that can be active at any one time with the Max Child Processes field.

  • Also when editing, you can set the login class that the server program runs as with the Execute as Login Class field.

NetBSD

  • As on FreeBSD, the Max Child Processes and Execute as Login Class fields are available when editing or creating a service.

  • As with Solaris, Internet services can use IPv6 TCP and UDP protcols.

OpenBSD, Compaq Tru64/OSF1, IBM AIX, SCO OpenServer, and SCO UnixWare

  • As on Solaris, the Max Per Minute and Execute as Group fields are not available.

SGI Irix

  • The Max Per Minute and Execute as Group fields are not available when editing a service.

  • There is an additional checkbox below the server program Command field labeled Command may not exist? If this is set, it tells inetd to ignore the service if the server program is not installed. By default, this is turned on for many services related to Irix packages that are not installed by default.

HP/UX

  • On HP/UX, the module has exactly the same options as on Linux.

Apple MacOS X

  • As on Solaris, the Max Per Minute and Execute as Group fields are not available.

  • RPC services cannot have programs assigned, as on FreeBSD.

  • Instead of being stored in the /etc/services file, service names and ports are in a NetInfo table. Webmin dumps and re-loads this table to read and edit services.


15.8 The Extended Internet Services Module

This module allows you to configure xinetd, a super server that is similar in purpose to inetd but has several additional features. Like the Internet Services and Protocols module, this one can also be found under the Networking category. However, its icon will appear only if Webmin detects that xinetd is installed, which it does by looking for the /etc/xinetd.conf file. If you have compiled and installed it manually, you may need to create a symbolic link to the real location of xinetd.conf.

The main page lists all services that have server programs assigned, their port numbers, protocol, program, and active status—see Figure 15.4 for an example. Services with no programs are never shown, unlike in the Internet Services module.

Figure 15.4. The Extended Internet Services module.

On Linux distributions that use xinetd, most server program packages include a file that adds an appropriate service to the list shown on the main page. These are generally disabled by default, so that services are not unexpectedly enabled the moment you install them.

If you are using a different operating system on which you have installed xinetd, the user interface will be exactly the same as on Linux. However, server program packages will probably not set up services when installed.


15.9 Enabling or Editing an Extended Internet Service

If you want to allow users to fetch mail from your system using the POP3 protocol or login via telnet it is necessary to turn on the appropriate service in this module, assuming it is listed on the main page. If not, you will need to first install the appropriate package from your distribution website or CD, which should add an entry for the service. If not, see Section 15.10 "Creating an Extended Internet Service".

Existing services can also be changed in other ways—for example, to restrict the allowed client IP addresses or number of concurrent connections. To edit a service, the steps to follow are:

  1. On the main page of the Extended Internet Services module, click on the name of the service that you want to edit. This will take you to the form shown in Figure 15.5.

    Figure 15.5. Editing an extended Internet service.

  2. The Service name, Socket type and Protocol options should all be left unchanged. The Port field should be changed only if you know what you are doing.

  3. To turn on the service, set the Service enabled? field to Yes. Or if it is already enabled and you want to turn it off, select No.

  4. If you want the service to be accessible only via a single IP address on your server, enter it into the Bind to address field. This can be useful if you have multiple virtual IP interfaces on your system and want different servers to listen on different addresses.

  5. Most of the fields under Server program options can be left unchanged, unless you want to limit the amount of load the service puts on your system. If so, you can set the Max concurrent servers field to the maximum number of server processes that should be allowed to run at any one time. The Maximum connections per second and Delay if maximum is reached fields can be set to limit the rate at which clients are allowed to connect and the amount of time that the service is disabled if that rate is exceeded.

  6. To control which addresses clients are allowed to connect from, use the fields in the Service access control section. If Allow access from is set to Only listed hosts, only the IP addresses (like 192.168.1.55), hosts (like server.foo.com) and networks (like 192.168.1.0/24) entered will be allowed. If Deny access from is set to Only listed hosts, the hosts, IP addresses, and networks entered will be prevented from connecting.

    If a client matches an entry in both lists, the most specific entry will be used to determine whether access is allowed or denied. For example, if 192.168.1.10 was allowed and 192.168.1.0/24 was denied then a client with IP address 192.168.1.10 would be able to connect.

  7. If you want to limit the times at which the service can be used, fill in the Allow access at times field. It must be in the format HH:MM-HH:MM, such as 9:00-17:00 to allow access during normal working hours.

  8. Click the Save button when you are done making changes. As long as you haven't made any mistakes, the browser will return to the module's main page.

  9. Click the Apply Changes button to make your modifications active.

If you want to delete a service totally, you can click the Delete button on the editing form instead. However, it is usually better to simply disable it so that it can be easily turned back on later.


15.10 Creating an Extended Internet Service

If you want to enable a protocol that is not in the list on the main page, or redirect traffic from a particular port to another host, then you will need to create a new service using this module. The appropriate server program for the service must be installed first, unless you are setting a redirection. The steps to follow are:

  1. Click on the Create a new internet service above or below the list on the main page. This will take you to the creation form, similar to the one in Figure 15.5.

  2. If the service is for a standard protocol like telnet or finger, enter its name in the Service name field. The Port number can then be left set to Standard.

    Otherwise, enter a unique name into the Service name field and set the Port number to the port you want the service to listen on.

  3. If you want the service to be accessible only via a single IP address on your server, enter it into the Bind to address field. This can be useful if you have multiple virtual IP interfaces on your system and want different servers to listen on different addresses.

  4. Set the Protocol field to the protocol you want the service to use, usually TCP. The Socket type field should be set to Stream for TCP protocol services, or Datagram for UDP services.

  5. If your service is going to use a server program, set the Service handled by option to the Server program option and enter its command and any arguments into the field next to it—for example, /usr/sbin/in.telnetd –a.

    If the service is just redirecting traffic to another host, select the Redirect to host option and enter the destination hostname and port in the corresponding fields. Redirection can be useful for making services on an internal network system available to the rest of the Internet, if your firewall or gateway host is running xinetd.

  6. In the Run as user field, enter the name of the UNIX user that the server program will be run as. This is not necessary for redirection services.

  7. Unless the server program always completes very quickly, set the Wait until complete field to No. If you leave it set to Yes, xinetd will not process any more connections until the program finishes.

  8. To limit the rate at which clients can connect, set the Max concurrent servers and Maximum connections per second fields as explained in Section 15.9 "Enabling or Editing an Extended Internet Service".

  9. To limit the addresses from which clients can connect or the times at which connections are allowed, set the fields under Service access control as explained in the list above.

  10. When done, click the Create button. If there are no errors in the form, you will be returned to the main page on which your new service should now be listed.

  11. Click the Apply Changes button to make the service active.

Once a service has been created, you can test it by running telnet localhost portnumber at the shell prompt on your system. You can edit or delete your service at any time by following the instructions in Section 15.9 "Enabling or Editing an Extended Internet Service".


15.11 Editing Default Options

There are several global options that apply to all services handled by xinetd, for logging and IP access control. To edit these options, the steps to follow are:

  1. Click the Edit Defaults button at the bottom of the module's main page, which will take you to the default options form.

  2. To restrict the addresses from which clients can connect to any service, fill in the Allow access from and Deny access from fields. They accept the same input as the fields of the same name on the service form, as explained in Section 15.9 "Enabling or Editing an Extended Internet Service".

    Any IP access controls configured for an individual service will override the default settings that you enter on this form.

  3. To have xinetd log to syslog, set the Xinetd logging mode field to Log to syslog facility and choose the facility and priority that it should use. Chapter 13 explains in detail how to configure the log file that messages from xinetd will be written to, based on the selected priority and facility. Normally, this is the default and best option.

    If you want xinetd to log directly to a file, select the Log to file option and enter the log file path into the field next to it. To have a warning message logged when the file becomes too big, enter a file size in bytes into the Soft file limit field. To set a file size limit that will never be exceeded, fill in the Hard file limit field. If the soft limit is set but the hard limit is not, it will default to 1 percent more than the soft limit. If neither is set, the log file will grow forever—which could cause all your disk space to be consumed by an attacker making millions of connections to xinetd.

    To turn off logging altogether, set the Xinetd logging mode field to Disable logging.

  4. To control which events are logged, choose the appropriate options from the On successful connection log and On failed connection log fields.

  5. When done, click the Save button. As long as there are no errors in your input, you will be returned to the module's main page.

  6. Click the Apply Changes button to make the new defaults active.


15.12 Summary

This chapter has explained the purposes of the two common UNIX super server programs—inetd and xinetd—and the differences between them. After reading it, you should know how to enable standard services started by either of these programs, and how to create and edit your own services, if necessary. Several other chapters refer back to the modules covered in this one, especially those on FTP, CVS, and SSL tunnel servers.


Chapter 16. Network Configuration

This chapter explains how to set your system's IP address, hostname, DNS servers, and other network settings. It covers both Linux and other UNIX variants.


16.1 Introduction to Linux Networking

A Linux system can be connected to a network or the Internet in several different ways—for example, via an Ethernet network card, a token ring card, or a PPP (Point-to-Point Protocol) connection over a dial-up modem. If your system is never connected to a network, then this chapter is not for you. However, if you do need to set up network connections (especially to a local area network), then read on.

Every Ethernet network card, PPP connection, wireless card, or other device in your system that can be used for networking is known as an interface. Interfaces are usually associated with a piece of hardware (like a network card), but they can also be dynamically created (like PPP connections). For an interface to be used, it must first have an IP address assigned, which may be fixed and set from a configuration file on your system or dynamically assigned by a server. An Ethernet interface for a desktop PC on a company or home network would usually have a fixed address, whereas a PPP connection interface to an ISP would have its address dynamically assigned by a server at the other end.

PPP interfaces are configured in a very different way to Ethernet and other fixed hardware interfaces. Before one can be activated, a modem must be used to dial an ISP at a particular phone number and log in with a username and password. Only after the login is successful will the PPP interface have an IP address assigned by the ISP's access server. Other network settings on your system such as the DNS server addresses and default gateway will be assigned by the ISP as well. An Ethernet interface, however, can have an IP address set and start working at any time, and a system connected via Ethernet usually uses fixed DNS server and gateway addresses.

Sometimes an Ethernet interface will have its addresses dynamically assigned as well. If so configured, the system will broadcast a request for an address using the DHCP (Dynamic Host Configuration Protocol) when the interface is activated at boot time. This will be answered by a DHCP server, which supplies the IP address and possibly default gateway and DNS server addresses as well. DHCP is often used on large networks with many systems that frequently connect and disconnect (such as laptops), in order to avoid manually configuring each system with a fixed IP address.

One special network interface that is always available is the loopback interface. It always has the IP address 127.0.0.1, which is mapped to the hostname localhost. This interface cannot be used to communicate with other systems, just your own—for example, running the command telnet localhost will bring up the login prompt of your own system (assuming a telnet server is active).

Every interface has a name, like eth1 or ppp0. All Ethernet interfaces start with eth, PPP interfaces with ppp, loopback with lo and token ring with tr. The number tells you which network card of that type the interface is related to—if your system had two Ethernet cards, the first would be eth0 and the second eth1.

If your system is connected to a network any bigger than a small home LAN, one of the computers on the network will be the gateway. This is a server (or more likely a router) that knows how to route traffic to other networks or the Internet, perhaps by a PPP link, broadband connection, or other network card. For your system to communicate with those other networks, it must be configured with the IP address of the gateway.

All communication on an IP network is done using IP addresses like 192.168.1.10 or 210.23.128.117. Because addresses like this are not too easy for the average person to remember, they can have names associated with them as well, like server.foo.com. Any time a system needs to lookup an IP address for a hostname (or vice versa) it queries a DNS server which will supply the needed information, either from its own records or by querying other DNS servers on the network or Internet. For your system to be able to query a DNS server, it needs to be configured with the IP address or addresses of nearby servers and a default domain name to append to any hostnames.

Not all IP addresses are looked up from a DNS server though—some are stored in the /etc/hosts file on your system so that they can be found even when networking is not active. Typically the IP addresses for localhost and your system's hostname will be stored in this file, because they rarely change.

As would be expected, the Network Configuration module can be found under the Networking category in Webmin. The main page shows one icon for each of the four configuration categories—Network Interfaces, Routing and Gateways, DNS Client, and Host Addresses. All the editable forms and options in the module are under one of those four categories.

This module was designed mainly for configuring networking on systems with permanent network connections, such as Ethernet or token ring cards. If your system has only a dial-up PPP connection to the Internet, it will not be much use to you. Instead, you should use Webmin's PPP Dialup Client module, which allows you to set phone numbers, usernames, and passwords for dial-up connections.

The forms in this module only allow you to set up your system as a DNS and DHCP client. If you want to run your own DNS server on your network, see Chapter 30. To learn how to set up your own DHCP server, see Chapter 32.


16.2 Viewing and Editing Network Interfaces

To view the interfaces that are currently active on your system, click on the Network Interfaces icon on the main page of the module. This will take you to the page shown in Figure 16.1, which lists interfaces on your system in two categories. At the top under Interfaces Active Now are those that are currently enabled and have an IP address assigned. All loopback, Ethernet, and PPP interfaces will be shown, although not all will be editable using Webmin. At the bottom under Interfaces Activated at Boot Time are those which have been configured to be activated at boot. The two lists will not necessarily be the same, as some types of interface (such as PPP) are not activated at boot time and so will not appear in the second list.

Figure 16.1. The network interfaces page.

The steps to follow to change the IP address, active status, or other details of an interface are:

  1. If the interface appears under both Interfaces Active Now and Interfaces Activated at Boot Time (as most editable ones do), click on its name in the lower list. This will take you to a form for editing its settings, shown in Figure 16.2.

    Figure 16.2. The interface editing form.

  2. To assign a different address, enter it into the IP Address field. Or select the From DHCP option if you want the address to be dynamically assigned by a DHCP server on your network.

  3. If necessary, change the Netmask field. If it or the IP address is changed, you will also need to set the Broadcast address field based on the new netmask and IP.

  4. When editing an active interface, the MTU and Hardware address fields will be available. You should leave the MTU alone unless you really know what you are doing, as changing it could reduce network performance or cut your system off from the network altogether. The hardware address should be changed only if you want to give your network card a different Ethernet address, which is rarely necessary.

  5. If editing a boot-time interface, make sure the Activate at boot? field is set to Yes so that the interface is brought up when the system starts.

    If editing an active interface, make sure the Status field is set to Up so that it can be used immediately.

  6. When done editing a boot-time interface, click the Save and Apply button to save your changes for use at bootup time, and to make them immediately active.

    If you are editing an active interface, just click Save to activate your changes.

After changing any of your system's IP addresses, be sure to update any host address entries associated with them as well. See Section 16.6 "Editing Host Addresses" for details on how to do this. You may also need to update records in your DNS server as well.

An active interface can be shut down by clicking the Delete button on its editing form instead. Similarly, a boot-time interface can be removed (for example, if you have removed a network card) so that it will not be activated at startup by clicking the Delete button on its form.


16.3 Adding a Network Interface

There are two situations in which you might want to add a new network interface—if your system has just had a network card installed, or if you are adding an additional virtual IP address to an existing interface. In the latter case, the new virtual interface is not associated with its own separate network card, but instead adds an additional IP address to an existing Ethernet card. Virtual addresses are often used on systems hosting multiple websites, so that each site can have its own IP address.

Before an interface for a new network card can be configured, you must make sure that it is recognized by the Linux kernel and the appropriate kernel module loaded. There is no support in Webmin for doing this at the moment, but most distributions include a graphical tool for loading kernel modules, or a configuration file in /etc that specifies which modules to load. Once the interface is recognized, the steps to configure it are:

  1. On the main page of the module, click the Add a new interface link under Interfaces Activate at Boot Time. This will take you to the creation form, which is similar to the editing form in Figure 16.2.

  2. Enter the interface name (such as eth1 or tr0) into the Name field. This must correspond to whatever name has been assigned by the kernel.

  3. In the IP Address field, either enter an address or select the From DHCP option for it to be dynamically assigned.

  4. Enter the netmask for the network the interface is on into the Netmask field, such as 255.255.255.0.

  5. Set the Broadcast field based on the address and netmask. For example, if the IP was 10.1.2.3 and the netmask was 255.0.0.0, then the broadcast address would be 10.255.255.255.

  6. If you want the interface to be brought up at boot time, set the Activate at boot? field to Yes.

  7. Finally, click the Create button. Assuming there are no errors in your input, you will be returned to the list of interfaces.

  8. To make the interface active now, click on its name from the Interfaces Activate at Boot Time list. Then on the editing form, click the Save and Apply button. If any error occurs during activation (such as the interface not being recognized by the kernel) Webmin will display an error message.

A virtual interface adds an additional IP address to an existing real interface. Virtual interfaces have names like eth0:1, where eth0 is the name of the real interface and 1 is the virtual number. To add one, the steps to follow are:

  1. On the main page of the module, click on the real interface that you want to add a virtual address for, under Interfaces Activate at Boot Time.

  2. On the editing form, click the Add virtual interface link. This will take you to a creation form, similar to Figure 16.2.

  3. In the Name field, enter a number for the virtual interface. This must not be used by any existing virtual interface on the same real network card.

  4. Fill in the IP Address field with the address that you want to assign to the virtual interface.

  5. The Netmask and Broadcast fields should be set to the same addresses as the real interface. They would only be different if the virtual interface was on a different IP network that was sharing the same LAN as the network for the real interface.

  6. Assuming you want the virtual interface to be created at boot time, set the Activate at boot? field to Yes.

  7. Hit the Create button. As long as there are no errors in your input, you will be returned to the list of interfaces. Your new virtual interface will appear under its real parent in the Interfaces Activate at Boot Time section.

  8. To activate the virtual interface immediately, click on its name, and then on the editing form click the Save and Apply button.


16.4 Configuring Routing

Any system attached to a large network needs to know the address of a default gateway, as explained in the introduction. In some cases, the system itself may be a gateway as well—perhaps forwarding data between a local area network and a dial-up or broadband connection. In this case, it must be configured to forward incoming packets that are destined for some other address.

In some cases, traffic destined for certain networks may have to be sent via another router instead of the default gateway. Or if more than one IP network shares the same LAN, traffic for any of those networks must be sent using the correct interface. If either of these are the case on your network, static or local routes need to be configured so that the system knows where to send packets for certain destinations.

To change the default gateway used by your system or enable packet forwarding, the steps to follow are:

  1. On the Network Configuration module's main page, click the Routing and Gateways icon. This will take you to a form for configuring routing, which is unfortunately slightly different on each Linux distribution due to differences in the underlying configuration files.

  2. Enter the IP address of the default gateway into the Default router field.

    On Red Hat Linux versions 8 and above, this field and the one mentioned in the next step is replaced by a table of default routers and interfaces instead. This can be used to define a different gateway for each interface, which can be useful if your system does not always use the same one. In most cases, however, you should just select Any from the menu under Interface and enter the router's IP address into the field under Gateway.

  3. Enter the name of the network interface that must be used to reach the default router into the Default route device field. On some Linux distributions this field is optional, meaning that the system will work it out automatically. On others, there is a Gateway field next to the Default router input.

  4. To enable routing, set the Act as router? field to Yes.

  5. On Red Hat, Mandrake, MSC and Turbo Linux, you can set up static routing using the Static routes table. For each static route, you must enter one row containing the following information:

    • In the Interface column, enter the interface that will be used to reach the router, such as eth0.

    • In the Network column, enter the address of the remote network, such as 192.168.5.0.

    • In the Netmask column, enter the network's netmask, such as 255.255.255.0.

    • In the Gateway column, enter the IP address of a router that knows how to forward data to the network, such as 192.168.4.1.

  6. On those same distributions, you can set up routing to additional IP networks on connected LANs using the Local routes table. For each route, you must enter one row containing the following details:

    • In the Interface column, enter the name of the interface that the LAN is connected to, such as eth1.

    • In the Network column, enter the address of the additional IP network, such as 192.168.3.0.

  7. Click the Save button when done. Any changes will not be activated immediately—instead, they will take effect when your system is next booted. On some Linux distributions, the module's main page will have a button labeled Apply Configuration at the bottom, which if clicked will activate the routing settings immediately. It will also make any boot-time network interfaces immediately active as well, so be careful when using it from a web browser on another system—your network connection may be cut off if the network configuration is incorrect.

If your system's primary network connection is via PPP dialup, then the default gateway will be assigned automatically when you connect and removed when you disconnect. Therefore there is no need to set it up using this form.


16.5 Changing the Hostname or DNS Client Settings

Every UNIX system has a hostname, which appears in the login prompt, system logs, outgoing email and on every Webmin page. Normally the hostname is the same as or part of the DNS name for the system's IP address, but this does not have to be the case, especially if the system is not connected to a network or only connects occasionally via dialup. However, for permanently connected systems the hostname should be the hosts fully qualified DNS name (like server1.foo.com), or just the first part (like server1). Anything else is likely to cause confusion and possibly network problems.

When a Linux system is first set up, you get to choose the hostname as part of the distribution's installation process. However, it can be changed at any time, either using Webmin, a GUI tool provided by the distribution, or the hostname command. To make the change in Webmin, the steps to follow are:

  1. On the main page of the Network Configuration module, click the DNS Client icon. This will take you to the form for editing the hostname and DNS options shown in Figure 16.3.

    Figure 16.3. The DNS client and hostname form.

  2. Enter the new hostname (composed of letters, numbers, underscores, and dots) into the Hostname field.

  3. Click the Save button to have it immediately changed. Your browser will be returned to the module's main page.

  4. Change the host address for your old hostname to the new one, as explained in Section 16.6 "Editing Host Addresses".

  5. If you are running a DNS server, don't forget to update the entry for your system there as well.

As explained in the introduction to this chapter, in order to look up hostnames and IP addresses your system will almost certainly need to know the addresses of DNS servers on the network.

To change the system's DNS settings, follow these steps:

  1. Click on the DNS Client icon on the main page of the module, which will take you to the form shown in Figure 16.3.

  2. Enter the addresses of up to three servers into the DNS servers field. If the first is not available, your system will try the second, and finally the third. Most networks will have at least a primary and secondary DNS server to increase reliability in case one fails.

  3. The Resolution order field can be used to control where your system will look when resolving hostnames and IP addresses. Generally the defaults are reasonable, with Hosts (the /etc/hosts file) listed first and DNS later. However, if you are using NIS for hostname resolution you will need to make sure it is selected somewhere in the order.

  4. In the Search domains field, enter any domain names that you want your system to automatically append to resolved hostnames. For example, if foo.com was listed and you ran the command telnet server1 then the IP address for server1.foo.com would be looked up.

  5. When done, click the Save button. Any changes will take effect immediately in all programs running on your system.

If your system's only network connection is via dialup, the DNS servers may be assigned automatically by your ISP depending on your PPP configuration.


16.6 Editing Host Addresses

Host addresses are mappings between an IP address and one or more hostnames that are stored in the /etc/hosts file on your system. Because they are stored locally, they can be looked up at any time, even when a DNS server is not accessible. On a small network with only a few systems, you may choose not to run a DNS server at all, but instead keep the addresses of every system in the hosts file on each system. In fact, this is what was done in the early days of the Internet before DNS was developed.

To view the addresses on your system, click the Host Addresses icon on the module's main page. There will always be an entry for localhost, and probably one for your system's hostname as well. If your system's IP address or hostname has been changed, the host addresses list will probably not reflect the change, which could cause problems. To change a host address, the steps to follow are:

  1. Click on its IP address from the list, which will take you to an editing form.

  2. Enter the new address into the IP Address field.

  3. Enter any hostnames into the Hostnames field. It is always a good idea to enter both the short and long forms of any hostname, such as server1.foo.com and server1 so that both can be used.

  4. Click the Save button, and if there are no errors in the form your browser will return to the list of hosts and addresses.

You can add extra host addresses by clicking the Add a new host address link above or below the link and filling in the same form. There are no restrictions on the same hostname being associated with two different IP addresses, or the same IP address appearing twice in the list.


16.7 Module Access Control

As Chapter 52 explains, it is possible to limit the features of this module that a particular Webmin user or group can access. For example, you may want to allow a user to edit only the host addresses list, or to be able to view settings only instead of editing them. To do this, create or edit a Webmin user who has access to the module, and then follow these steps:

  1. In the Webmin Users module, click on Network Configuration next to the name of the user or group that you want to restrict. This will bring up the module access control form.

  2. Change the Can edit module configuration? field to No, so that the user cannot configure the module to edit a host addresses file other than /etc/hosts.

  3. The Can edit network interfaces? field determines which interfaces the user can see and edit. Setting it to Yes allows editing of all of them, while choosing No prevents the Network Interfaces page from being accessed at all.

    If View only is chosen, all interfaces will be visible but the user will not be able to change any of their attributes. If Only interfaces is chosen, only those whose names (separated by spaces) are entered into the field next to it will be editable. All others will be only viewable.

  4. If the Can edit routing and gateways? field is set to Yes, the user will be able to set up the default router and static routes as normal. If No is chosen, the Routing and Gateways page will not be accessible at all, or if View only is chosen the current settings will be visible but not changeable.

  5. Similarly, the Can edit DNS client settings? and Can edit host addresses? fields can be set to Yes, View only and No to control access to the DNS Client and Host Addresses pages respectively.

  6. When you are done making selections, click the Save button to have the new restrictions immediately activated.

Be very careful giving an untrusted user the rights to edit any network configuration in this module, as he may be able to figure out a way to gain root access or disrupt other users by changing routes, host addresses, or interface settings.


16.8 Other Operating Systems

The Network Configuration module is also available on several other operating systems, with options fairly similar to those of Linux. Due to the different features supported by network configuration files on other versions of UNIX, in some sections the user interface is quite different. The supported systems and the variations between them and Linux are:

Sun Solaris and SCO UnixWare

  • When editing a boot-time network interface, all that can be changed is the IP address.

  • The boot-time settings for the loopback interface cannot be edited at all. Both operating systems always enable it at boot with the IP address 127.0.0.1.

  • On the routing and gateways page, multiple default routers can be entered. There is no need to specify a default route device though, as it is always worked out automatically.

FreeBSD and NetBSD

  • There is no option to use DHCP to automatically assign an address for an interface at boot time.

  • On the routing and gateways page, there is no default route device field. However, there is an additional Start route discovery daemon? option.

  • The hardware address of an active interface cannot be changed.

  • When creating a virtual interface, the netmask must be entered as 255.255.255.255.

OpenBSD

  • On the routing and gateways page, there is no default route device field. However, there is an additional Start route discovery daemon? option.

  • The hardware address of an active interface cannot be changed.

Mac OS X

  • On the routing and gateways page, only options for setting the default router and controlling it if this system acts as a router are displayed.

  • On the DNS client page, no list of resolution orders appears, because the hosts file is always checked first, followed by DNS.


16.9 Summary

This chapter has explained how to perform basic network configuration on your Linux or UNIX system. After reading it, you should know how to specify IP addresses for network interfaces, define routes and choose an DNS server. Unless your system has only a single dial-up connection to the Internet, the information presented here is important if you want to connect your machine to a network.


Chapter 17. Network Information Service

NIS is a protocol for sharing users, groups, and other information between multiple systems. This chapter explains how NIS works, and how to set up your system as either a client or server using Webmin.


17.1 Introduction to NIS

NIS was originally developed by Sun Microsystems, but is now available on Linux and many other UNIX operating systems. Its original name was YP (Yellow Pages), which is why many of the NIS commands start with yp.

On a network with many systems, users may be allowed to log in to any of those systems. Typically, to avoid having to create and update users on each system separately, NIS can be used to distribute a master list of users and groups to all hosts. Although distributing user and group information is the most common use of NIS, it can also be used to share hostnames and IP addresses, automounter maps, Internet services, and netgroups.

An NIS server is a system that stores tables of user, group, and other information. A client system connects to a server and queries it for stored information, usually by looking up usernames, hostnames, and so on. Normally a server system is also one of its own clients, so that it has access to the users and other data in its own tables.

Each server is responsible for a single NIS domain, and each client is a member of a domain. A domain has a short name, like marketing or foo.com, which is not necessarily the same as the network's DNS domain. When NIS is started on a client system, it can either broadcast for any server on the network for its domain, or connect to specific server IP addresses. A single network may have multiple NIS servers for different domains, each of which supplies different tables.

In order to reduce the load on the NIS server, a network may contain multiple servers that all have copies of the same tables. One is the master server and the rest are slaves, which just receive information from the master whenever it is changed. A client can then connect to either the master or a slave and query the same tables.

In recent years, a new version of the old NIS protocol has been developed, called NIS+. It solves many problems with the original protocol, the biggest being lack of security. However, it is more complex to configure and not as widely available. For these reasons, Webmin supports only the configuration of NIS clients and servers.

The file /var/yp/Makefile is usually the primary configuration file for an NIS server, as well as a make script that generates binary format table data from source text files. The server also reads the files /var/yp/securenets and /etc/ypserv.conf to control which clients are allowed to connect, and which tables they can query. Webmin directly updates all of these files, along with the table source files, when you are configuring NIS. The primary NIS server program is called ypserv, but others such as yppasswd (for processing password change requests from clients) and ypxfrd (for sending tables to slaves) may be run as well.

On client systems, the file /etc/yp.conf stores the domain name and NIS server IP addresses. Information about which services to query NIS for is stored in /etc/nsswitch.conf. All clients run the program ypbind, which passes queries for user, group, and other information from local programs to the NIS server.

The NIS Client and Server Webmin module allows you to set up your system as an NIS client and/or server. When you enter it from the Networking category, the main page simply shows five icons for the different areas of client and server configuration. If Webmin detects that the NIS client programs are missing from your system, the main page will instead display an error message—if this happens, check your Linux distribution CD or website for a package named something like ypbind.

The module is not supported on all versions of Linux. At the time of writing, only Red Hat, Mandrake, OpenLinux, Debian, SuSE, UnitedLinux, and MSC.Linux could use it. Because each distribution uses slightly different configuration files for NIS, there may be some differences in the user interface and default settings between different distributions, in particular on the client services and NIS server pages.


17.2 Becoming an NIS Client

To set your system up as an NIS client, there must already be an NIS server running on your network. If not, see Section 17.3 "Setting Up an NIS Master Server" for information on how to start one. Assuming there is an NIS server running and you know its NIS domain name, the steps to become a client are:

  1. On the module's main page, click the NIS Client icon. This will take you to a form for entering the domain name and NIS server IP addresses.

  2. In the NIS domain field, enter the name of your network's NIS domain.

  3. If you do not know the IP address of an NIS server, set the NIS servers option to Find by broadcast. This will work only if the server is on the same LAN as your system—if not, the broadcast will not be able to reach it.

    If you do know the address of an NIS server, select the Listed below option and enter all the master and slave server addresses into the text box. The more you enter the better, because your system will try to query each of them in turn when NIS is enabled. However, it is best to enter the nearest server first so that a more distant and thus slower server is not always queried.

  4. Click the Save and Apply button to have your settings saved and immediately activated. If your system cannot contact a server for the NIS domain, an error message will be displayed—otherwise, the browser will return to the module's main page.

  5. Now that you are connected to an NIS server, you must configure the system to actually query it for users, groups, and other information. To do this, click on the Client Services icon which will take you to the form shown in Figure 17.1.

    Figure 17.1. The NIS client services form.

  6. Each row of the client services form controls what your system will query when looking something up for a particular service. For each, you can select several sources that will be checked in order until one finds a match. The available sources are:

    Files Local configuration files, such as /etc/passwd or /etc/hosts.

    NIS This NIS server that your system is currently connected to.

    NIS+ The NIS+ server that your system is connected to. Configuring NIS+ is not supported by Webmin.

    NIS and Files This option only works for the UNIX users and UNIX groups services. If chosen, special lines in /etc/passwd and /etc/group starting with + or – can be used to indicate that some or all NIS users should be included. This is actually more flexible than just choosing the NIS source, as special + and – lines can be used to bring in only some users and groups, or change the attributes of those that are included.

    DNS This option makes sense only for the Host addresses source. It tells the system to query a DNS server when looking up hostnames, which is almost always what you want to do.

    Typically, you should set each of the services for which you want to use NIS (such as UNIX users and UNIX groups) to Files and NIS. Everything else should be left set to just Files, or in the case of Host addresses just Files and DNS. Your system will then look in the local system configuration file first (such as /etc/passwd) and then query the NIS server.

  7. When done, click the Save button. Your changes will take effect immediately in all programs, and any NIS users should be able to log in just as local users would.

Once you have used Webmin to make your system an NIS client, it will attempt to connect to a server at boot time. Failure to connect could cause the system to hang part way through the boot process, waiting for the server to become available. If the server goes down while your system is connected, any program that looks up user information may hang as well.

To stop your system from being an NIS client, the steps to follow are:

  1. On the main page of the module, click the NIS Client icon to go to the client options page.

  2. Set the NIS domain field to None (NIS disabled).

  3. Click the Save and Apply button. The system will no longer use NIS to look up any information, and will not connect at boot time. Any services that are configured to use an NIS source on the Client Services page will simply skip that source, and most likely use only local files instead.


17.3 Setting Up an NIS Master Server

Before your system can become an NIS, the appropriate server programs must first be installed—if they are not, when you click on the NIS Server icon an error message will be displayed. Check your Linux distribution CD or website for a ypserv or nis-server package, which should contain all the needed commands and files.

The first step in setting up an NIS server is deciding on a domain name. Typically, this will be the same as your Internet domain (such as foo.com), but anything made up of letters, numbers, and dots is allowed. After deciding, the steps to follow are:

  1. On the module's main page, click on the NIS Server icon. This will take you to a form for enabling the server and configuring other options, as shown in Figure 17.2. The form will look the same on most Linux distributions, but on Caldera's OpenLinux it will have far fewer options.

    Figure 17.2. The NIS server configuration form.

  2. Set the Enable NIS server? option to Yes. When the form is saved, the server processes will be started immediately and at each subsequent reboot.

  3. Enter your chosen domain into the Serve NIS domain field. This is better than choosing the Same as client option, even if they are going to be the same.

  4. Leave the Server type set to Master server. To set up a slave server, see Section 17.6 "Setting Up an NIS Slave Server".

  5. If NIS clients are incapable of looking up hosts and addresses in DNS themselves, turn on the Lookup missing hosts in DNS? option to have the master server do lookups for them. Only very old client operating systems like SunOS 4 need this.

  6. In the NIS tables to serve field, select all the tables that you want to make available to clients. Some of the most commonly used tables and their contents are:

    passwd UNIX users, as stored in the /etc/passwd file. Normally this contains passwords as well, instead of having them stored in a separate shadow table.

    group UNIX groups, as normally found in the /etc/group file.

    hosts Hosts and IP addresses, as found in the /etc/hosts file. Even though NIS can be used to store and lookup hostnames and addresses, it is almost always better to set up a DNS server instead.

    shadow Additional user information, including passwords. If this table and passwd are selected, depending on your NIS Makefile configuration you may be able to edit extended user information, such as expiry and warning dates.

    netgrp Netgroups, which are groups of hosts. These can be used when exporting directories via NFS, as explained in Chapter 6.

  7. If your network will have slave servers, it is advisable to set the Push updates to slaves? option to Yes. This way whenever a change is made to one of the NIS tables, all slave servers will be notified immediately so that they are in sync.

  8. Enter the IP addresses of any slaves (separated by spaces) into the Slave servers field.

  9. In the Master NIS files section, you can choose which files will be used as the sources for the NIS tables. Often by default the normal user, group, host, and other configuration files in /etc will be used, such as /etc/passwd, /etc/group, and /etc/hosts. This is not a good idea, though—instead, you should change the files for the tables that your server is using to similar filenames in the /var/yp directory, such as /var/yp/passwd and /var/yp/group. Once the server is running, it can be configured to become one of its own clients and so have access via NIS to any records in these files, instead of accessing them locally.

  10. When done, click the Save and Apply button. The NIS server will be started on your system, and be configured to start at boot time in future.

Now that the server is running, you can test it by configuring some other system as an NIS client for the chosen domain. Server settings on the form can be changed at any time by simply repeating the same steps, and they will become effective immediately.

To shut down your NIS server, the steps to follow are:

  1. Make sure any clients are no longer using your system as a server, either by turning off NIS on them altogether or having them use a different server.

  2. On the module's main page, click on the NIS Server icon to go to the server options form.

  3. Set the Enable NIS server? field to No.

  4. Click the Save and Apply button. The server processes on your system will be shut down, and prevented from starting at boot time in future.


17.4 Editing NIS Tables

Once your system is running as an NIS master server, you can use this Webmin module to edit records in the tables that it is serving. To see the editable tables, click on the NIS Tables icon, which will take you to a page with a menu of all tables and the contents of one displayed. Other tables can be shown by selecting one of them from the list and clicking the Edit NIS table button.

For most table types, Webmin will parse the contents of their files and display them as a table on the page, with one record per row. You can edit any record by clicking on its name in the first column, or add a new one by clicking the Add a new record link. However, some tables are in a format unknown to Webmin and so will be shown as raw text in a text box instead. If you know the correct format, the table can be manually edited and saved with the Save and Apply button. You can also switch any table to manual mode by clicking the Edit table manually link, if you prefer to work with the raw text.

The fields that exist in each record and the form for editing them are different for each type of table. The instructions below explain how to add, delete, and modify records in several frequently used tables. One commonality is that any changes will cause the NIS table to be automatically rebuilt from the changed source files, and pushed out to slave servers if configured to do so.

To create a new UNIX user for NIS clients, the steps to follow are:

  1. Select the UNIX users table from the menu and click the Edit NIS table button.

  2. Click the Add a new record link above or below the table of existing users, which will take you to the user creation form.

  3. Enter the user's name into the Username field, and an ID number for the new user into the User ID field. Unlike in the Users and Groups module, the ID will not be automatically chosen for you, so make sure it is unique.

  4. Enter the user's full name into the Real name field.

  5. Enter a home directory into the Home directory field. Unlike in the Users and Groups module, this will not be created for you and files will not be copied into it.

  6. Select a shell from the Shell menu, or select the Other option and enter the path to the shell program into the field below.

  7. Select the Normal password option for the Password field, and enter the new user's password into the text field next to it.

  8. Enter the numeric ID of the user's group into the Primary group ID field.

  9. If the shadow NIS table is enabled, you can set the optional Expiry date, Minimum days, Maximum days, Warning days, and Inactive days fields. These all have the same meanings as in the Users and Groups module, covered in Chapter 4.

  10. When done, click the Create button to have the new user added to the table.

Existing UNIX users can be edited by clicking on their names in the table, which will take you to an editing form with all the same fields as described above. Change any of the fields, and click the Save button—or to delete the user, click the Delete button at the bottom of the form. When deleting, the user's home directory will not be touched, so you may need to delete it manually.

To create a new UNIX group in NIS, the process is as follows:

  1. Select the UNIX groups table from the menu and click the Edit NIS table button.

  2. Click the Add a new record link above or below the table of existing groups, which will take you to the user creation form.

  3. Enter a name for the new group into the Group name field, and a numeric ID into the Group ID field. Make sure that the ID is not used by any other existing group.

  4. The Password field can be left untouched, as group passwords are almost never used.

  5. Fill in the Group members field with the usernames of users who will be members of the group, one per line.

  6. When done, click the Create button to have the new group added to the table.

As with users, you can edit a group at any time by clicking on its name from the table, which will take you to an editing form. Make any changes that you want, and click the Save button to save them—or use the Delete button to remove the group. Note that no checking will be done to see if it is the primary group of any existing users.

As the instructions for editing users and groups show, the process for editing any of the supported tables is quite similar. Currently, you can edit UNIX users, UNIX groups, Host addresses, Networks, Services, Protocols, Netgroups, Ethernet addresses, RPC programs, Netmasks and Aliases using forms in Webmin. All other tables must be edited manually.


17.5 Securing Your NIS Server

By default, an NIS server allows any client to connect to it and query tables, as long as the client knows the domain name. If your system is connected to the Internet, an attacker could guess the NIS domain and request a list of all NIS users. Even though their passwords are stored in encrypted format, it is still possible for obvious or dictionary word passwords to be discovered by a brute-force attack on the password encryption.

For this reason, it is wise to limit the addresses of clients that connect to the server to only those UNIX systems that are really clients. To set this up, the steps to follow are:

  1. On the main page of the module, click on the Server Security icon, which will take you to the form shown in Figure 17.3.

    Figure 17.3. The server security form.

  2. The rows in the Allowed clients table control which clients are allowed to connect. You can modify any of the existing entries, or use the empty row at the bottom to add a new one. To add more than one row, you will have to add them one at a time, saving and opening the form for each one.

    To grant access to a single host, under the Netmask column select Single host, and enter its IP address under Network/host address.

    To grant access to an entire IP network, select Netmask and enter a netmask (such as 255.255.255.0) into the field next to it, and the network address under the Network/host address column.

    To grant access to all clients, just select the Any host option under the Netmask column.

  3. When done, click the Save and Apply button. The new restrictions will take effect immediately, and you will be returned to the module's main page.

It is a good idea to let only clients on your own network connect, and deny all others. An even more secure alternative would be to allow only those systems that you know are NIS clients, assuming they have fixed IP addresses and do not change often.

Even if you restrict access to only trusted client systems, users who can log in to those systems via SSH or telnet may still be able to get a list of all NIS users and their encrypted passwords. To prevent this, it is possible to configure the server to allow only clients using trusted ports to access certain tables or fields within tables. Because on UNIX systems only the root user can create TCP or UDP sockets with port numbers below 1024, these low ports are considered trusted and safe from use by regular users.

It is also possible to prevent certain clients from accessing some NIS tables, but still allow them access to others. For example, you might want to give all client systems access to the Host addresses table, but only a trusted few the rights to the UNIX users table.

To restrict access to tables on your server, the steps to follow are:

  1. On the main page of the module, click on the Server Security icon to get to the form shown in Figure 17.3.

  2. The Client map restrictions table controls which NIS tables can be accessed by certain client systems, and who on those systems can access them. Each row specifies a rule that applies to some or all clients, and can either allow access, block it entirely or filter the a queried table. The fields and their meanings are:

    Hosts An IP address or partial IP address (like 192.168.1.) that this restriction applies to. Entering * will make the restriction apply to all clients.

    NIS tables Select the All option to have the restriction apply to all tables, or enter a single table name. Internally, the NIS server appends something like .byname or .byuid to table names to indicate what they are indexed by. The table name that you enter must use this internal name, such as passwd.byuid or hosts.byaddr.

    Restriction This field controls what the server does if a client request matches. Select None to allow the request, Deny access to block it altogether, or Trusted port to block if the client is using an untrusted port.

    Mangle field If using the Trusted port restriction, you can use this option to hide only a single field of the requested table from the client. Selecting None will block access to the table altogether, but entering a field number will cause its contents to be replaced with an x. The only practical use of this option is hiding passwords in the passwd.byname, passwd.byuid or shadow.byname tables, which are in field 2.

    New restrictions can be added using the empty row at the bottom of the table. To add more than one restriction, you will need to save and re-open the form multiple times.

    When a client requests a table, the NIS server will find the first row in the table that matches and use the restriction defined. For this reason, you must make sure that any new row you add is before the one that grants access to all clients and tables, which usually exists by default.

  3. When done, click the Save and Apply button. The browser will return to the module's main page, and any changes to restrictions will take effect immediately.

The most useful use of the Client map restrictions table is to add a row for all clients on the passwd.byname table, with the restriction set to Trusted port and the Mangle field option set to 2. Then add another row for the passwd.byuid table, with all other options the same. These will prevent non-root users from seeing encrypted passwords, while still allowing in programs running as root, such as the telnet or SSH server.

If you are using the separate shadow table to store passwords and expiry information, the restriction should be on the shadow.byname table instead. On many Linux distributions, a restriction like this exists by default.


17.6 Setting Up an NIS Slave Server

Slave NIS servers are used in a similar way to secondary DNS servers—they keep a copy of the tables held by the master server, and they can be used by clients if the master fails or is slow to respond. If you are using NIS on a very large network that has multiple LANs connected by slow links, it may also make sense to put a slave server on each LAN so that clients can use it instead of the master.

On OpenLinux, there is no way to setup a slave server using Webmin, due to the unique NIS configuration files used by the distribution. On all other versions of Linux, the steps to set up a system as a slave server are:

  1. On the module's main page, click on the NIS Server icon. This will take you to the server configuration form, shown in Figure 17.2.

  2. Set the Enable NIS server? field to Yes.

  3. Enter the master server's domain into the NIS domain field.

  4. Change the Server type to Slave of server, and enter the IP address of the master into the field next to it. None of the other fields need to be touched, because they all relate to running a master server.

  5. Click the Save and Apply button. The server should be started immediately, and configured to start at boot time.

Make sure that the master server has the address of this slave entered into the Slave servers field on the server configuration form. It should also have the Push updates to slave servers? option enabled, so that any changes to tables will be immediately sent to the slaves. If not, you can use the yppush command to send the contents of an NIS table to some or all slave servers.


17.7 Configuring the NIS Client and Server Module

The module has a few configurable options that can be changed by clicking on the Module Config link in the top left corner of the main page. The ones that you can safely change shown in Table 17.1.

The other options on the module configuration page are set automatically based on your operating system, and generally do not need to be changed.


17.8 NIS on Solaris

The only other operating system that Webmin allows you to configure NIS on is Sun's Solaris. On Solaris, the NIS Client and Client Services page are identical to those on Linux, and work in the same way. However, the NIS Server and Server Security forms are slightly different:

Table 17.1. Module Configuration Options

Maximum number of records to display

If the number of records in an NIS table exceeds this number, then the NIS Tables page will not display all of the records. Instead, it will show a search form for finding records based on a field and search term.

Automatically rebuild NIS maps?

Normally, any time you add, update, or delete a record in a table file, the NIS Makefile is run to rebuild all tables. Because this can be slow on systems with many records or slave servers, setting this option to No will turn off the automatic rebuild. Instead, you can force a build whenever you want by clicking the button labeled Rebuild NIS tables on the NIS Tables page.

  • On the NIS Server page, whatever domain you enter will also be used for the NIS client as well. This is a limitation of Solaris—unlike Linux, where a system can be a server for one domain and a client of another.

  • On the server page, you cannot specify the paths to individual table files directly. Instead, the NIS source files directory and NIS password source files directory fields control which directories they are stored in, usually /var/yp.

  • There is no Client map restrictions table on the Server Security page, and so no way to control which tables and fields clients can request. However, you can still allow or deny certain hosts and networks entirely using the Allow clients table.

Solaris systems include client and server support for NIS+ as standard. However, because that protocol is not supported by Webmin, attempting to use this module to reconfigure a system that is already running as an NIS+ client or server will not work, and may even cause problems with its configuration.


17.9 Summary

NIS is the standard way of sharing user, group, and other information between UNIX systems, and this chapter has explained how to set up and configure it using Webmin. After finishing it, you should know how to make your system a client of an existing NIS server on your network. You should also understand how to run a master NIS server of your own to serve other clients, and how to set up a slave to act as a backup for master.


Chapter 18. PPP Server Configuration

This chapter covers the process of setting up a Linux system with an attached modem as a dial-in server, so that other computers can dial up to it and access connected networks.


18.1 Introduction to PPP on Linux

Any Linux system with a modem attached can be configured so that other computers can dial up to it and start a PPP session, giving them TCP/IP access to the system and any networks that it is connected to. This allows it to act like a miniature ISP, and in fact some small ISPs have been run using Linux systems with multiple serial port cards as access servers.

Two separate programs are responsible for different parts of the dial-in service. The first is mgetty, which communicates on a serial port with an attached modem and instructs it to answer the phone. Once the server and client modems are connected, mgetty displays a text login prompt and waits for either a username or the start of a PPP session. A client can log in using text mode and get a UNIX shell prompt without needing to start a PPP session at all, but this is rarely done these days. Once the client disconnects or logs out, mgetty hangs up the modem and waits for a new connection.

Because most clients start a PPP session as soon as they connect, mgetty is usually configured to run the separate pppd program if it detects a PPP connection. This creates a ppp network interface on the server, authenticates the client, assigns an IP address, and starts sending and receiving data using the PPP protocol. The assigned IP address and other configuration options are usually set on a per-serial port basis, so that you can have multiple modems and support several simultaneous clients with different addresses.

The PPP Dialin Server module allows you to setup both mgetty and pppd so that clients can dial in and start PPP sessions. When you enter it from the Networking category, the main page simply shows four icons, under which are the actual configurable options.

Currently, the PPP Dialin Server module can be used only on Linux and Solaris systems, even though mgetty is available on some other versions of UNIX. If neither of the programs that it configures are installed, the main page will display an error message—however, all Linux distributions include packages for pppd and mgetty on their CDs or websites. If only mgetty is installed, you can use the Serial Port Configuration and Caller ID Access features. Conversely, if only pppd is installed, you can access only the PPP Options and PPP Accounts pages.

When you use the module to set up mgetty to answer calls on a serial port, an entry is added to the /etc/inittab file so that init will run the mgetty process at boot time, and re-run it as necessary. You will be able to see this entry in the SysV Init Configuration module (covered in Chapter 9), but you should not edit it there unless you know what you are doing.

Even though this chapter was written with Linux in mind, the module behaves almost identically on Solaris. The only difference is the names of the serial port device files—whereas /dev/ttyS0 is the first serial port on Linux, Solaris would use /dev/term/a instead.


18.2 Configuring a PPP Server

Before you can set a system up to allow clients to connect with PPP, it must either have a modem attached to a serial port, or be connected via a null-modem cable to another machine. Internal modems that emulate a serial port can be used as well, although they are not recommended as they do not have easily visible LEDs to indicate if the modem is connected, transmitting, and so on. USB modems should work, as long as they are recognized by the kernel—however, they will probably use a special device file. Modems that require special drivers to operate (commonly known as Winmodems) cannot be used at all, unless there is a driver for the modem available for Linux.

Naturally, any modem must be connected to a phone line. Because your system will be configured to answer the phone after a few rings, the phone line should not be used for anything else—otherwise, voice callers will have their calls answered by the modem, which is not very friendly.

Once all the hardware is ready, the steps to set up your system as a PPP server are:

  1. On the main page of the module, click on the Serial Port Configuration icon. This will take you to a page listing any existing ports that have been configured for PPP or voicemail.

  2. Click on the Add a new serial port link, which will bring up the port configuration form shown in Figure 18.1.

    Figure 18.1. The serial port configuration form.

  3. Set the Serial device to the port on which your modem or null-modem cable is connected. Serial port 1 corresponds to the device file /dev/ttyS0, and so on. For modems on serial devices not starting with /dev/ttyS (such as USB modems), select the Other device option and enter the full device file path into the text field next to the menu.

  4. Set the Type option to either Direct connection (for a system connected via null-modem cable), or Modem (for an actual dial-in modem).

  5. The Port speed field should be set to the baud rate that the modem or null-modem connection will use. This must be one of the standard speeds, such as 57600 or 33600.

  6. In the Answer after field, enter the number of rings that you want mgetty to wait for before answering the phone. If the phone line your modem is on will be also used for receiving voice calls, you could set this to something large like 20 to give yourself plenty of time to answer the phone before the modem does.

    Naturally, this option has no meaning for null-modem connections.

  7. Click the Create button. A new entry will be added to the /etc/inittab file, and you will be returned to the serial ports list.

  8. Click Apply Configuration to activate mgetty on the new port. Phone calls to the line your modem is on should now be answered after the configured number of rings.

    If you care only about text-only clients, then nothing more needs to be done—they will be able to dial up, authenticate at the login prompt and execute shell commands.

  9. To set up PPP, click on the PPP Options icon back on the main page. This will take you to the form shown in Figure 18.2, where you can set options that will apply to all PPP connections.

    Figure 18.2. The PPP configuration form.

  10. Unless you want clients to log in using text mode and start the pppd command manually, it is best to set the Automatically detect PPP connections on serial ports? option to Yes. With this enabled, mgetty will detect that the client wants to start a PPP session when the server is waiting for a log-in prompt, and run pppd automatically.

  11. In the PPP IP Address fields, enter the IP address that you want the server's end of the connection to use (the Local IP) and the address for the client's end of the connection (the Remote IP). Normally these addresses will not be on your local LAN, but on a different subnet. Other systems on the network should be configured to route traffic for the client's address to your system, so that they can communicate.

    If no addresses are specified, then the PPP server will use whatever addresses are supplied by the client. This might make sense when connecting two machines via null-modem, but will not work with most dial-up clients.

    It is possible to assign the client an IP address that is within the range of the local LAN, by turning on the Create proxy ARP entry? option. If this is enabled, enter an unused LAN IP address into the Remote IP field and your system's current Ethernet IP into the Local IP field.

  12. Set the Control lines mode field to Local for a null-modem connection, or Modem if there is a real modem connected to the serial port.

  13. Unless you are setting up a null-modem connection, clients should be forced to authenticate to prevent potential attackers from connecting. To turn on authentication, set the Require authentication? field to Yes. To turn it off totally for null-modem use, set the field to No.

    To set usernames and passwords for clients to authenticate against, see Section 18.3 "Managing PPP Accounts".

  14. To disconnect clients that have been idle for a long period, enter a number of seconds into the Idle time before disconnect field.

  15. Enter the IP addresses of any DNS servers on your network into the DNS servers for clients field. Client operating systems like Windows will use them automatically, which simplifies their configuration.

  16. Finally, click the Save button. Clients should now be able to dial in, establish a PPP session and access your system and network.

If your system is going to have multiple simultaneous PPP clients connected, then you will need to set different options for each serial port. In particular, each client must have a different remote IP address, although the local address can be re-used.

To set up different PPP options for each serial port, the steps to follow are:

  1. On the module's main page, click on the PPP Options icon. Change the PPP IP Addresses field back to From client, and change any other options that you want set on a per-port basis back to their defaults as well.

  2. Go back to the main page, click on Serial Port Configuration and then on the Edit link under Port PPP Config for the serial port that you want to set options for. This will take you to the per-port options page, which is very similar to the global PPP options form shown in Figure 18.2.

  3. Enter remote and local IP addresses to which you want PPP clients connecting on this port to be assigned, and change any other options that have not been set on the global PPP options page.

  4. When done, click the Save button. Clients connecting on the configured port will use the new options from now on.

The easiest way to stop your system from acting as a PPP server is simply to remove the serial port configuration entry for your modem. If you have multiple modems attached, the steps below can be used to disable one without any effect on the others:

  1. On the main page, click on Serial Port Configuration and then on the device name of the port with the attached modem.

  2. On the port options page, click the Delete button in the lower-right corner. The appropriate entry will be removed from the /etc/inittab file, and you will be returned to the list of enabled ports.

  3. Click the Apply Configuration button to make the change active. From now on, your system will no longer answer incoming phone calls or communicate with another computer attached by a null-modem cable.


18.3 Managing PPP Accounts

If you enable dialin access to your system, you should force all clients to authenticate themselves by turning on the Require authentication? option on the PPP Options page. Even if you think that your sever doesn't need to authenticate clients because only you know the phone number of the line your modem is on, it is still a good idea to enable it in case someone stumbles across the number by accident—or in case a "war dialer" trying out hundreds of phone numbers in search of insecure servers finds it.

Once authentication is enabled, you can add a new account that is allowed to log in by following these steps:

  1. On the main page of the module, click on the PPP Accounts icon. This will take you to a page listing all existing accounts, including those that have been created for dialing out to other servers.

  2. Follow the Create a new PPP account link, which will bring you to the account creation form shown in Figure 18.3.

    Figure 18.3. Creating a new PPP account.

  3. Enter a login name into the Username field, and make sure its Any option is not selected.

  4. Make sure the Server field is set to Any. If you set it to something else, then the username will be accepted only when the client's hostname matches whatever you enter.

  5. Select the Set to option in the Password field, and enter a password for the account into the text field next to it. It is also possible to have the PPP server read the password from a separate file, by selecting the From file option and entering a file name into its text field. Or you can remove the need for a password to be supplied at all, by selecting None—however, this isn't a very good idea from a security point of view.

  6. Assuming that all clients are being assigned IP addresses, set the Valid Addresses field to Allow any. However, if no addresses are specified in the PPP Options page, you may want to select Allow listed and enter acceptable addresses into the text box below it.

  7. Finally, click the Save button and the new PPP account will be created. It can be used immediately by connecting clients.

To edit an existing PPP account, just click on its username from the accounts list. This will being you to the account editing form, which is almost identical to the creation form shown in Figure 18.3. Change the username, password, or any other options, and click the Save button to save your changes and make them immediately active. Or click the Delete button on the editing form to remove the account instead.

By default, Webmin will add new users to the /etc/ppp/pap-secrets file. This is only read by the PPP server when doing PAP authentication, which is used by default. If you have manually configured your system to authenticate clients using the more secure CHAP protocol instead, you will need to configure Webmin to edit the chap-secrets file instead. This can be done by clicking on the Module Config link in the top left corner of the main page, and changing the PAP secrets file field to /etc/ppp/chap-secrets.


18.4 Restricting Access by Caller ID

If your phone line has caller ID enabled and your modem supports it, mgetty can be configured to block certain callers based on their phone numbers. By default, any caller will be allowed to connect—but you can change this so that only a few numbers are allowed by following these steps:

  1. On the main page of the module, click on the Caller ID Access icon. This will take you to a form listing restricted numbers, which will probably be empty if you have not added any yet.

  2. Click on the Add a new caller ID number link, which will take you to a form for entering the new number.

  3. Set the Phone number option to Numbers starting with, and in the field next to it enter a partial or complete phone number that you want to allow. If you enter something like just 555, any caller whose phone number starts with 555 (such as 555-1234) will be allowed.

  4. Set the Action field to Allow.

  5. Click the Create button, which will save the number and return you to the list of those that are allowed and denied.

  6. To add another allowed number, repeat Steps 2 through 5.

  7. Finally, click on Add a new caller ID number again and on the creation form set Phone number to All numbers and the Action to Deny.

  8. Click the Create button to have this final deny entry added to the list. From now on, only the phone numbers that you explicitly allowed will be able to connect.

Because the system checks each entry in the list in order and stops when it finds one that matches, any entry that denies (or allows) all callers must appear at the bottom of the list—otherwise, those after it will never be processed. If you want to allow a new phone number in the future, you must add it, then use the arrows in the Move column to move it above the final entry that denies everyone.

Because some clients may not provide caller ID information, the Unknown numbers option for the Phone number field can be used to match their calls. Allowing all unknown callers is not a good way to block known attackers though, as they may just disable the sending of caller ID information on their phone line.

Caller ID restrictions should never be the only form of security on your dial-in server, as caller numbers are supplied by the phone company and thus not totally under your control. PPP authentication should be enabled as well, so that all clients are forced to log in.


18.5 Module Access Control

Like others, this module has several options that you can set in the Webmin Users module to control which of its features are available. They are most useful for disabling parts of the module that are no use on a particular system—for example, you may want only the PPP Accounts page to be visible for a certain user.

To edit access control options in this module for a user or group, the steps to follow are:

  1. In the Webmin Users module, click on PPP Dialin Server next to the name of a user who has been granted access to the module.

  2. For the Available pages field, de-select those icons on the module's main page that you don't want the user to be able to access. If PPP Options is de-selected, the user will not be able to edit the options that apply to a single serial port either.

  3. If the user is granted access to only a single page, setting the Go direct to one page? field to Yes will cause the browser to jump directly to that page when the module is entered.

  4. Click the Save button to make the access control settings active.


18.6 Summary

After reading this chapter, you will be able to set up any Linux system with an attached modem as a dial-in server to which PPP clients can connect. You should understand the security implications of doing this, and how access can be restricted to only trusted systems. You should also know how a dial-up connection like this fits in with, and is accessible from, the rest of your network.


Chapter 19. Firewall Configuration

I If your system is connected to the Internet, it should be protected with a firewall to prevent unauthorized access. This chapter covers the process of setting up and configuring a firewall with Webmin and IPtables.


19.1 Introduction to Firewalling with IPtables

A firewall is a system that protects itself and other hosts on a network from attackers on untrusted networks, such as the Internet. It can block packets and connections based on a variety of criteria, such as the source address, destination address, port, and protocol. Typically a firewall is also a router, forwarding packets between a secure local network and the untrusted Internet—however, it is also possible for a system to protect just itself.

A firewall system can also be configured to hide multiple hosts behind a single IP address, using a process known as NAT (Network Address Translation). Typically, the hidden hosts are on an internal LAN using a private IP network (such as 192.168.0.0) and the firewall has a single Internet IP address. NAT allows these internal hosts to communicate with others on the Internet, even though they do not have real public IP addresses.

The Linux kernel has included several different firewall implementations over the years, such as IPfwadm and IPchains. The 2.4 series of kernels include the IPtables firewall, which is more powerful and flexible than its predecessors. All Linux distributions that use the 2.4 kernel have IPtables support enabled, and include the commands needed to configure it. This chapter and the Linux Firewall module cover only the setting up of a firewall using IPtables, not any of the older implementations like IPchains or IPfwadm.

All IP network traffic is broken up into packets, which are chunks of data with a source, destination, and protocol information. Even a continuous flow of data such as the download of a large file is broken into packets when sent, and re-assembled at its destination. Because the IPtables firewall operates at the IP level, all of its rules and chains evaluate and operate on individual packets, not TCP connections or HTTP requests.

An IPtables firewall is made up of three different kinds of objects—tables, chains, and rules. Each of the three tables contains two or three standard chains, and possibly many user-defined custom chains. Each chain contains zero or more rules, which are applied to packets received by or sent out from the firewall to determine their fate. The three tables and their standard chains are:

Packet filtering (filter) The INPUT, OUTPUT, and FORWARD packets chains in this table apply to packets received by, sent out from, or forwarded by the firewall, respectively. If the firewall system is acting as a router, only the FORWARD chain applies to routed packets. Network traffic destined for the system itself is processed by the INPUT chain, and traffic sent out by local process by the OUTPUT chain.

For a system that is an ordinary router and not doing any masquerading, or a system that needs a firewall only to protect itself, this is the only table that rules need to be added to.

Network address translation (nat) This table is used only for packets that start a new connection. The rules in its PREROUTING chain are applied to packets as soon as they are received by the system for routing, and the POSTROUTING for packets about to leave after routing. The OUTPUT chain rules are applied to locally generated packets for modification before routing.

Rules are typically added to this table to set up masquerading, transparent proxying, or some other kind of address translation.

Packet alteration (mangle) This table is used only for specialized packet alteration. It contains two chains—PREROUTING for modifying packets before routing, and OUTPUT for modifying locally generated packets.

This table is rarely used in a typical firewall configuration.

When a network packet is processed by a chain, each rule in the chain is executed in order. Every rule has a set of conditions that determine whether the rule matches or not, and an action that is taken in the case of a match. This action may be to immediately accept the packet, immediately drop it, perform some modification, or continue execution. If the end of a chain is reached, its default action will be taken instead, which is usually to allow the packet through.

Figure 19.1 shows the tables and chains that a packet passes through, and the order in which they are checked. Packets coming in from the network enter the diagram at the top, and are processed by both the PREROUTING chains. At this point, a decision is made—packets destined for the local system go to the left, while those being forwarded to some other destination take the right hand branch. Those that go left are processed by the incoming packets chain before being delivered to local processes, such as servers. Forwarded data is processed by the Forwarded packets and After routing chains before being sent on to its destination.

Figure 19.1. An overview of IPtables.

The firewall can also affect packets sent out by processes on the local system. These are checked against the three Output chains and the After routing chain before being transmitted via the appropriate network interface to their destinations. This means that an IPtables firewall can be used to limit the addresses that local processes can connect to, and the protocols that they can use.


19.2 The Linux Firewall Module

This module can be used to set up a firewall on a Linux system with IPtables enabled, or to edit any part of an existing firewall. It stores the firewall configuration in a save file created and read by the iptables-save and iptables-restore commands, not in a shell script containing calls to the iptables command. Red Hat, Debian, and Gentoo Linux all use a save file like this as standard, which Webmin knows about and will work with.

If you have manually created a firewall using a shell script and want to use this module to edit it from now on, it will have to be converted to an IPtables save file so that Webmin can edit it. Fortunately, the module can do this for you automatically—all you have to do is stop your custom script from being run at boot time, and tell the module to create its own firewall setup script instead.

This also applies to firewalls created by tools such as YaST or fBuilder, which write out shell scripts of iptables commands. Unless the tool can also edit an IPtables save file (such as knetfilter), it should not be used alongside Webmin's Linux Firewall module, or they will probably overwrite each other's settings.

When you enter the module from the Networking category, the main page will usually display a list of all chains and rules in the first table that contains any (usually Packet filtering), as shown in Figure 19.2. However, if Webmin detects that the iptables or iptables-save commands are not installed, an error message will be displayed instead—check your distribution CD or website for a package containing them.

Figure 19.2. The Linux Firewall module.

If this is the first time you have used the module and no firewall has been set up on your system yet, the main page will instead display a form to simplify the initial firewall creation. Three options will be displayed—select one and click the Setup Firewall button to set it up. If necessary, Webmin will also display an Enable firewall at boot time? Checkbox, which if selected will cause a boot-up script to be created so that the firewall is enabled at boot time as well.

The firewall setup options are:

Allow all traffic If this is selected, the firewall will be created "empty" and all traffic allowed through.

Do network address translation on external interface The firewall will be set up for NAT, so that hosts on an internal LAN can access the Internet via a host with a single public IP address. You must select the network interface that is connected to the Internet from the list next to this option, such as ppp0.

Block all incoming connections on external interface If this is chosen, the firewall will be set up to block all traffic coming into your system on the selected network interface, except for established connections, DNS replies, and harmless ICMP packets. The interface you select should be the one connected to the Internet, such as ppp0.

Block all except SSH and IDENT on external interface Similar to the previous option, but SSH and IDENT protocol traffic will be allowed as well.

Block all except SSH, IDENT, ping, and high ports on interface Similar to the previous option, but ICMP pings and connections to ports above 1024 will be allowed as well.

If this is the first time the module has been used and Webmin detects that a firewall already exists on your system, its rules will be displayed and you will be prompted to convert it to a save file so that the module can be used to edit it. If you choose to do this by clicking the Save Firewall Rules button, all existing tables, chains, and rules will be safely recorded. An Enable firewall at boot time? checkbox will also be displayed if necessary, which if selected will cause Webmin to create a boot script to activate the saved firewall rules at boot time.

If you choose to convert an existing manually created firewall configuration, be sure to disable any existing script that sets it up at boot time. Otherwise both the old script and the one created by Webmin will be run, possibly causing the rules set up in this module to be cancelled out by the older manual configuration.


19.3 Allowing and Denying Network Traffic

To restrict the types of connections and packets that your firewall will accept or forward, you need to create additional firewall rules. The best place for these rules is the Packet filtering table, in either the Incoming packets or Forwarded packets chain. If your firewall is acting as a router and you want to protect systems on the secure network that it is attached to but not the firewall itself, the Forwarded packets chain should be used. However, if you want to protect both the firewall and other systems that it routes to, rules should be added to the Incoming packets chain.

It is also possible to restrict data being sent out by your system, which may come from local processes or be forwarded from other hosts. To do this, you can add rules to the Outgoing packets chain. This can be useful for limiting what addresses and ports local users can connect to, if you desire.

To create a new rule to block traffic, the steps to follow are:

  1. On the main page of the module, select Packet filtering from the list next to the Show IPtable button, and then click it to switch to the filtering table.

  2. To add a rule that applies to all incoming traffic, click the Add Rule button in the Incoming packets section. If you want to restrict only forwarded traffic, click the button under Forwarded packets instead.

    Either way, you will be taken to the rule creation form, shown in Figure 19.3.

    Figure 19.3. The rule creation form.

  3. Change the Action to take to Drop, so that packets matching this rule are silently discarded by the firewall.

  4. In the Rule comment field enter a short explanation for this rule if you wish.

  5. In the Condition details section, select the conditions that determine which packets will be matched and thus dropped. Only packets matching all conditions that are not set to <Ignore> will be dropped.

    Some examples of the conditions to select to block certain kinds of traffic are:

    Blocking all connections to a certain TCP port Set the Network protocol field to Equals and select TCP. To block a port, a protocol must always be selected.

    Set the Destination TCP or UDP port to Equals and enter a port number into the Port(s) field next to it. You can block several ports by entering a list of numbers separated by commas into the Port(s) field, or block an entire range by selecting Port range and entering the start and end ports into the fields next to it.

    Blocking all traffic from a particular address Set the Source address or network to Equals and enter the IP address to block into the field next to it. You can also block an entire network by entering a network/prefix pair like 130.194.164.0/24 into the field.

    Set the Connection state to Does not equal and select Existing connection from the menu next to it. This step will allow your system to connect to the blocked addresses, but not vice-versa.

    Blocking traffic to a particular address Set the Destination address or network to Equals and enter the IP address or network to block into the field next to it. Because this will effectively stop the blocked system from connecting to yours as well, it may be a good idea to set the Connection state to Does not equal and select Existing connection from the menu next to it.

    In all cases, it is usually a good idea to set the Incoming interface to the network interface that is connected to the Internet (such as ppp0), so that the restriction does not apply to connections from your local LAN.

  6. When you are done selecting conditions, click the Create button. As long as there are no errors in your input, you will be returned to the module's main page on which the new rule will be listed.

  7. To make the new rule active, click the Apply Configuration button at the bottom of the page.

The rules in each chain are evaluated in order from top to bottom, and the action taken is determined by whichever one matches first. If none match, then the chain's default action is taken, which is usually to accept the packet. You can make use of this evaluation order to create a rule that allows a single IP address, followed by a rule to deny an entire network. The final effect will be that every host within the network is denied except one.

Because the ordering of rules is important, you may sometimes want to add a rule in the middle of an existing chain. To do this, use one of the arrow buttons under a chain's Add column on the module's main page to create a new rule either before or after an existing one.

The most common actions and their meanings are listed below. Not all are available in all chains and tables.

Do nothing If a rule with this action is matched, nothing will be done and processing will continue to the next rule.

Accept Matching packets will be immediately accepted, and no further processing will be done in the chain. However, rules in other tables may still affect the packet.

Drop Matching packets will be silently discarded, as though they were never received at all. No further processing will take place in this chain or any other.

Userspace Packets will be passed to a normal userspace process. This action is rarely used.

Exit chain Jump immediately to the end of the chain, and execute its default action instead. If this is used in a user-defined chain, processing will return to the rule that called it.

Masquerade Matching packets will have their source address changed to appear to come from the firewall system, and no further rules in the chain will be processed. When this action is selected, you can use the Source ports for masquerading field to control which ports the firewall will use for masqueraded connections. See Section 19.7 "Setting Up Network Address Translation" for more details.

The Masquerade option is available only in the Network address translation table, in the Packets after routing chain.

Source NAT Similar to the Masquerade option, but better suited to systems that have a fixed Internet IP address. If selected, you can use the IPs and ports for SNAT field to control which addresses and ports are used for NAT, as explained in Section 19.7 "Setting Up Network Address Translation".

This option is only available in the Network address translation table, in the Packets after routing chain.

Destination NAT Matching packets will have their destination address and port modified based on the IPs and ports for DNAT field. This is the basis for transparent proxying, so to learn more, see Section 19.8 "Setting Up a Transparent Proxy".

This action is available only in the Network address translation table, in the Packets before routing and Output chains.

Redirect This action redirects all matching packets to a port or ports on the firewall box, specified by the Target ports for redirect field. It can also be used for transparent proxying, although Destination NAT is more flexible.

The redirect action is available only in the Network address translation table, in the Packets before routing and Output chains.

You can also choose the Run chain option for the Action to take, which will pass the packet on to the user-defined chain or custom target entered into the field next to it. See Section 19.6 "Creating Your Own Chain" for more information on user-defined chains. Some of the targets available are LOG (for logging packets to syslog), MIRROR (for reflecting packets back to their sender), and MARK (for marking a packet for later conditions).

For each condition, the options <Ignored>, Equals, and Does not equal can be selected. The first means that the condition is not used at all when checking if a packet matches the rule. The second means that a packet must match the condition for it to match the entire rule, and the third means that the packet must NOT match the condition for the rule to be executed. If for example the Incoming interface condition was set to Does not equal and eth0 selected, the rule would match only packets coming in on any interface except the primary Ethernet card.

Because almost all network protocols involve traffic flowing in two directions, attempting to block just incoming traffic from some address using the Source address or network condition will also block connections to the address as well, because reply packets that are part of the connection will be dropped. The same goes for blocking incoming data on a particular port using the Destination TCP or UDP port condition—if in the unlikely case that the randomly chosen source port of a connection from your system matches the blocked port, any replies to it will be dropped. For these reasons, it is usually a good idea when creating deny rules to set the Connection state condition to Does not equal and select Existing connection from the menu next to it. This will cause IPtables to keep track of outgoing connections made by your server, and not block them.

As you can see, there are many different conditions available which can be combined to create quite complex rules. To learn more about what each of the available conditions do, see Section 19.10 "Firewall Rule Conditions". Because there are so many conditions, Webmin allows you to create new rules that are almost identical to existing ones. To do this, click on an existing rule to edit it and use the Clone rule button at the bottom of the page to go to the rule creation form, with all conditions and actions set based on the original rule.


19.4 Changing a Chain's Default Action

Packets that do not match any rule in a chain will be processed using the default action, which is usually to accept the packet. On the module's main page, the default action for each chain is shown next to the Set default action to button. To change it, the steps to follow are:

  1. Select the new action from the menu next to the Set default action to button. Only the Accept, Drop, Userspace, and Exit chain actions are available—see Section 19.3 "Allowing and Denying Network Traffic" for their meanings. Typically, only Allow and Drop make sense as default actions.

  2. Click the Set default action to button to save the new default.

  3. If changing to Drop, add any additional firewall rules needed so that your system can still access other servers and supply important services.

  4. When done, click the Apply Configuration button to make the new default active.

Just changing the default action to Drop for incoming packets is an easy way to totally cut your system off from the network, and possibly make it unusable. Before you do so, make sure you allow at least the following kinds of traffic:

  • All established connections Create an Allow rule with the Connection state set to Equals and Existing connection chosen.

  • Connections related to those that are established, such as FTP data connections Create an Allow rule with the Connection state set to Equals and Related connection chosen.

  • All traffic on the loopback interface Create an Allow rule with Incoming interface set to Equals and lo chosen.

  • Traffic from your system to itself on its primary network interfaces For each interface create an Allow rule with both the Source address or network and Destination address or network set to the interface IP address.

  • Safe ICMP types Create four Allow rules with the ICMP packet type set to Equals and echo-reply, destination-unreachable, source-quench, and time-exceeded chosen.

Changing the default action for forwarded packets to Drop will not cause as many problems—it will just be the equivalent of turning off forwarding altogether. Changing the default action for outgoing packets to Drop is a bad idea as it will cut off all network access, and probably makes very little sense in most cases.


19.5 Editing Firewall Rules

Webmin can be used to edit any of the existing firewall rules that have been created manually, in another program or using this module. Even though the module does not support all of the available IPtables condition and action options, you can still use it to safely edit rules containing unknown options. Only those known to Webmin can be changed, and others will be left untouched.

To edit a rule, the steps to follow are:

  1. On the main page of the module, select the table the rule is in from the list next to be Showing IPtable button before clicking it.

  2. Click on the action of the rule you wish to change in the table for its chain. This will take you to an editing form, which is identical to the creation form shown in Figure 19.3.

  3. Change the action or any of the conditions, and click the Save button to return to the list of chains and rules. Or to delete the rule altogether, click the Delete button.

  4. To make the changes active, click on Apply Configuration.

Rules can be moved up and down within their chain using the arrows under the Moveolumn on the module's mSave buiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii


19.10 Firewall Rule Conditions

When creating a firewall rule, you can select many different conditions to control which packets the rule matches. A rule's action will only be executed if all the conditions are matched. Each condition can be in one of three states, chosen by the menu next to it on the rule creation form:

<Ignore> The condition will be totally ignored when deciding whether the rule matches or not.

Equals The rule will only match if the packet matches the address, port, interface, or whatever was selected for this condition.

Does not equal The rule will only match if the packet does NOT match whatever was selected for this condition.

The available conditions and what each one matches are listed in Table 19.1. Note that some are not available in all tables and chains.

Remember that each condition is applied on a per-packet basis, and that a single TCP connection may involve multiple packets flowing in both directions.

Table 19.1. Firewall Conditions

Condition

Matches

Source address or network

The IP address, host, or network that the packet was sent from. When entering a network, you can use the network/prefix notation (like 192.168.0.0/16) or the network/netmask notation (like 192.168.0.0/255.255.0.0).

Destination address or network

The IP address, host, or network that the packet is going to. As with the source address, you can use both the network/prefix and network/netmask notations.

Incoming interface

The network interface on which the packet entered the firewall server. See the discussion of interface types and names in Chapter 16 for more details.

Outgoing interface

The network interface on which the packet is being sent out by the firewall server.

Fragmentation

When an IP packet is too large for the physical network it is being sent over, it will be broken into multiple fragments. If Is fragmented is chosen, the rule will apply only to fragments after the first one. If Is not fragmented is chosen, the rule applies only to the first fragment, or packets that were not fragmented at all.

Because fragments after the first do not contain any protocol or port information, rules that have protocol, port, TCP, state, or type of service conditions will never match a fragment.

Network protocol

The network protocol of the data carried by the packet. TCP is used by HTTP, FTP, telnet, SSH, SMTP, POP3, and many other higher level protocols. UDP is used by the DNS, NFS, and NIS protocols. ICMP is used by commands like ping and traceroute.

Source TCP or UDP port

The port that a TCP connection or UDP packet came from. For packets sent by a client to a server, the source port is usually randomly assigned and thus useless for firewalling. But for packets sent back from the server to the client, the source port is the same as the port that the client connected to.

If the Port(s) option is selected, you can enter one or more ports into the field next to it, separated by commas. If Port range is selected, you must enter a starting and ending number to cover all ports between them.

This condition can be used only if your Network protocol is set to TCP or UDP.

Destination TCP or UDP port

The port that a TCP connection or UDP packet is going to. Instead of entering a port number, you can enter a name from the /etc/services file that is associated with a port, such as telnet or http.

As with the Source TCP or UDP port condition, a list or range of ports can be entered, and the Network protocol must be set to either TCP or UDP.

Source and destination port(s)

For a condition of this type to match, both the source and destination ports must be in the comma-separated list of port names or numbers entered into the field next to it. This condition has never seemed particularly useful to me.

TCP option number is set

Matches if the entered TCP option number is set.

TCP flags set

The flags set on a TCP packet. The selections in the second row determine which flags the firewall will look at, while those in the first row indicate whether a particular flag must be set or not.

This condition can be used to detect TCP packets that are part of an existing connection. However, the Connection state condition is a far superior and simpler way of doing the same thing.

For this condition to be used, the Network protocol must be set to TCP.

ICMP packet type

For ICMP packets, this condition matches if the packet type matches whatever is chosen from the menu next to it. Some types such as echo-request and echo-reply are sent by the ping command, while others are used for low-level network flow control. Because ICMP packets are usually harmless and sometimes important, it is not necessary to block them.

As would be expected, the Network protocol must be set to ICMP for this condition to be used.

Ethernet address

The MAC address (usually Ethernet) of the packet sender. If the packet was forwarded by another router after being sent by the original host, its MAC address will be that of the router.

Ethernet addresses must be formatted like 00:D0:B7:1D:FB:AA, as displayed by the ifconfig command.

Packet flow rate

Matches packets up to the rate entered (if Below is chosen), or above the rate entered (if Above is chosen). This condition cannot be used for limiting the amount of traffic a host can send—rather, it is useful for logging with the LOG target only a fraction of the packets that match some rule.

Packet burst rate

The maximum initial number of packets to match. This number gets recharged by one every time the Packet flow rate is not reached, up to the number entered.

Connection state

Matches packets depending on their connection status and the options chosen from the menu. You can select more than one to match packets with any of the chosen statuses. The available options and the packets they match are:

New connection Matches packets that are part of a new TCP connection.

Existing connection Packets that are part of a connection that has already been established.

Related connection Packets in a connection that is related to one already established, such as an FTP data connection.

Not part of any connection Packets that do not fit in with any new or existing connection at all.

Type of service

Matches packets whose IP type-of-service field is the same as the type selected from the menu next to this condition.

Sending unix user

Packets sent by a local process owned by the chosen UNIX user. This condition (and the three below) make sense only in the Outgoing packets chain.

Sending unix group

Packets sent by a local process owned by the chosen UNIX group.

Sending process ID

Packets sent by a local process with the specified PID.

Sending process group

Packets sent by a local process with the specified process group ID.

Additional parameters

This field can be used to enter additional parameters to a rule that cannot be set through the module's user interface, such as—log-level warn. It should only be used if you are familiar with the iptables command.


19.11 Configuring the Linux Firewall Module

This module has several configurable settings, reachable by clicking on the Module Config link on the main page. It is shown in Table 19.2.


19.12 Summary

Any system that is directly connected to the Internet is potentially vulnerable to attacks by hackers and other malicious people. After reading this chapter, you should know how to limit the kinds of traffic that your system will accept, making it much harder for attackers to break in. You should also know how to set it up as a masquerading gateway that protects hosts on an internal LAN which still allows them access to the Internet. Finally, you should know how to set up a transparent proxy and configure port forwarding, if required, on your network.

Table 19.2. Module Configuration Options

Directly edit firewall rules instead of save file?

Normally, this field is set to No, which tells the module to edit firewall rules in a save file that can be applied by hitting the Apply Configuration button. Selecting Yes switches the module to a different mode, in which all changes are made directly to the active firewall rules. The user interface in this mode is similar, but the apply, revert, and boot-time buttons on the main page are no longer displayed, as they do not make any sense.

Directly updating the firewall rules makes sense if some other program on your system is editing them as well, such as PortSentry. However, all rules will be lost when your system is re-booted, unless you have manually created a script to save them at shutdown time with the iptables-save command, and restore them at boot time with iptables-restore.

IPtables save file to edit

This field can be used to specify an alternate file for the module to read and update IPtables rules in. You should only change it if your system is using some custom save file, perhaps created by another firewall tool.

Display comment?

This field determines if the comment for each rule is shown on the module's main page along with the condition and action.

Display condition?

This field determines if each rule's condition is shown on the module's main page.