“ROOT Filesystem is Currently Mounted Read Only”

July 18, 2008 / 1 Comment

This error can be a bit unnerving if your Linux system doesn’t reboot cleanly. To remount your root filesystem as read/write (rw) issue this command:

# mount -n -o remount rw /

Backup GMAIL with FetchMail

July 14, 2008 / 0 Comments

If you’re anything like me you really enjoy GMail but you really enjoy the peace of mind and comfort in having a local copy of your email available at all times. I tend to not rely heavily on services provided by third party providers, even Google. What if I am offline? What if they have a long outage and I need access to my mail? As a society, we rely heavily on mail… probably more than we really know. Think about it: When was the last time your companies mail server went down? Global anarchy, chaos and fires result.

In this tutorial I will install, configure and run fetchmail to retrieve my messages over POP on a CentOS server.

Backing up GMail

Here we go 🙂

1. Check to make sure fetchmail is installed on your system.

     # rpm -aq | grep fetchmail

If fetchmail is installed you will see the package returned. If not, issue this command in CentOS:
    # yum -y install fetchmail

2. Good, now we have fetchmail installed. Let’s verify by using this command:

     # fetchmail -V | grep release
        This is fetchmail release 6.2.5+IMAP-GSS+RPA+NTLM+SDPS+SSL+INET6+NLS

3. Let’s create a user which will keep our gmail backup.

     # adduser gmailbackup

4. Let’s create a fetchmail configuration file called ".fetchmailrc" in your current users home directory.

     # vi ~/.fetchmailrc

5. In this file enter the following substituting your credentials where necessary:

     poll pop.gmail.com with proto POP3 and options no dns
     user ‘[email protected]’ there with password ‘yourpassword’ is ‘gmailbackup’ here  options ssl

6. Now let’s set the permissions on the new .fetcmailrc file otherwise fetchmail will complain like this:
        File /root/.fetchmailrc must have no more than -rwx–x— (0710) permissions.

To set these permissions use this command:

      # chmod 710 ~/.fetchmailrc

7. Let’s fetch the mail with verbosity on.

      # fetchmail -vk

8. Let’s verify the mail we downloaded
      # mail -u gmailbackup

9. After this transfer let’s set up a cron entry to run a fetch every hour for safe keeping of our GMail.

      # crontab -e

    Add this to the bottom of your users cron:
          0 * * * * root fetchmail -k &> /dev/null

    The above redirects all output from fetchmail to /dev/null so we don’t get chatter in our local users mail box.

That’s it! You’re all done and being backed up. For easier viewing, assign a password to your local gmailbackup user with "passwd gmailbackup" and use a web client like RoundCube or SquirrelMail to view your GMail backup.

Using SFDISK to backup your partition table

July 14, 2008 / 0 Comments

Many times we perform full backups of the root partition (/), including all mount points under root. How often do we back up our partition tables? What if we have total disk failure and our only restore option is a file-level restore? Will we know what our partition sizes were? Enter sfdisk.

Using SFDISK

The most common usage of sfdisk is to dump the partition sizes and count to a file for later import. This partition table dump can be included in your gzipped tarball.

Use this command to dump /dev/sda’s partition table:

# sfdisk -d /dev/sda > /backup/sda.part

The dump file will look like this:
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start=       63, size=479990007, Id=83, bootable
/dev/sda2 : start=479990070, size=  8385930, Id=82
/dev/sda3 : start=        0, size=        0, Id= 0
/dev/sda4 : start=        0, size=        0, Id= 0

Restoring Partitions from SFDISK Dump

To restore your partition table from a dump file use this command:

# sfdisk /dev/sda < sda.part

Linux: The Sticky, SUID and SGID Bits

July 14, 2008 / 1 Comment

I’m sure anyone who has used Linux has heard of the Sticky, SUID or SGID bits. The most common (and easiest to explain) is the infamous "Sticky Bit".

The Sticky Bit

Back when systems had kilobytes of RAM (instead of gigabytes), this bit was used to mark a file (program) to run, and remain, primarily in memory. This was a great benefit back in "the day". Now the most common use for the sticky bit is to maintain the integrity of publicly accessible directories.

Setting the Sticky Bit

To set the sticky bit use this command:
# chmod +t <file/directory>

Looking for the Sticky Bit

To identify the sticky bit use the standard "ls" command to show all files. Look for a (t) in the listing.

For example:
-rw-r–r-T  1 root root 0 Jul 14 21:14 foo

The SUID Bit

SUID stands for "Set User ID". The SUID makes the program run as the user who owns the program (instead of the current user). I have an application called "test" which is owned by "dale" and the user "al" runs "test" the program will still run as "dale" if the SUID bit is set.

Setting the SUID Bit

To set the SUID bit use this command:
# chmod +s <file/directory>

Looking for the SUID Bit

To identify the SUID bit use the standard "ls" command to show all files. Look for an (S) in the listing.

For example:
-rwSr-Sr–  1 root root 0 Jul 14 21:14 foo

The SGID Bit

The SGID bit is much like the SUID bit but runs a program only as the set group ID group.

Examples

Setting SUID for user and not group
# chmod u+s <file/directory>

Setting sticky bit for group only
# chmod g+t <file/directory>