Sunday, December 14, 2008

Most Common Mistakes made by Linux Administrators

This article will help you avoid those mistakes by laying out the most typical Linux missteps.

Installing applications from various types

This might not seem like such a bad idea at first. You are running Ubuntu so you know the package management system uses .deb packages. But there are a number of applications that you find only in source form. No big deal right? They install, they work. Why shouldn’t you? Simple, your package management system can’t keep track of what you have installed if it’s installed from source. So what happens when package A (that you installed from source) depends upon package B (that was installed from a .deb binary) and package B is upgraded from the update manager? Package A might still work or it might not. But if both package A and B are installed from .debs, the chances of them both working are far higher. Also, updating packages is much easier when all packages are from the same binary type.

Neglecting updates

Okay, this one doesn’t point out Linux as much as it does poor administration skills. But many admins get Linux up and running and think they have to do nothing more. It’s solid, it’s secure, it works. Well, new updates can patch new exploits. Keeping up with your updates can make the difference between a compromised system and a secure one. And just because you can rest on the security of Linux doesn’t mean you should. For security, for new features, for stability — the same reasons we have all grown accustomed to updating with Windows — you should always keep up with your Linux updates.

Poor root password choice

Okay, repeat after me: “The root password is the key to the kingdom.” So why would you make the key to the kingdom simple to crack? Sure, make your standard user password something you can easily remember and/or type. But that root password — you know, the one that’s protecting your enterprise database server — give that a much higher difficulty level. Make that password one you might have to store, encrypted, on a USB key, requiring you to slide that USB key into the machine, mount it, decrypt the password, and use it.

Avoiding the command line

No one wants to have to memorize a bunch of commands. And for the most part, the GUI takes care of a vast majority of them. But there are times when the command line is easier, faster, more secure, and more reliable. Avoiding the command line should be considered a cardinal sin of Linux administration. You should at least have a solid understanding of how the command line works and a small arsenal of commands you can use without having to RTFM. With a small selection of command-line tools on top of the GUI tools, you should be ready for just about anything.

Not keeping a working kernel installed

Let’s face it, you don’t need 12 kernels installed on one machine. But you do need to update your kernel, and the update process doesn’t delete previous kernels. What do you do? You keep at least the most recently working kernel at all times. Let’s say you have 2.6.22 as your current working kernel and 2.6.20 as your backup. If you update to 2.6.26 and all is working well, you can remove 2.6.20. If you use an rpm-based system, you can use this method to remove the old kernels: rpm -qa | grep -i kernel followed by rpm-e kernel-{VERSION}.

Not backing up critical configuration files

How many times have you upgraded X11 only to find the new version fubar’d your xorg.conf file to the point where you can no longer use X? It used to happen to me a lot when I was new to Linux. But now, anytime X is going to be updated I always back up /etc/X11/xorg.conf in case the upgrade goes bad. Sure, an X update tries to back up xorg.conf, but it does so within the /etc/X11 directory. And even though this often works seamlessly, you are better off keeping that backup under your own control. I always back up xorg.conf to the /root directory so I know only the root user can even access it. Better safe than sorry. This applies to other critical backups, such as Samba, Apache, and MySQL, too.

Booting a server to X

When a machine is a dedicated server, you might want to have X installed so some administration tasks are easier. But this doesn’t mean you should have that server boot to X. This will waste precious memory and CPU cycles. Instead, stop the boot process at runlevel 3 so you are left at the command line. Not only will this leave all of your resources to the servers, it will also keep prying eyes out of your machine (unless they know the command line and passwords to log in). To log into X, you will simply have to log in and run the command startx to bring up your desktop.

Not understanding permissions

Permissions can make your life really easy, but if done poorly, can make life really easy for hackers. The simplest way to handle permissions is using the rwx method. Here’s what they mean: r=read, w=write, x=execute. Say you want a user to be able to read a file but not write to a file. To do this, you would issue chmod u+r,u-wx filename. What often happens is that a new user sees an error saying they do not have permission to use a file, so they hit the file with something akin to chmod 777 filename to avoid the problem. But this can actually cause more problems because it gives the file executable privileges. Remember this: 777 gives a file rwx permissions to all users (root, group, and other), 666 gives the file rw privileges to all users, 555 gives the file rx permissions to all users, 444 gives r privileges to all users, 333 gives wx privileges to all users, 222 gives w privileges to all users, 111 gives x privileges to all users, and 000 gives no privileges to all users.

Logging in as root user

I can’t stress this enough. Do NOT log in as root. If you need root privileges to execute or configure an application, su to root in a standard user account. Why is logging in as root bad? Well, when you log on as a standard user, all running X applications still have access only to the system limited to that user. If you log in as root, X has all root permissions. This can cause two problems: 1) if you make a big mistake via a GUI, that mistake can be catastrophic to the system and 2) with X running as root that makes your system more vulnerable.

Ignoring log files
There is a reason /var/log exists. It is a single location for all log files. This makes it simple to remember where you first need to look when there is a problem. Possible security issue? Check /var/log/secure. One of the very first places I look is /var/log/messages. This log file is the common log file where all generic errors and such are logged to. In this file you will get messages about networking, media changes, etc. When administering a machine you can always use a third-party application such as logwatch that can create various reports for you based on your /var/log

Read more!

Monday, December 8, 2008

Tried and Tested method to Recover Damaged CD / DVD

Well, there are many methods that can be used to recover damaged CDs but to recover DVDs is somewhat tougher, I have come across many software which claim to do the same but when I tried them, none of them was able to achieve the desired result.

So after banging my head for some time, I have come across one method that worked for me. I am just going to explain and then hope that maybe it would work for you too.

The tool I am going to use here is called CD Check. Well its a paid tool but you I happen to have copy which you can download here.

Whats better is that this tool is just 1.5 MB. Download and install.

This is how it looks


All you need to do is, click on check, once it checks the DVD, you can go ahead and click on Recover Button

You'll see something similar to below


Just specify an output folder and click continue, you should be good to go.

Please let me know if it worked

Read more!

Thursday, December 4, 2008

Minimize removable media headaches in Linux

For many new Linux users, removable media can be a deal-breaker. Anyone coming over from Windows knows you simply insert the CD, use it, and eject it. With Linux, it isn't always that simple. In fact, with Linux, removable media has always held a completely different philosophy.
In the old days of UNIX, removable media was seen in the same light as the PC itself -- multi-user. So when you inserted some form of media (usually a floppy disk, back then), it had to be mounted to a mount point (such as /mnt/floppy) and was then made available to all users on the system. Because of this, the removable media synchronization wasn't "on demand." It typically worked by caching the data until the media was unmounted. Upon unmounting the media, the data was written and the media could be removed.

Linux has caught up to the needs of today's user and, in many cases, the media mounting/unmounting is automatic. But not every situation is the same. Here are some tips that should make your Linux life with removable media better.


Use the right desktop
The right desktop can make your job so much easier. The newest releases of both KDE and GNOME offer systems that check for the insertion of removable media. When a CD is inserted, you will be greeted with a window asking what you would like to do with the media. You can even set that action you choose as the default action to take upon insertion of that type of media. Those desktops also have applets that reside in the panel (or desktop icons) that allow you to easily mount and unmount the media with a click of the mouse. No more entering commands like mount /dev/cdrom /media/cdrom.


Get to know /etc/fstab

Because I generally stick with more old-school desktops (such as Enlightenment DR16), I often still have to mount my removable media. So instead of having to issue the full command mount /dev/sda1 /media/mp3 to mount my MP3 player, I will add a line to my /etc/fstab file that will do two things: Point the device to the correct mount point and make sure the mount point is both readable and writable by the user. The fstab entry will look something like this:

/dev/sda1 /media/ipod vfat users,exec,noauto,managed 0 0

Now when you need to mount the device, enter mount /media/ipod. Just remember to unmount the device before you remove it.


Use udev to make your life easier
Let's build upon using fstab to simplify mount of removable media. Let's say you have an entry in your /etc/fstab file for your iPod pointing it from /dev/sda1 to /media/ipod. Now let's say you plug in another USB device or reboot. The problem is that entry in your fstab file may or may not be valid now because /dev/sda1 might be used by something else. To avoid this, make use of the udev system. You're going to tell udev to always make sure that device shows up with the same filename. Enter a line in the /etc/udev/rules.d/00.rules file that looks like:

## iPod
BUS="scsi", SYSFS{model}="iPod*", NAME="ipod"

Of course, your entry in /etc/fstab will have to change to reflect the above. So now /etc/fstab will look like:

/dev/ipod /media/ipod vfat users,exec,noauto,managed 0 0


Use menu entries for mount/umount
Back in the day, when I used AfterStep, I always had a submenu that included an entry for mounting and unmounting both the floppy and the CD-ROM. This made life much easier because I no longer had to open up a command line and enter the mount and umount commands to use the device. Granted, the window manager you use will determine how this is employed. For example, in Enlightenment, I can create two entries in the user_apps.menu file that look like:

"mount iPod" NULL exec "mount /media/ipod"
"umount iPod" NULL exec "umount /media/ipod"

Now on the Enlightenment menu, I will see two entries: mount iPod and umount iPod. With the device connected all I have to do is click the mount entry. To remove the device I only need to click the umount entry.


Be safe with your removable hard drives
One time, I left a USB drive plugged into a machine I was re-installing the operating system on. I wasn't paying enough attention and wound up with an operating system spanning both my internal drive and my removable drive. Yes, this was a big mistake and no, it has never happened since. Why? Because anytime I install an OS on a machine with a removable drive, that removable drive is removed during installation. It's not a problem, because upon first boot, I plug the drive back in and it is always automatically recognized and mounted. Of course, I will make an entry in /etc/fstab that will automatically mount the drive on boot.


Never forget to use the dmesg command
When you plug in a device or insert removable media, the dmesg command will give you the status of the system. For example, when I insert an iPod into a Mandriva 2008 machine I run the dmesg command and see:

usb 1-4: new high speed USB device using ehci_hcd and address 2
usb 1-4: configuration #1 chosen from 3 choices
usb 1-4: USB disconnect, address 2
usb 1-4: new high speed USB device using ehci_hcd and address 3
usb 1-4: configuration #1 chosen from 2 choices
Initializing USB Mass Storage driver...
scsi2 : SCSI emulation for USB Mass Storage devices
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usb-storage: device found at 3
usb-storage: waiting for device to settle before scanning
scsi 2:0:0:0: Direct-Access Apple iPod 1.62 PQ: 0 ANSI: 0
sd 2:0:0:0: [sdb] 58605120 512-byte hardware sectors (30006 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 68 00 00 08
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sd 2:0:0:0: [sdb] 58605120 512-byte hardware sectors (30006 MB)
sd 2:0:0:0: [sdb] Write Protect is off
sd 2:0:0:0: [sdb] Mode Sense: 68 00 00 08
sd 2:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1 sdb2
sd 2:0:0:0: [sdb] Attached SCSI removable disk
sd 2:0:0:0: Attached scsi generic sg1 type 0
usb-storage: device scan complete

From this, I know the device is being seen at /dev/sdb. Without knowing this, I would have a hard time guessing where the device has been mapped to.


Don't forget the eject command
Most people don't know that there's a command to eject CDs from the CD drive. Naturally, this isn't an issue for those who have tray CD drives. But for those with slot-loading CD drives, eject will save you from pulling your hair out. After you have used and unmounted your CD drive, open up a terminal and enter the eject command, and your CD will pop out. To simplify the process, make a menu entry for the command.


Remember that the mount command tells all
If you're unsure what devices are mounted on your system, issue the mount command to see a listing of everything currently mounted on your machine. The output looks like:

/dev/sda1 on / type ext3 (rw)
none on /proc type proc (rw)
/dev/sda6 on /home type ext3 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
none on /sys/fs/fuse/connections type fusectl (rw)

From this output, I can see that I have no removable media mounted on the machine. So I know it's safe to unplug anything removable. Had there been an entry for, say, my iPod, I would know not to remove the device without unmounting it. Of course, on modern systems (using one of the major desktops), this will be made clear with the icon or the removable device applet on the panel. But this command will be helpful (along with dmesg) in debugging removable media issues.

Reformat your iPod to a Windows format
If you've tried to add songs on a Mac-formatted iPod on Linux, you've probably discovered that it's not possible without jumping through hoops even programmers don't want to jump through. Format your iPod in Windows format, and you won't have any problems using your iPod with Amarok, Banshee, or gtkpod.


Allow others to connect to your removable media
In my office, I have a removable drive mounted to /media/music that contains my entire music collection. I allow others to listen to that music via samba by including it as a share. I like doing this far better than allowing users to have access to my internal drive because 1) it keeps anyone from trashing the drive containing my OS and 2) it allows me to keep sensitive data physically separated from shared data. This approach doesn't have to be used for music, either. It's a great way to share interoffice files or have a single repository for backups. Once the drive is full, remove it and store it. Just add a new removable drive for the new backup.

Simpler, easier
Not only is today's Linux not nearly as challenged with removable media as it once was, it's really quite flexible and user friendly. With the help of these tips, you should now see how you can expand your Linux experience to include various ways to employ removable media.

Read more!