ServerBuddies Support Blog

Using rndc

BIND includes a utility called rndc that allows you to administer the named daemon, locally or remotely, with command line statements. The rndc program uses the /etc/rndc.conf file for its configuration options, which can be overridden with command line options.

In order to prevent unauthorized users on other systems from controlling BIND on your server, a shared secret key method is used to explicitly grant privileges to particular hosts. In order for rndc to issue commands to any named, even on a local machine, the keys used in /etc/named.conf and /etc/rndc.conf must match.

When executing rndc on a properly configured localhost, the following commands are available:

halt — Stops the named service immediately.

querylog — Turns on logging of all queries made by clients to this nameserver.

refresh — Refreshes the nameserver’s database.

reload — Tells the nameserver to reload the zone files but keep all other previously cached responses. This allows you to make changes to zone files and have them take effect on your master and slave servers without losing all stored name resolutions.
If your changes only affected a particular zone, you can tell named to only reload that one zone. Type the name of the zone after the reload command.

stats — Dumps the current named stats to the /var/named/named.stats file.

stop — Stops the server gracefully, saving any dynamic update and IXFR data before exiting.

Tags: rndc

Domain zone files

Here is an example for a domain file for yourdomain.com. Please note this is a very generic example and there are more features to it. Please refer to the BIND documentation for help with these features.

Any line starting with a ; is a comment line and is ignored by BIND. The first 6 lines are configuration lines for the zone. These lines tell it what the zone is (yourdomain.com) who is responsible for it (root.yourdomain.com which is equivalent to root@yourdomain.com) and a few other things. These other things include a serial number used for keeping track of when it’s updated, how often to refresh the database, how often to retry a zone transfer, when the zone information will expire and a default time to live. *IMPORTANT* Whenever you make changes to the zone file, you MUST increment the serial number. If you do not do this, prolems can occur, especially if you are a primary server supplying information to secondary sites. Most of this information is only used if you have both master and slave systems

The next two lines tell it who the primary DNS server is and who should get the mail for this domain. You can have multiple listings of each of these. To add more dns servers just repeat exactly what is listed changing the dns.yourdomain.com with another dns server. To add another mail server you do the same thing except you have an extra field. The “10″ in the MX line states a priority, lower number being first. What this means is if you have 2 MX listings, one is 10 and one is 20, it will try to deliver the mail to the MX listing with the 10 priority and if it fails it will then go to the MX listing with the 20 priority.

The rest of the zone file lists all your hosts and ips.

Tags: Domain, Files, zone

Mounting confusion /proc comes to the rescue

If you are losing track of what’s mounted, and in what state? No problem, here comes /proc to the rescue:

This displays all mounted filesystems, the filesystem types, read/write status, and other attributes. How many hard drives are on the system? One of these will tell you and also, SCSI drives are sd, IDE are hd.

or

or

Tags: confusion, mounting, proc, Rescue

Cloning an entire drive

You’ll need two hard drives the same size, or a destination drive larger than the source drive.

Make sure no partitions are mounted on either drive. In this example /dev/hda is the source drive, /dev/hdb is the destination drive. The dd command makes an exact, byte-for-byte copy, including the MBR (master boot record):

Tags: Cloning, drive, entire

Apache Graceful Restart Process

Signal: USR1

The USR1 or graceful signal causes the parent process to advise the children to exit after their current request (or to exit immediately if they’re not serving anything). The parent re-reads its configuration files and re-opens its log files. As each child dies off the parent replaces it with a child from the new generation of the configuration, which begins serving new requests immediately.

This code is designed to always respect the process control directive of the MPMs, so the number of processes and threads available to serve clients will be maintained at the appropriate values throughout the restart process.

Tags: Apache, graceful, process, Restart