System log messages are stored in the /var/log/ directory tree in plain text format, most are logged through the systemd and klogd programs, which may be configured via the /etc/syslog.conf file.
The logrotate utility, launched from /etc/cron.daily/logrotate, starts a fresh log file every week or when they reach a maximum size and automatically removes or archives old log files. You may change the configuration files
/etc/logrotate.conf and /etc/logrotate.d/* as required.
In adition to syslog messages, various other log files and status files are generated in /var/log by other programs:
File Source
-------------|------------------------
audit Direcotry for audit logs
boot.msg Message from system startup
lastlog Last successful log in
vsftpd.log Transcastions log of the VSFTP daemon
localmessage Written by syslog
mail written by syslog, contains message from the MTA
messages written by syslog, contains message from su and ssh
news syslog news entries
warn written by syslog
wtmp written by the PAM susbsystem
Thursday, February 26, 2009
Tuesday, February 24, 2009
Linux (Ext3/Ext2) file undelete/recovery tool - gET iT i sAY - giis
giis (gET iT i sAY) is a console based Linux (Ext3/Ext2) file undelete/recovery tool.Once installed, files on your hard disk can be recovered using giis.A new functionality automatically restores recovered files into it's original directories-if path exists."But those files which are deleted before the installation of giis can't be recovered using giis".
Features
»Recover files Deleted Date on specific date or deleted before/after specific date or even within specific date range.
» Recover files with their original access permission types and file owner and group details.
»User friendly configuration file which supports adding new directories even after installation.
Existing Features
» Recover deleted files of all users.
» Recover deleted files of a specific user.
» Recovery of files based on the File type (gif,mp3,jpeg)
» Recovers deleted hidden files or system files.
» Recovers Dropped mysql tables.
» Forensic analyzer is provided to assist data dump from the harddisk.
» If original path of deleted file exists,Recovered files automatically restored back to their appropriate directories.
» Provides list of deleted files and it's restore path
» If contents are modified or overwritten , during recovery user has the option to compare to old file data with current disk data using giis dump option.
» Displays your current file system details.
» If file is modified ,it allows user to decide whether to retrieve latest version of deleted file or older version.
» Allows user to choose directories (other than /root and /home) that can be protected by giis.
» All newly created files and directory are added,as time limit specified in crontab.
Features
»Recover files Deleted Date on specific date or deleted before/after specific date or even within specific date range.
» Recover files with their original access permission types and file owner and group details.
»User friendly configuration file which supports adding new directories even after installation.
Existing Features
» Recover deleted files of all users.
» Recover deleted files of a specific user.
» Recovery of files based on the File type (gif,mp3,jpeg)
» Recovers deleted hidden files or system files.
» Recovers Dropped mysql tables.
» Forensic analyzer is provided to assist data dump from the harddisk.
» If original path of deleted file exists,Recovered files automatically restored back to their appropriate directories.
» Provides list of deleted files and it's restore path
» If contents are modified or overwritten , during recovery user has the option to compare to old file data with current disk data using giis dump option.
» Displays your current file system details.
» If file is modified ,it allows user to decide whether to retrieve latest version of deleted file or older version.
» Allows user to choose directories (other than /root and /home) that can be protected by giis.
» All newly created files and directory are added,as time limit specified in crontab.
Monday, February 16, 2009
How to Create and Configure robot.txt for Apache web server
"Robots.txt" is a regular text file that through its name, has special meaning to the majority of "honorable" robots on the web. By defining a few rules in this text file, you can instruct robots to not crawl and index certain files, directories within your site, or at all. For example, you may not want Google to crawl the /images directory of your site, as it's both meaningless to you and a waste of your site's bandwidth. "Robots.txt" lets you tell Google just that.
1) Here's a basic "robots.txt":
User-agent: *
Disallow: /
With the above declared, all robots (indicated by "*") are instructed to not index any of your pages (indicated by "/"). Most likely not what you want, but you get the idea.
2) you may not want Google's Image bot crawling your site's images and making them searchable online, if just to save bandwidth. The below declaration will do the trick:
User-agent: Googlebot-Image
Disallow: /
3) The following disallows all search engines and robots from crawling select directories and pages:
User-agent: *
Disallow: /cgi-bin/
Disallow: /privatedir/
Disallow: /tutorials/blank.htm
4) You can conditionally target multiple robots in "robots.txt." Take a look at the below:
User-agent: *
Disallow: /
User-agent: Googlebot
Disallow: /cgi-bin/
Disallow: /privatedir/
This is interesting- here we declare that crawlers in general should not crawl any parts of our site, EXCEPT for Google, which is allowed to crawl the entire site apart from /cgi-bin/ and /privatedir/. So the rules of specificity apply, not inheritance.
5) There is a way to use Disallow: to essentially turn it into "Allow all", and that is by not entering a value after the semicolon(:):
User-agent: *
Disallow: /
User-agent: ia_archiver
Disallow:
Here all crawlers should be prohibited from crawling our site, except for Alexa, which is allowed.
6) Finally, some crawlers now support an additional field called "Allow:", most notably, Google. As its name implies, "Allow:" lets you explicitly dictate what files/folders can be crawled. However, this field is currently not part of the "robots.txt" protocol, so use it only if absolutely needed, as it might confuse some less intelligent crawlers.
Per Google's FAQs for webmasters, the below is the preferred way to disallow all crawlers from your site EXCEPT Google:
User-agent: *
Disallow: /
User-agent: Googlebot
Allow: /
Finally this file (robot.txt) must be uploaded to the root accessible directory of your site, not a subdirectory (eg. www.mysite.com/robot.txt) it is only by following the above rules will search engines interpret the instructions contained in the file.
1) Here's a basic "robots.txt":
User-agent: *
Disallow: /
With the above declared, all robots (indicated by "*") are instructed to not index any of your pages (indicated by "/"). Most likely not what you want, but you get the idea.
2) you may not want Google's Image bot crawling your site's images and making them searchable online, if just to save bandwidth. The below declaration will do the trick:
User-agent: Googlebot-Image
Disallow: /
3) The following disallows all search engines and robots from crawling select directories and pages:
User-agent: *
Disallow: /cgi-bin/
Disallow: /privatedir/
Disallow: /tutorials/blank.htm
4) You can conditionally target multiple robots in "robots.txt." Take a look at the below:
User-agent: *
Disallow: /
User-agent: Googlebot
Disallow: /cgi-bin/
Disallow: /privatedir/
This is interesting- here we declare that crawlers in general should not crawl any parts of our site, EXCEPT for Google, which is allowed to crawl the entire site apart from /cgi-bin/ and /privatedir/. So the rules of specificity apply, not inheritance.
5) There is a way to use Disallow: to essentially turn it into "Allow all", and that is by not entering a value after the semicolon(:):
User-agent: *
Disallow: /
User-agent: ia_archiver
Disallow:
Here all crawlers should be prohibited from crawling our site, except for Alexa, which is allowed.
6) Finally, some crawlers now support an additional field called "Allow:", most notably, Google. As its name implies, "Allow:" lets you explicitly dictate what files/folders can be crawled. However, this field is currently not part of the "robots.txt" protocol, so use it only if absolutely needed, as it might confuse some less intelligent crawlers.
Per Google's FAQs for webmasters, the below is the preferred way to disallow all crawlers from your site EXCEPT Google:
User-agent: *
Disallow: /
User-agent: Googlebot
Allow: /
Finally this file (robot.txt) must be uploaded to the root accessible directory of your site, not a subdirectory (eg. www.mysite.com/robot.txt) it is only by following the above rules will search engines interpret the instructions contained in the file.
Thursday, February 12, 2009
FreeBSD:PortAudit
The portaudit utility allows you to check your installed ports against a database of published security vulnerabilities. This database is maintained by the FreeBSD port administrators and the FreeBSD Security Team. If a security advisory exists for an installed port, a web link to the security advisory is provided for more information.
To install portaudit, enter:
# cd /usr/ports/ports-mgmt/portaudit
# make install clean
# rehash
To check installed ports against the current portaudit database, enter:
# portaudit -Fda
To install portaudit, enter:
# cd /usr/ports/ports-mgmt/portaudit
# make install clean
# rehash
To check installed ports against the current portaudit database, enter:
# portaudit -Fda
Monday, February 9, 2009
Don't run as root
Anyone who knows anythhing about GNU/Linux or FreeBSD security will tell you never, never, never to run anything as the root user.
Logging in as administrator in a Windows network is common, but doing so is discouraged in the SNU/Linux or FreeBSD community.
This is why whenever you need to run something as root, you use the sudo command.
Any system administrator can use the sudo command if you give them the password. to see how and when the sudo password is being used, check out /var/log/messages.
Because you're looking for all uses of suo, use grep command to find them.
Logging in as administrator in a Windows network is common, but doing so is discouraged in the SNU/Linux or FreeBSD community.
This is why whenever you need to run something as root, you use the sudo command.
Any system administrator can use the sudo command if you give them the password. to see how and when the sudo password is being used, check out /var/log/messages.
Because you're looking for all uses of suo, use grep command to find them.
Thursday, February 5, 2009
New Report Shows 92 Percent of Critical Microsoft Vulnerabilities are Mitigated by Eliminating Admin Rights
BeyondTrust’s findings show that among the 2008 Microsoft vulnerabilities given a "critical" severity rating, 92 percent shared the same best practice advice from Microsoft to mitigate the vulnerability: "Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights." This language, found in the "Mitigating Factors" portion of Microsoft’s security bulletins, also appears as a recommendation for reducing the threat from nearly 70 percent of all vulnerabilities reported in 2008.
Other key findings from BeyondTrust’s report show that removing administrator rights will better protect companies against the exploitation of:
* 94 percent of Microsoft Office vulnerabilities reported in 2008
* 89 percent of Internet Explorer vulnerabilities reported in 2008
* 53 percent of Microsoft Windows vulnerabilities reported in 2008.
Further illustrating the benefits to enterprises of removing administrator rights from users, a recent Gartner report states, "The Gartner TCO model shows a significant reduction in TCO between a managed desktop where the user is an administrator, compared with a desktop where the user is a standard user. Among the most remarkable observations is that the model shows a 24 percent decrease in the amount of IT labor needed for technical support." Gartner, Inc., "Organizations That Unlock PCs Unnecessarily Will Face High Costs," Michael A. Silver, Ronni J.
Other key findings from BeyondTrust’s report show that removing administrator rights will better protect companies against the exploitation of:
* 94 percent of Microsoft Office vulnerabilities reported in 2008
* 89 percent of Internet Explorer vulnerabilities reported in 2008
* 53 percent of Microsoft Windows vulnerabilities reported in 2008.
Further illustrating the benefits to enterprises of removing administrator rights from users, a recent Gartner report states, "The Gartner TCO model shows a significant reduction in TCO between a managed desktop where the user is an administrator, compared with a desktop where the user is a standard user. Among the most remarkable observations is that the model shows a 24 percent decrease in the amount of IT labor needed for technical support." Gartner, Inc., "Organizations That Unlock PCs Unnecessarily Will Face High Costs," Michael A. Silver, Ronni J.
Wednesday, February 4, 2009
Using The Red Hat Rescue Environment
There are several different rescue CDs out there, and they all provide slightly different rescue environments. The requirement here at Red Hat Academy is, perhaps unsurprisingly, an intimate knowledge of how to use the Red Hat Enterprise Linux (RHEL) 5 boot CD.
All these procedures should work exactly the same way with Fedora and CentOS. As with any rescue environment, it provides a set of useful tools; it also allows you to configure your network interfaces. This can be helpful if you have an NFS install tree to mount, or if you have an RPM that was corrupted and needs to be replaced. There are LVM tools for manipulating Logical Volumes, "fdisk" for partitioning devices, and a number of other tools making up a small but capable toolkit.
The Red Hat rescue environment provided by the first CD or DVD can really come in handy in many situations. With it you can solve boot problems, bypass forgotten GRUB bootloader passwords, replace corrupted RPMs, and more. I will go over some of the most important and common issues. I also suggest reviewing a password recovery article written by Suramya Tomar (http://linuxgazette.net/107/tomar.html) that deals with recovering lost root passwords in a variety of ways for different distributions. I will not be covering that here since his article is a very good resource for those problems.
Start by getting familiar with using GRUB and booting into single user mode. After you learn to overcome and repair a variety of boot problems, what initially appears to be a non-bootable system may be fully recoverable. The best way to get practice recovering non-bootable systems is by using a non-production machine or a virtual machine and trying out various scenarios. I used Michael Jang's book, "Red Hat Certified Engineer Linux Study Guide", to review non-booting scenarios and rehearse how to recover from various situations. I would highly recommend getting comfortable with recovering non-booting systems because dealing with them in real life without any practice beforehand can be very stressful. Many of these problems are really easy to fix but only if you have had previous experience and know the steps to take.
When you are troubleshooting a non-booting system, there are certain things that you should be on the alert for. For example, an error in /boot/grub/grub.conf, /etc/fstab, or /etc/inittab can cause the system to not boot properly; so can an overwritten boot sector. In going through the process of troubleshooting with the RHEL rescue environment, I'll point out some things that may be of help in these situations.
Getting started
First, if you can't get the system booted by normal means, check things like the order of boot devices in the BIOS just to make sure you're reading the right drive. You should also ensure that the drive is being recognized. Try to pinpoint where in the boot sequence the process is failing; take note of any unusual activity or messages. Remember that the boot process runs in this order:
1. BIOS
2. MBR
3. GRUB - /etc/grub/grub.conf
4. Kernel
5. INIT - /etc/inittab
* /etc/rc.d/rc.sysinit
* /etc/fstab
6. Runlevel
Pay close attention to any configuration files, as they are likely places for errors.
OK - it's time for the boot CD. The Linux rescue environment will load a minimal system with only a small subset of commands, but it should be enough for our purposes.
Rescue
After restarting the machine with the CD or DVD in the drive, you will need to type linux rescue at the boot prompt instead of hitting 'Enter' for a normal install.
Booting into rescue
The next screen will ask us to choose a language.
Choose Language
The screen after that will ask for our keyboard layout.
Select keyboard
At this point, we are asked if we would like to configure our network interfaces. If you need access to an NFS install tree or some other external resource, you should select this option. It will allow you to configure your network interfaces with IPv4 and/or IPv6; you can also choose manual or dynamic configuration of your IP address and subnet mask. If you think that you might need to reinstall a corrupt package and have no network install tree, you will still be able to access the RPMs on the CD or DVD. You will need to mount the CD or DVD on the rescue filesystem to do this.
Choose if we need networking
The next stage of the rescue environment will scan your disks and attempt to mount your partitions under /mnt/sysimage. Note that you have the option to mount read/write, read-only, or to skip and not mount or attempt to mount any partition. Here is where you ask yourself "what do I need to do?" Only you know if you've experienced a drive crash and possible data loss. Do you need to check or repair your partitions? If so, you'll need to skip mounting - running fsck on mounted partitions is a bad idea.
Chose mount options
If you choose to mount your partitions, you'll see the following screen.
Partitions mounted under /mnt/sysimage
At this point, you can get started with troubleshooting and checking for errors. Good places to start looking for problems depend on your particular situation. System logs are always an excellent place if you are unsure of the exact nature of your problem. Again, /boot/grub/grub.conf, /etc/fstab, and /etc/inittab are the most common places for errors that will prevent normal system startup.
If you get this next screen as a result of trying to mount your system partitions, it is likely that you have an error in the /etc/fstab file and a partition is being incorrectly specified as your root device. You can check that your partitions are correctly labeled and listed in /etc/fstab by writing down your /etc/fstab file and running e2label /dev/partition over your partitions. If you're not sure what they are, you can get a listing by running fdisk -l.
Error mounting partitions
Removing a GRUB Bootloader Password
This often comes up when you need to append an option to the GRUB boot stanza - at which point you find out that the last sysadmin neglected to leave us that information. Or we need to be able to boot into a different runlevel or emergency mode for troubleshooting - and a GRUB password is preventing us from doing this. Some system administrators think that a GRUB password is going to save them from unauthorized access; unfortunately, this is not true. If some one can touch your console, they can acquire complete access to your system and data.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Run vi /mnt/sysimage/boot/grub/grub.conf
6. Comment out or remove the line containing the password hash.
7. Reboot.
As they say, "physical access equals root access."
Reinstalling RPMs from the CD or DVD
When you are troubleshooting, and you suspect that some critical files were altered or a package became corrupted, the following command can be used to verify that the file is still the same as it was in the RPM: rpm -Vf /path/file. To verify if a specific RPM that was downloaded or is on removable media is intact, use rpm -Vp packagename.rpm. Recall that you can access the RPMs on the install CD or DVD for reinstallation, although you'll need to mount that CD or DVD manually.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Mount the CD or DVD by typing mount /dev/cdrom /mnt/source.
6. Select the RPM and reinstall it with rpm --replacepkgs -ivh /mnt/source/Server/rpmfile.rpm --root /mnt/sysimage
7. Reboot.
Fixing a corrupted Master Boot Record
This will restore only the master boot record; note that the partition table will not be recovered by this sequence if it is damaged.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Type chroot /mnt/sysimage to enter your Linux environment.
6. Type grub-install /dev/sda or grub-install /dev/hda (whatever is appropriate for your hardware.)
7. Reboot.
Backing up and resoring the MBR and partition table
It's a good idea to save a known-good copy of your MBR and partition table before problems arise; the former may be easy to recreate with GRUB, but the latter can be quite a challenge. To save a copy of both, run the following command:
dd if=/dev/sda of=mbr-parttable bs=512 count=1
This will create a file called "mbr-parttable" which should be saved off-system.
To restore the MBR and the partition table which had been saved with the previous command, run the following (assuming that the file you created is in the current directory):
dd if=mbr-parttable of=/dev/sda bs=512 count=1
Things to keep in mind
When in rescue mode, it's vital to stay focused on what you are doing. Think critically and don't do things haphazardly; pay attention to any errors you see. I personally keep paper notes of any problems that I notice, and document everything I do in detail. Proceeding from there depends on my best estimate of the problem: I may list my partitions and write them down if I believe that's where the problem is. I list the files that are involved with the process or problem that occurred and mark them off one by one in a organized manner as I go down the list. If you're testing out possible solutions, try only one thing at a time and if it is not the correct solution, revert to the previous state before going on to try the next fix. Make copies of files before you edit them. Ask yourself questions about why you would see the problem produce the error that it did. Read logs and see if you can deduce why the error occurred in the first place. A temporary patch may cost you more downtime at an even more inconvenient time later.
Standard Troubleshooting Model
1. Define the problem
2. Gather information and data
3. Form a hypothesis
4. Try possible solutions
5. Analyze data
6. Draw conclusions
7. Redefine the problem based on results
8. Repeat as necessary
All these procedures should work exactly the same way with Fedora and CentOS. As with any rescue environment, it provides a set of useful tools; it also allows you to configure your network interfaces. This can be helpful if you have an NFS install tree to mount, or if you have an RPM that was corrupted and needs to be replaced. There are LVM tools for manipulating Logical Volumes, "fdisk" for partitioning devices, and a number of other tools making up a small but capable toolkit.
The Red Hat rescue environment provided by the first CD or DVD can really come in handy in many situations. With it you can solve boot problems, bypass forgotten GRUB bootloader passwords, replace corrupted RPMs, and more. I will go over some of the most important and common issues. I also suggest reviewing a password recovery article written by Suramya Tomar (http://linuxgazette.net/107/tomar.html) that deals with recovering lost root passwords in a variety of ways for different distributions. I will not be covering that here since his article is a very good resource for those problems.
Start by getting familiar with using GRUB and booting into single user mode. After you learn to overcome and repair a variety of boot problems, what initially appears to be a non-bootable system may be fully recoverable. The best way to get practice recovering non-bootable systems is by using a non-production machine or a virtual machine and trying out various scenarios. I used Michael Jang's book, "Red Hat Certified Engineer Linux Study Guide", to review non-booting scenarios and rehearse how to recover from various situations. I would highly recommend getting comfortable with recovering non-booting systems because dealing with them in real life without any practice beforehand can be very stressful. Many of these problems are really easy to fix but only if you have had previous experience and know the steps to take.
When you are troubleshooting a non-booting system, there are certain things that you should be on the alert for. For example, an error in /boot/grub/grub.conf, /etc/fstab, or /etc/inittab can cause the system to not boot properly; so can an overwritten boot sector. In going through the process of troubleshooting with the RHEL rescue environment, I'll point out some things that may be of help in these situations.
Getting started
First, if you can't get the system booted by normal means, check things like the order of boot devices in the BIOS just to make sure you're reading the right drive. You should also ensure that the drive is being recognized. Try to pinpoint where in the boot sequence the process is failing; take note of any unusual activity or messages. Remember that the boot process runs in this order:
1. BIOS
2. MBR
3. GRUB - /etc/grub/grub.conf
4. Kernel
5. INIT - /etc/inittab
* /etc/rc.d/rc.sysinit
* /etc/fstab
6. Runlevel
Pay close attention to any configuration files, as they are likely places for errors.
OK - it's time for the boot CD. The Linux rescue environment will load a minimal system with only a small subset of commands, but it should be enough for our purposes.
Rescue
After restarting the machine with the CD or DVD in the drive, you will need to type linux rescue at the boot prompt instead of hitting 'Enter' for a normal install.
Booting into rescue
The next screen will ask us to choose a language.
Choose Language
The screen after that will ask for our keyboard layout.
Select keyboard
At this point, we are asked if we would like to configure our network interfaces. If you need access to an NFS install tree or some other external resource, you should select this option. It will allow you to configure your network interfaces with IPv4 and/or IPv6; you can also choose manual or dynamic configuration of your IP address and subnet mask. If you think that you might need to reinstall a corrupt package and have no network install tree, you will still be able to access the RPMs on the CD or DVD. You will need to mount the CD or DVD on the rescue filesystem to do this.
Choose if we need networking
The next stage of the rescue environment will scan your disks and attempt to mount your partitions under /mnt/sysimage. Note that you have the option to mount read/write, read-only, or to skip and not mount or attempt to mount any partition. Here is where you ask yourself "what do I need to do?" Only you know if you've experienced a drive crash and possible data loss. Do you need to check or repair your partitions? If so, you'll need to skip mounting - running fsck on mounted partitions is a bad idea.
Chose mount options
If you choose to mount your partitions, you'll see the following screen.
Partitions mounted under /mnt/sysimage
At this point, you can get started with troubleshooting and checking for errors. Good places to start looking for problems depend on your particular situation. System logs are always an excellent place if you are unsure of the exact nature of your problem. Again, /boot/grub/grub.conf, /etc/fstab, and /etc/inittab are the most common places for errors that will prevent normal system startup.
If you get this next screen as a result of trying to mount your system partitions, it is likely that you have an error in the /etc/fstab file and a partition is being incorrectly specified as your root device. You can check that your partitions are correctly labeled and listed in /etc/fstab by writing down your /etc/fstab file and running e2label /dev/partition over your partitions. If you're not sure what they are, you can get a listing by running fdisk -l
Error mounting partitions
Removing a GRUB Bootloader Password
This often comes up when you need to append an option to the GRUB boot stanza - at which point you find out that the last sysadmin neglected to leave us that information. Or we need to be able to boot into a different runlevel or emergency mode for troubleshooting - and a GRUB password is preventing us from doing this. Some system administrators think that a GRUB password is going to save them from unauthorized access; unfortunately, this is not true. If some one can touch your console, they can acquire complete access to your system and data.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Run vi /mnt/sysimage/boot/grub/grub.conf
6. Comment out or remove the line containing the password hash.
7. Reboot.
As they say, "physical access equals root access."
Reinstalling RPMs from the CD or DVD
When you are troubleshooting, and you suspect that some critical files were altered or a package became corrupted, the following command can be used to verify that the file is still the same as it was in the RPM: rpm -Vf /path/file. To verify if a specific RPM that was downloaded or is on removable media is intact, use rpm -Vp packagename.rpm. Recall that you can access the RPMs on the install CD or DVD for reinstallation, although you'll need to mount that CD or DVD manually.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Mount the CD or DVD by typing mount /dev/cdrom /mnt/source.
6. Select the RPM and reinstall it with rpm --replacepkgs -ivh /mnt/source/Server/rpmfile.rpm --root /mnt/sysimage
7. Reboot.
Fixing a corrupted Master Boot Record
This will restore only the master boot record; note that the partition table will not be recovered by this sequence if it is damaged.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Type chroot /mnt/sysimage to enter your Linux environment.
6. Type grub-install /dev/sda or grub-install /dev/hda (whatever is appropriate for your hardware.)
7. Reboot.
Backing up and resoring the MBR and partition table
It's a good idea to save a known-good copy of your MBR and partition table before problems arise; the former may be easy to recreate with GRUB, but the latter can be quite a challenge. To save a copy of both, run the following command:
dd if=/dev/sda of=mbr-parttable bs=512 count=1
This will create a file called "mbr-parttable" which should be saved off-system.
To restore the MBR and the partition table which had been saved with the previous command, run the following (assuming that the file you created is in the current directory):
dd if=mbr-parttable of=/dev/sda bs=512 count=1
Things to keep in mind
When in rescue mode, it's vital to stay focused on what you are doing. Think critically and don't do things haphazardly; pay attention to any errors you see. I personally keep paper notes of any problems that I notice, and document everything I do in detail. Proceeding from there depends on my best estimate of the problem: I may list my partitions and write them down if I believe that's where the problem is. I list the files that are involved with the process or problem that occurred and mark them off one by one in a organized manner as I go down the list. If you're testing out possible solutions, try only one thing at a time and if it is not the correct solution, revert to the previous state before going on to try the next fix. Make copies of files before you edit them. Ask yourself questions about why you would see the problem produce the error that it did. Read logs and see if you can deduce why the error occurred in the first place. A temporary patch may cost you more downtime at an even more inconvenient time later.
Standard Troubleshooting Model
1. Define the problem
2. Gather information and data
3. Form a hypothesis
4. Try possible solutions
5. Analyze data
6. Draw conclusions
7. Redefine the problem based on results
8. Repeat as necessary
Using The Red Hat Rescue Environment
There are several different rescue CDs out there, and they all provide slightly different rescue environments. The requirement here at Red Hat Academy is, perhaps unsurprisingly, an intimate knowledge of how to use the Red Hat Enterprise Linux (RHEL) 5 boot CD.
All these procedures should work exactly the same way with Fedora and CentOS. As with any rescue environment, it provides a set of useful tools; it also allows you to configure your network interfaces. This can be helpful if you have an NFS install tree to mount, or if you have an RPM that was corrupted and needs to be replaced. There are LVM tools for manipulating Logical Volumes, "fdisk" for partitioning devices, and a number of other tools making up a small but capable toolkit.
The Red Hat rescue environment provided by the first CD or DVD can really come in handy in many situations. With it you can solve boot problems, bypass forgotten GRUB bootloader passwords, replace corrupted RPMs, and more. I will go over some of the most important and common issues. I also suggest reviewing a password recovery article written by Suramya Tomar (http://linuxgazette.net/107/tomar.html) that deals with recovering lost root passwords in a variety of ways for different distributions. I will not be covering that here since his article is a very good resource for those problems.
Start by getting familiar with using GRUB and booting into single user mode. After you learn to overcome and repair a variety of boot problems, what initially appears to be a non-bootable system may be fully recoverable. The best way to get practice recovering non-bootable systems is by using a non-production machine or a virtual machine and trying out various scenarios. I used Michael Jang's book, "Red Hat Certified Engineer Linux Study Guide", to review non-booting scenarios and rehearse how to recover from various situations. I would highly recommend getting comfortable with recovering non-booting systems because dealing with them in real life without any practice beforehand can be very stressful. Many of these problems are really easy to fix but only if you have had previous experience and know the steps to take.
When you are troubleshooting a non-booting system, there are certain things that you should be on the alert for. For example, an error in /boot/grub/grub.conf, /etc/fstab, or /etc/inittab can cause the system to not boot properly; so can an overwritten boot sector. In going through the process of troubleshooting with the RHEL rescue environment, I'll point out some things that may be of help in these situations.
Getting started
First, if you can't get the system booted by normal means, check things like the order of boot devices in the BIOS just to make sure you're reading the right drive. You should also ensure that the drive is being recognized. Try to pinpoint where in the boot sequence the process is failing; take note of any unusual activity or messages. Remember that the boot process runs in this order:
1. BIOS
2. MBR
3. GRUB - /etc/grub/grub.conf
4. Kernel
5. INIT - /etc/inittab
* /etc/rc.d/rc.sysinit
* /etc/fstab
6. Runlevel
Pay close attention to any configuration files, as they are likely places for errors.
OK - it's time for the boot CD. The Linux rescue environment will load a minimal system with only a small subset of commands, but it should be enough for our purposes.
Rescue
After restarting the machine with the CD or DVD in the drive, you will need to type linux rescue at the boot prompt instead of hitting 'Enter' for a normal install.
The next screen will ask us to choose a language.
The screen after that will ask for our keyboard layout.
At this point, we are asked if we would like to configure our network interfaces. If you need access to an NFS install tree or some other external resource, you should select this option. It will allow you to configure your network interfaces with IPv4 and/or IPv6; you can also choose manual or dynamic configuration of your IP address and subnet mask. If you think that you might need to reinstall a corrupt package and have no network install tree, you will still be able to access the RPMs on the CD or DVD. You will need to mount the CD or DVD on the rescue filesystem to do this.
The next stage of the rescue environment will scan your disks and attempt to mount your partitions under /mnt/sysimage. Note that you have the option to mount read/write, read-only, or to skip and not mount or attempt to mount any partition. Here is where you ask yourself "what do I need to do?" Only you know if you've experienced a drive crash and possible data loss. Do you need to check or repair your partitions? If so, you'll need to skip mounting - running fsck on mounted partitions is a bad idea.
If you choose to mount your partitions, you'll see the following screen.
At this point, you can get started with troubleshooting and checking for errors. Good places to start looking for problems depend on your particular situation. System logs are always an excellent place if you are unsure of the exact nature of your problem. Again, /boot/grub/grub.conf, /etc/fstab, and /etc/inittab are the most common places for errors that will prevent normal system startup.
If you get this next screen as a result of trying to mount your system partitions, it is likely that you have an error in the /etc/fstab file and a partition is being incorrectly specified as your root device. You can check that your partitions are correctly labeled and listed in /etc/fstab by writing down your /etc/fstab file and running e2label /dev/partition over your partitions. If you're not sure what they are, you can get a listing by running fdisk -l.
Removing a GRUB Bootloader Password
This often comes up when you need to append an option to the GRUB boot stanza - at which point you find out that the last sysadmin neglected to leave us that information. Or we need to be able to boot into a different runlevel or emergency mode for troubleshooting - and a GRUB password is preventing us from doing this. Some system administrators think that a GRUB password is going to save them from unauthorized access; unfortunately, this is not true. If some one can touch your console, they can acquire complete access to your system and data.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Run vi /mnt/sysimage/boot/grub/grub.conf
6. Comment out or remove the line containing the password hash.
7. Reboot.
As they say, "physical access equals root access."
Reinstalling RPMs from the CD or DVD
When you are troubleshooting, and you suspect that some critical files were altered or a package became corrupted, the following command can be used to verify that the file is still the same as it was in the RPM: rpm -Vf /path/file. To verify if a specific RPM that was downloaded or is on removable media is intact, use rpm -Vp packagename.rpm. Recall that you can access the RPMs on the install CD or DVD for reinstallation, although you'll need to mount that CD or DVD manually.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Mount the CD or DVD by typing mount /dev/cdrom /mnt/source.
6. Select the RPM and reinstall it with rpm --replacepkgs -ivh /mnt/source/Server/rpmfile.rpm --root /mnt/sysimage
7. Reboot.
Fixing a corrupted Master Boot Record
This will restore only the master boot record; note that the partition table will not be recovered by this sequence if it is damaged.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Type chroot /mnt/sysimage to enter your Linux environment.
6. Type grub-install /dev/sda or grub-install /dev/hda (whatever is appropriate for your hardware.)
7. Reboot.
Backing up and resoring the MBR and partition table
It's a good idea to save a known-good copy of your MBR and partition table before problems arise; the former may be easy to recreate with GRUB, but the latter can be quite a challenge. To save a copy of both, run the following command:
dd if=/dev/sda of=mbr-parttable bs=512 count=1
This will create a file called "mbr-parttable" which should be saved off-system.
To restore the MBR and the partition table which had been saved with the previous command, run the following (assuming that the file you created is in the current directory):
dd if=mbr-parttable of=/dev/sda bs=512 count=1
Things to keep in mind
When in rescue mode, it's vital to stay focused on what you are doing. Think critically and don't do things haphazardly; pay attention to any errors you see. I personally keep paper notes of any problems that I notice, and document everything I do in detail. Proceeding from there depends on my best estimate of the problem: I may list my partitions and write them down if I believe that's where the problem is. I list the files that are involved with the process or problem that occurred and mark them off one by one in a organized manner as I go down the list. If you're testing out possible solutions, try only one thing at a time and if it is not the correct solution, revert to the previous state before going on to try the next fix. Make copies of files before you edit them. Ask yourself questions about why you would see the problem produce the error that it did. Read logs and see if you can deduce why the error occurred in the first place. A temporary patch may cost you more downtime at an even more inconvenient time later.
Standard Troubleshooting Model
1. Define the problem
2. Gather information and data
3. Form a hypothesis
4. Try possible solutions
5. Analyze data
6. Draw conclusions
7. Redefine the problem based on results
8. Repeat as necessary
All these procedures should work exactly the same way with Fedora and CentOS. As with any rescue environment, it provides a set of useful tools; it also allows you to configure your network interfaces. This can be helpful if you have an NFS install tree to mount, or if you have an RPM that was corrupted and needs to be replaced. There are LVM tools for manipulating Logical Volumes, "fdisk" for partitioning devices, and a number of other tools making up a small but capable toolkit.
The Red Hat rescue environment provided by the first CD or DVD can really come in handy in many situations. With it you can solve boot problems, bypass forgotten GRUB bootloader passwords, replace corrupted RPMs, and more. I will go over some of the most important and common issues. I also suggest reviewing a password recovery article written by Suramya Tomar (http://linuxgazette.net/107/tomar.html) that deals with recovering lost root passwords in a variety of ways for different distributions. I will not be covering that here since his article is a very good resource for those problems.
Start by getting familiar with using GRUB and booting into single user mode. After you learn to overcome and repair a variety of boot problems, what initially appears to be a non-bootable system may be fully recoverable. The best way to get practice recovering non-bootable systems is by using a non-production machine or a virtual machine and trying out various scenarios. I used Michael Jang's book, "Red Hat Certified Engineer Linux Study Guide", to review non-booting scenarios and rehearse how to recover from various situations. I would highly recommend getting comfortable with recovering non-booting systems because dealing with them in real life without any practice beforehand can be very stressful. Many of these problems are really easy to fix but only if you have had previous experience and know the steps to take.
When you are troubleshooting a non-booting system, there are certain things that you should be on the alert for. For example, an error in /boot/grub/grub.conf, /etc/fstab, or /etc/inittab can cause the system to not boot properly; so can an overwritten boot sector. In going through the process of troubleshooting with the RHEL rescue environment, I'll point out some things that may be of help in these situations.
Getting started
First, if you can't get the system booted by normal means, check things like the order of boot devices in the BIOS just to make sure you're reading the right drive. You should also ensure that the drive is being recognized. Try to pinpoint where in the boot sequence the process is failing; take note of any unusual activity or messages. Remember that the boot process runs in this order:
1. BIOS
2. MBR
3. GRUB - /etc/grub/grub.conf
4. Kernel
5. INIT - /etc/inittab
* /etc/rc.d/rc.sysinit
* /etc/fstab
6. Runlevel
Pay close attention to any configuration files, as they are likely places for errors.
OK - it's time for the boot CD. The Linux rescue environment will load a minimal system with only a small subset of commands, but it should be enough for our purposes.
Rescue
After restarting the machine with the CD or DVD in the drive, you will need to type linux rescue at the boot prompt instead of hitting 'Enter' for a normal install.
The next screen will ask us to choose a language.
The screen after that will ask for our keyboard layout.
At this point, we are asked if we would like to configure our network interfaces. If you need access to an NFS install tree or some other external resource, you should select this option. It will allow you to configure your network interfaces with IPv4 and/or IPv6; you can also choose manual or dynamic configuration of your IP address and subnet mask. If you think that you might need to reinstall a corrupt package and have no network install tree, you will still be able to access the RPMs on the CD or DVD. You will need to mount the CD or DVD on the rescue filesystem to do this.
The next stage of the rescue environment will scan your disks and attempt to mount your partitions under /mnt/sysimage. Note that you have the option to mount read/write, read-only, or to skip and not mount or attempt to mount any partition. Here is where you ask yourself "what do I need to do?" Only you know if you've experienced a drive crash and possible data loss. Do you need to check or repair your partitions? If so, you'll need to skip mounting - running fsck on mounted partitions is a bad idea.
If you choose to mount your partitions, you'll see the following screen.
At this point, you can get started with troubleshooting and checking for errors. Good places to start looking for problems depend on your particular situation. System logs are always an excellent place if you are unsure of the exact nature of your problem. Again, /boot/grub/grub.conf, /etc/fstab, and /etc/inittab are the most common places for errors that will prevent normal system startup.
If you get this next screen as a result of trying to mount your system partitions, it is likely that you have an error in the /etc/fstab file and a partition is being incorrectly specified as your root device. You can check that your partitions are correctly labeled and listed in /etc/fstab by writing down your /etc/fstab file and running e2label /dev/partition over your partitions. If you're not sure what they are, you can get a listing by running fdisk -l
Removing a GRUB Bootloader Password
This often comes up when you need to append an option to the GRUB boot stanza - at which point you find out that the last sysadmin neglected to leave us that information. Or we need to be able to boot into a different runlevel or emergency mode for troubleshooting - and a GRUB password is preventing us from doing this. Some system administrators think that a GRUB password is going to save them from unauthorized access; unfortunately, this is not true. If some one can touch your console, they can acquire complete access to your system and data.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Run vi /mnt/sysimage/boot/grub/grub.conf
6. Comment out or remove the line containing the password hash.
7. Reboot.
As they say, "physical access equals root access."
Reinstalling RPMs from the CD or DVD
When you are troubleshooting, and you suspect that some critical files were altered or a package became corrupted, the following command can be used to verify that the file is still the same as it was in the RPM: rpm -Vf /path/file. To verify if a specific RPM that was downloaded or is on removable media is intact, use rpm -Vp packagename.rpm. Recall that you can access the RPMs on the install CD or DVD for reinstallation, although you'll need to mount that CD or DVD manually.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Mount the CD or DVD by typing mount /dev/cdrom /mnt/source.
6. Select the RPM and reinstall it with rpm --replacepkgs -ivh /mnt/source/Server/rpmfile.rpm --root /mnt/sysimage
7. Reboot.
Fixing a corrupted Master Boot Record
This will restore only the master boot record; note that the partition table will not be recovered by this sequence if it is damaged.
1. Boot from the RHEL boot CD and at the boot prompt type: linux rescue.
2. Select your language and keyboard layout.
3. Choose whether or not to start networking interfaces.
4. Mount your partitions read/write.
5. Type chroot /mnt/sysimage to enter your Linux environment.
6. Type grub-install /dev/sda or grub-install /dev/hda (whatever is appropriate for your hardware.)
7. Reboot.
Backing up and resoring the MBR and partition table
It's a good idea to save a known-good copy of your MBR and partition table before problems arise; the former may be easy to recreate with GRUB, but the latter can be quite a challenge. To save a copy of both, run the following command:
dd if=/dev/sda of=mbr-parttable bs=512 count=1
This will create a file called "mbr-parttable" which should be saved off-system.
To restore the MBR and the partition table which had been saved with the previous command, run the following (assuming that the file you created is in the current directory):
dd if=mbr-parttable of=/dev/sda bs=512 count=1
Things to keep in mind
When in rescue mode, it's vital to stay focused on what you are doing. Think critically and don't do things haphazardly; pay attention to any errors you see. I personally keep paper notes of any problems that I notice, and document everything I do in detail. Proceeding from there depends on my best estimate of the problem: I may list my partitions and write them down if I believe that's where the problem is. I list the files that are involved with the process or problem that occurred and mark them off one by one in a organized manner as I go down the list. If you're testing out possible solutions, try only one thing at a time and if it is not the correct solution, revert to the previous state before going on to try the next fix. Make copies of files before you edit them. Ask yourself questions about why you would see the problem produce the error that it did. Read logs and see if you can deduce why the error occurred in the first place. A temporary patch may cost you more downtime at an even more inconvenient time later.
Standard Troubleshooting Model
1. Define the problem
2. Gather information and data
3. Form a hypothesis
4. Try possible solutions
5. Analyze data
6. Draw conclusions
7. Redefine the problem based on results
8. Repeat as necessary
Tuesday, February 3, 2009
How to Recover your Ubuntu password
First of all, if you forget your admin Ubuntu password, you will need physical access to the PC in order to recover your password.
Usually Ubuntu install in the grub menu this option:
title Ubuntu 8.10, kernel 2.6.27-7-generic (recovery mode)
uuid 393ac665-f5c2-488d-b601-b59ba1d5675b
kernel /boot/vmlinuz-2.6.27-7-generic root=UUID=393ac665-f5c2-488d-b601-b59ba1d5675b ro single
initrd /boot/initrd.img-2.6.27-7-generic
That text is part of my /boot/grub/menu.lst of my Ubuntu Linux, so first go to the easiest way to recover the password in Ubuntu.
1. Reboot your system
2. When it is starting, press ESC to get the grub menu
3. Select the option that says (recovery mode)
4. In the next dialog select the root prompt, and get access to a console shell
5. type
passwd admin-username
Remember to change the bold text by your username in Ubuntu, the one that has admin rights.
6. reboot your system, and you are done!
Now Going to the not so easy way, in case you do not have the recovery mode option.
Follow the same procedure as above until step 2.
3. Press e to edit
4. Select the line that starts with kernel...
5. Press e again.
6. Go to the end of the line and add single
7. Press ENTER
8. Press b to boot that kernel, with the single option.
9. Change password, and reboot.
Usually Ubuntu install in the grub menu this option:
title Ubuntu 8.10, kernel 2.6.27-7-generic (recovery mode)
uuid 393ac665-f5c2-488d-b601-b59ba1d5675b
kernel /boot/vmlinuz-2.6.27-7-generic root=UUID=393ac665-f5c2-488d-b601-b59ba1d5675b ro single
initrd /boot/initrd.img-2.6.27-7-generic
That text is part of my /boot/grub/menu.lst of my Ubuntu Linux, so first go to the easiest way to recover the password in Ubuntu.
1. Reboot your system
2. When it is starting, press ESC to get the grub menu
3. Select the option that says (recovery mode)
4. In the next dialog select the root prompt, and get access to a console shell
5. type
passwd admin-username
Remember to change the bold text by your username in Ubuntu, the one that has admin rights.
6. reboot your system, and you are done!
Now Going to the not so easy way, in case you do not have the recovery mode option.
Follow the same procedure as above until step 2.
3. Press e to edit
4. Select the line that starts with kernel...
5. Press e again.
6. Go to the end of the line and add single
7. Press ENTER
8. Press b to boot that kernel, with the single option.
9. Change password, and reboot.
Monday, February 2, 2009
PWCK - Check Integrity of /etc/passwd
PWCK will verifies:
1. The correct number of fields.
2. A unique username
3. A valid user and group identifier
4. A valid primary group
5. A valid home directory
6. A valid of login shell
1. The correct number of fields.
2. A unique username
3. A valid user and group identifier
4. A valid primary group
5. A valid home directory
6. A valid of login shell
Sunday, February 1, 2009
Configure Sensible Security for Apache
1. Using a dedicated user and group for Apache
2. Using a safe directory structure
3. Using appropriate file and directory permissions
4. Using directory index file
5. Disable default access
6. Disable user overrides
2. Using a safe directory structure
3. Using appropriate file and directory permissions
4. Using directory index file
5. Disable default access
6. Disable user overrides
Subscribe to:
Comments (Atom)
