ServerBuddies Support Blog

Configuration Files in Webmin

Most Webmin modules work by editing configuration files on your system, like

Each module knows which configuration files it manages, and what commands need to be run to activate them. Not all modules actually deal with config files though - for example, the MySQL module works by executing SQL commands.

As such, it cannot participate in the configuration backup process.

More in details at http://doxfer.com/Webmin/

The iostat command

The iostat command at its most basic provides an overview of CPU and disk I/O statistics:

Below the first line (which contains the system’s kernel version and hostname, along with the current date), iostat displays an overview of the system’s average CPU utilization since the last reboot.

The CPU utilization report includes the following percentages:

Percentage of time spent in user mode (running applications, etc.)

Percentage of time spent in user mode (for processes that have altered their scheduling priority using nice(2))

Percentage of time spent in kernel mode.

Percentage of time spent idle.

Below the CPU utilization report is the device utilization report. This report contains one line for each active disk device on the system.

dig, or domain information groper, provides the ability to query any domain server for information about the domains it serves. It operates in both an interactive mode and a batch query mode.

Using dig is much like using host, in that in its simplest mode you enter just the command and the name to lookup.

However, dig is more verbose by default and presents a much wider array or information, though in a somewhat less readable form.

Just like host, it is possible to query your default system resolver, or you can query a name server specified on the command line. For example, I could query name server about the google.com domain.

Above, we have a large amount of information, though not all of it is generally useful to us. First is the version of dig, and the command line options we specified.

The comes some status information, including the NOERROR designator that indicates the name was retrieve without error. If the domain did not exist, or could not be queried, there would be an NXDOMAIN error or some other error. Next are the flags of the query.

In this case, we have one query and one answer which are contained in the QUESTION and ANSWER sections below it. The next two items inform us of the number of AUTHORITY and ADDITIONAL sections that follow. In this case, the authority section gives us the primary and secondary name servers for this domain, ns1.serverbuddies.com and ns2.serverbuddies.com, and the additional section provides the IP addresses of those name servers.

The last few lines give the time the query required, the server that was queried and the port on which it was queried, the time and date on which the query was made, and the size of the message received from the name server.

Like host, dig has a mode in which you can query all of the information available about the domain. This can be done by appending the ANY argument to the end of the command line. Furthermore, the options NS, MX, CNAME, etc. are also available and do just what you would expect.

Reference - for more please check - http://doxfer.com/Webmin/

Using whois to confirm glue records

Name service cannot possibly work without accurate glue records at your registrar.

These records provide the top-level domain name servers with the information they need to point clients to the right name server for any given second-level domain.

If these records are incorrect, nothing that requires a name lookup will work for your domain.

To check the glue records, use the whois command:

This will produce a bunch of information about your zone, but the important part is the name servers section, which will include two records of the form:

Domain servers in listed order:

Other top-level domains, like .net and .org, or other country domains, may have slightly different wording or conventions for what information is provided, but there will always be a section for name servers.

If these are incorrect, you’ll need to update the information with your registrar.

Reference : http://doxfer.com/Webmin/

Module access control for users in Webmin

Once a user has been given access to the module, you can limit him to just mounting or un-mounted selected filesystems by following these steps :

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

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.

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.

Change the Can add new filesystems? field to No.

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

Hit the Save button to activate the new restrictions.

For more please visit - http://doxfer.com/Webmin/DiskAndNetworkFilesystems