ServerBuddies Support Blog

fsck - check and repair a Linux file system

fsck - check and repair a Linux file system

fsck is used to check and optionally repair one or more Linux file systems. filesys can be a device name (e.g. /dev/hdc1, /dev/sdb2), a mount point (e.g. /, /usr, /home), or an ext2 label or UUID specifier (e.g. UUID=8868abf6-88c5-4a83-98b8-bfc24057f7bd or LABEL=root). Normally, the fsck program will try to handle filesystems on different physical disk drives in parallel to reduce the total amount of time needed to check all of the filesystems.

If no filesystems are specified on the command line, and the -A option is not specified, fsck will default to checking filesystems in /etc/fstab serially.

This is equivalent to the -As options.

The exit code returned by fsck is the sum of the following conditions:

0 - No errors
1 - File system errors corrected
2 - System should be rebooted
4 - File system errors left uncorrected
8 - Operational error
16 - Usage or syntax error
32 - Fsck canceled by user request
128 - Shared library error

The exit code returned when multiple file systems are checked is the bit-wise OR of the exit codes for each file system that is checked.

BIND Security

BIND supports a number of different methods to protect the updating and transfer of zones, on both master and slave nameservers:

DNSSEC — Short for DNS SECurity, this feature allows for zones to be cryptographically signed with a zone key.
In this way, the information about a specific zone can be verified as coming from a nameserver that has signed it with a particular private key, as long as the recipient has that nameserver’s public key.

BINDversion 9 also supports the SIG(0) public/private key method of message authentication.

TSIG — Short for Transaction SIGnatures, a shared secret key exists on the master and slave server, verifying that a transfer from master to slave is authorized.
This feature strengthens the standard IP address-based method of transfer authorization. An attacker would not only need to have access to the IP address to transfer the zone, but they would also need to know the secret key.

BINDversion 9 also support TKEY, which is another shared secret key method of authorizing zone transfers.

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.

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.

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