Yesterday I introduced SELinux and explained how to begin using it in 'Permissive' mode without affecting any existing processes on a server. Today I'm going to cover how to interpret a violation in the logs and how to find more information which might help to resolve the issue and allow you to run in 'Enforcing' mode. Enforcing mode is where the real security comes into play and mandatory access controls are enforced.
As I showed in my previous post, a violation will show up in /var/log/messages like the following:
Dec 26 07:30:26 f7-laptop setroubleshoot: SELinux is preventing the /bin/vi from using potentially mislabeled files (ftp). For complete SELinux messages. run sealert -l 0621a8c3-b182-49cf-9116-c78a9dd52199
This message indicates that when executing 'vipw' it does not get access to my personalized vi config file (.exrc). This warning is valid since no system process should be accessing a file not labeled as a system file. To determine the context of a file, use the '-Z' flag with ls:
$ ls -Z ~/.exrc
-rw-r--r-- josh josh user_u:object_r:user_home_t /home/josh/.exrc
You can see the context is 'user_u:object_r:user_home_t'. This is clearly not a system file and that is why SELinux is preventing vipw from accessing it. To see more information about this error, run the 'sealert' command above:
sealert -l 0621a8c3-b182-49cf-9116-c78a9dd52199
Now, to include only the relevant portions, see the following:
Detailed Description
SELinux has denied /bin/vi access to potentially mislabeled file(s) (ftp).
This means that SELinux will not allow /bin/vi to use these files. It is
common for users to edit files in their home directory or tmp directories
and then move (mv) them to system directories. The problem is that the
files end up with the wrong file context which confined applications are not
allowed to access.
Allowing Access
If you want /bin/vi to access this files, you need to relabel them using
restorecon -v ftp. You might want to relabel the entire directory using
restorecon -R -v .
Additional Information
Source Context user_u:system_r:sysadm_passwd_t
Target Context user_u:object_r:user_home_t
Target Objects ftp [ dir ]
Affected RPM Packages vim-minimal-7.1.12-1.fc7 [application]
Policy RPM selinux-policy-2.6.4-46.fc7
Selinux Enabled True
Policy Type targeted
MLS Enabled True
Enforcing Mode Permissive
You can see from the above message that the process trying to access the file has a security context of 'user_u:system_r:sysadm_passwd_t' and it's fairly evident from this context that it's a system process related to authentication. Further up in the description you see the details of the violation and why it would refuse access.
If the file would have been a valid file for this process to access, and I wanted to grant that access, I could do so with the 'chcon' command:
chcon user_u:system_r:sysadm_passwd_t ~/.exrc
$ ls -Z !$
ls -Z ~/.exrc
-rw-r--r-- josh josh user_u:system_r:sysadm_passwd_t /home/josh/.exrc
This action would have failed if SELinux was in enforcing mode since it would not make sense to assign a sysadm_passwd_t context to a file in this location. This is a great example of how SELinux helps to keep your system secure without letting you mis-label files! This example also show how SELinux prevents mis-steps while giving you the opportunity to troubleshoot and find out what the real problem is.
Another great SELinux resource is the Unofficial SELinux FAQ.
Thursday, December 27, 2007
Wednesday, December 26, 2007
SELinux for all?
I recently migrated my mail server from a Gentoo Linux host to a Fedora 7 host and decided to use SELinux to improve my security posture. This is a big deal and should provide a greater level of security for my mail server, provided I can configure the security policies correctly.
SELinux was developed with the NSA and released under the GPL to provide a method of Mandatory Access Control for Linux.
The great benefit of using SELinux is that processes are prevented from accessing files that are not defined as belonging to, or associated with that process. This is a great thing! If a daemon or process were to be compromised, it would be restricted to the specific files and resources configured in the SELinux policy. Any violations are logged by the setroubleshoot daemon in the /var/log/messages syslog file and allow the user to review in order to allow or continue denial of the access attempt(s).
Enabling SELinux is very simple upon installation of Fedora or Red Hat Linux and is prompted during install. I do not recommend enabling on an OS that is in production and would only recommend enabling SELinux on a recent install or non-production host until you are very comfortable with it and have tuned your policies according to your production operation.
To get your feet wet, enable SELinux in permissive mode. This mode will allow all processes to run as if SELinux were off, but it will log any violations via auditd in syslog to allow you to tune your policies. You are prompted for this method upon install, or post-install, you could configure this via the following method:
1. use the setenforce command: setenforce permissive
usage: setenforce [ Enforcing | Permissive | 1 | 0 ]
2. edit the /etc/selinux/config file:
SELINUX=permissive
Also, be sure to remove any mention of selinux from the /boot/grub/grub.conf file if you enable SELinux, or provide the proper flags to enable it. This is also the best way to disable SELinux if you are so inclined. An example would be:
#/boot/grub/grub.conf
title Fedora 7 (2.6.22.1-41.fc7)
root (hd0,0)
kernel /vmlinuz-2.6.22.1-41.fc7 ro root=/dev/vg01/f7_root rhgb quiet selinux=0
initrd /initrd-2.6.22.1-41.fc7.img
Note that on the kernel line I have passed 'selinux=0' to the kernel which would then disable this feature.
After enabling SELinux, check syslog frequently (/var/log/messages) to look for policy violations and tune your system. A typical policy violation would look like the following:
Dec 26 08:12:50 f7-laptop setroubleshoot: SELinux is preventing the /bin/vi from using potentially mislabeled files (.exrc). For complete SELinux messages. run sealert -l 27ae2a46-19bb-47a8-b127-068a587e9494
In the above log entry, I used 'vipw' to access the /etc/passwd file and SELinux did not allow the 'vipw' binary to access my '.exrc' file (user customized file for VIM settings).
In short, SELinux can provide a GREAT measure of security to a seasoned administrator who is willing to take the time to learn how to use it. Use permissive mode and tune the policies to fit your particular environment. I do not know of anybody who uses SELinux in production or in a business due to the issues it seems to cause by lack of training and/or expertise in the configuration phase. Remember to disable SELinux and re-create the issue before bothering the application maintainer about any issues you may have.
SELinux was developed with the NSA and released under the GPL to provide a method of Mandatory Access Control for Linux.
The great benefit of using SELinux is that processes are prevented from accessing files that are not defined as belonging to, or associated with that process. This is a great thing! If a daemon or process were to be compromised, it would be restricted to the specific files and resources configured in the SELinux policy. Any violations are logged by the setroubleshoot daemon in the /var/log/messages syslog file and allow the user to review in order to allow or continue denial of the access attempt(s).
Enabling SELinux is very simple upon installation of Fedora or Red Hat Linux and is prompted during install. I do not recommend enabling on an OS that is in production and would only recommend enabling SELinux on a recent install or non-production host until you are very comfortable with it and have tuned your policies according to your production operation.
To get your feet wet, enable SELinux in permissive mode. This mode will allow all processes to run as if SELinux were off, but it will log any violations via auditd in syslog to allow you to tune your policies. You are prompted for this method upon install, or post-install, you could configure this via the following method:
1. use the setenforce command: setenforce permissive
usage: setenforce [ Enforcing | Permissive | 1 | 0 ]
2. edit the /etc/selinux/config file:
SELINUX=permissive
Also, be sure to remove any mention of selinux from the /boot/grub/grub.conf file if you enable SELinux, or provide the proper flags to enable it. This is also the best way to disable SELinux if you are so inclined. An example would be:
#/boot/grub/grub.conf
title Fedora 7 (2.6.22.1-41.fc7)
root (hd0,0)
kernel /vmlinuz-2.6.22.1-41.fc7 ro root=/dev/vg01/f7_root rhgb quiet selinux=0
initrd /initrd-2.6.22.1-41.fc7.img
Note that on the kernel line I have passed 'selinux=0' to the kernel which would then disable this feature.
After enabling SELinux, check syslog frequently (/var/log/messages) to look for policy violations and tune your system. A typical policy violation would look like the following:
Dec 26 08:12:50 f7-laptop setroubleshoot: SELinux is preventing the /bin/vi from using potentially mislabeled files (.exrc). For complete SELinux messages. run sealert -l 27ae2a46-19bb-47a8-b127-068a587e9494
In the above log entry, I used 'vipw' to access the /etc/passwd file and SELinux did not allow the 'vipw' binary to access my '.exrc' file (user customized file for VIM settings).
In short, SELinux can provide a GREAT measure of security to a seasoned administrator who is willing to take the time to learn how to use it. Use permissive mode and tune the policies to fit your particular environment. I do not know of anybody who uses SELinux in production or in a business due to the issues it seems to cause by lack of training and/or expertise in the configuration phase. Remember to disable SELinux and re-create the issue before bothering the application maintainer about any issues you may have.
Thursday, October 04, 2007
Linux Driver Support
One of the biggest complaints of Linux users is a lack of hardware support. While Linux supports more hardware than any other operating system, it doesn't support all of the hardware that Windows supports since manufacturers create drivers for Windows by default.
A new project created by Greg Kroah-Hartman aims to create Linux drivers for vendors -- free of charge! This is revolutionary and should pave the way for increased driver support in all areas of the hardware world. It seems that there is a great demand for this service, and great participation by developers as well.
A new project created by Greg Kroah-Hartman aims to create Linux drivers for vendors -- free of charge! This is revolutionary and should pave the way for increased driver support in all areas of the hardware world. It seems that there is a great demand for this service, and great participation by developers as well.
Linux in the New York Times
There is a great article in the technology section of the New York Times which talks about Linux and Ubuntu specifically. This is great coverage!
Sunday, March 04, 2007
Upgrading Mediawiki from 1.6.5 to 1.9.2
I have been running Mediawiki 1.6.5 on a Gentoo server for quite some time. Today I decided that I would perform the upgrade to 1.9.2 -- which has been installed for a while without being configured for use.
The first step that I took was to update my httpd.conf to point to the new wiki location:
#Alias /mediawiki "/usr/share/webapps/mediawiki/1.6.5/htdocs"
Alias /mediawiki "/usr/share/webapps/mediawiki/1.9.2/htdocs"
The next step was to test it out. If I had a large user base or any outside users, I would have enabled the second one without disabling the first and locked my database. I dont have any users other than myself, so I did not worry about this step.
I navigated to the URL of my installation and I received an error about the config directory not being writable. I realized here that I needed to copy by LocalSettings.php from the old installation to the new version.
cp /usr/share/webapps/mediawiki/1.6.5/htdocs/LocalSettings.php /usr/share/webapps/mediawiki/1.9.2/htdocs
After copying the settings file, I visited the URL again and this time I was able to see the content. Now on to the testing phase.
To test my new wiki version, I first navigated around to make sure I could see all of the content -- this worked flawlessly. The next test was to add some content.
After adding some content, I received an internal error that suggested that I add the following line to my LocalSettings.php:
$wgShowExceptionDetails = true;
I added the above line to the end of my LocalSettings.php and I was rewarded with the error message below:
Utf8Case.ser is missing, please run "make" in the serialized directory
Backtrace:
#0 /var/www/fuag.com/htdocs/mediawiki/languages/Language.php(972): Language::getCaseMaps()
#1 /var/www/fuag.com/htdocs/mediawiki/includes/SearchUpdate.php(51): Language->stripForSearch('This will be an...')
#2 /var/www/fuag.com/htdocs/mediawiki/includes/Wiki.php(295): SearchUpdate->doUpdate()
#3 /var/www/fuag.com/htdocs/mediawiki/includes/Wiki.php(277): MediaWiki->doUpdates(Array)
#4 /var/www/fuag.com/htdocs/mediawiki/index.php(49): MediaWiki->finalCleanup(Array, Object(LoadBalancer), Object(OutputPage))
#5 {main}
This was not very clear to me, as there was not serialize directory in my installation. I did some looking around and came up with the following fix, specific to Gentoo:
1. Download new mediawiki from: http://download.wikimedia.org/mediawiki/1.9/mediawiki-1.9.3.tar.gz
curl -C - -O 'http://download.wikimedia.org/mediawiki/1.9/mediawiki-1.9.3.tar.gz'
2. Un-tar in /tmp and copy the serialized directory from the downloaded version to my local copy:
tar xzf mediawiki-1.9.3.tar.gz
cp -a serialized/ /usr/share/webapps/mediawiki/1.9.2/htdocs/
3. Run make in the new directory
make
4. Change permissions on the new directory to match the rest of my stuff in htdocs:
chown -R root:web_devs serialized/
5. Restart apache and it should now work!
Don't forget to comment out the added line in LocalSettings.php so that any end-users don't see your specific error messages.
Now I can remove all of the in-between versions that I have not been using.
The first step that I took was to update my httpd.conf to point to the new wiki location:
#Alias /mediawiki "/usr/share/webapps/mediawiki/1.6.5/htdocs"
Alias /mediawiki "/usr/share/webapps/mediawiki/1.9.2/htdocs"
The next step was to test it out. If I had a large user base or any outside users, I would have enabled the second one without disabling the first and locked my database. I dont have any users other than myself, so I did not worry about this step.
I navigated to the URL of my installation and I received an error about the config directory not being writable. I realized here that I needed to copy by LocalSettings.php from the old installation to the new version.
cp /usr/share/webapps/mediawiki/1.6.5/htdocs/LocalSettings.php /usr/share/webapps/mediawiki/1.9.2/htdocs
After copying the settings file, I visited the URL again and this time I was able to see the content. Now on to the testing phase.
To test my new wiki version, I first navigated around to make sure I could see all of the content -- this worked flawlessly. The next test was to add some content.
After adding some content, I received an internal error that suggested that I add the following line to my LocalSettings.php:
$wgShowExceptionDetails = true;
I added the above line to the end of my LocalSettings.php and I was rewarded with the error message below:
Utf8Case.ser is missing, please run "make" in the serialized directory
Backtrace:
#0 /var/www/fuag.com/htdocs/mediawiki/languages/Language.php(972): Language::getCaseMaps()
#1 /var/www/fuag.com/htdocs/mediawiki/includes/SearchUpdate.php(51): Language->stripForSearch('This will be an...')
#2 /var/www/fuag.com/htdocs/mediawiki/includes/Wiki.php(295): SearchUpdate->doUpdate()
#3 /var/www/fuag.com/htdocs/mediawiki/includes/Wiki.php(277): MediaWiki->doUpdates(Array)
#4 /var/www/fuag.com/htdocs/mediawiki/index.php(49): MediaWiki->finalCleanup(Array, Object(LoadBalancer), Object(OutputPage))
#5 {main}
This was not very clear to me, as there was not serialize directory in my installation. I did some looking around and came up with the following fix, specific to Gentoo:
1. Download new mediawiki from: http://download.wikimedia.org/mediawiki/1.9/mediawiki-1.9.3.tar.gz
curl -C - -O 'http://download.wikimedia.org/mediawiki/1.9/mediawiki-1.9.3.tar.gz'
2. Un-tar in /tmp and copy the serialized directory from the downloaded version to my local copy:
tar xzf mediawiki-1.9.3.tar.gz
cp -a serialized/ /usr/share/webapps/mediawiki/1.9.2/htdocs/
3. Run make in the new directory
make
4. Change permissions on the new directory to match the rest of my stuff in htdocs:
chown -R root:web_devs serialized/
5. Restart apache and it should now work!
Don't forget to comment out the added line in LocalSettings.php so that any end-users don't see your specific error messages.
Now I can remove all of the in-between versions that I have not been using.
primary mediawiki # ll
total 32
drwxrwsr-x 6 root web_devs 4096 Mar 4 15:14 1.6.5
drwxr-xr-x 7 root web_devs 4096 May 23 2006 1.6.6
drwxr-xr-x 7 root web_devs 4096 Jun 8 2006 1.6.7
drwxr-xr-x 7 root web_devs 4096 Sep 3 09:13 1.6.8
drwxr-xr-x 7 root web_devs 4096 Nov 28 23:45 1.7.1
drwxr-xr-x 7 root web_devs 4096 Jan 13 21:15 1.8.2
drwxr-xr-x 7 root web_devs 4096 Jan 19 22:10 1.9.0
drwxr-xr-x 6 root web_devs 4096 Mar 4 16:07 1.9.2
primary mediawiki #
Fedora Core 7 -- Going free?
Fedora Core is one of the most popular free distributions of Linux and is the community version of Redhat Enterprise Linux.
With the pending release of Fedora Core 7, the Fedora project is attempting to merge the two primary repositories; Fedora Core and Fedora Extras. With the merging of these two repositories, the Fedora project is also considering requiring all packages in the repository to be "Free Software". (re: link.)
This change would benefit everybody involved with the Fedora Project. Users of Fedora would know that license restrictions were similar throughout the software available and developers would have an easier time integrating existing software with other packages provided.
Fedora has had a lot of negativity lately around packages not working well together and updates breaking fully functional systems. This change for Fedora Core 7 might improve much of the mess that has been made.
With the pending release of Fedora Core 7, the Fedora project is attempting to merge the two primary repositories; Fedora Core and Fedora Extras. With the merging of these two repositories, the Fedora project is also considering requiring all packages in the repository to be "Free Software". (re: link.)
This change would benefit everybody involved with the Fedora Project. Users of Fedora would know that license restrictions were similar throughout the software available and developers would have an easier time integrating existing software with other packages provided.
Fedora has had a lot of negativity lately around packages not working well together and updates breaking fully functional systems. This change for Fedora Core 7 might improve much of the mess that has been made.
rootkit defense -- not so fast
A recent demonstration at Black Hat DC by Joanna Rutkowska shows how hardware based rootkit defense may not be sufficient when facing an elite hacker. Rutkowska showed how the image of volatile memory as seen by the CPU can be different from the image in memory.
This is significant as it shows that monitoring at the hardware level is not fool-proof and defenders must use a combination of hardware and software monitoring.
Read the article.
Actual implementation of this attack does not seem very likely due to the complexity.
This is significant as it shows that monitoring at the hardware level is not fool-proof and defenders must use a combination of hardware and software monitoring.
Read the article.
Actual implementation of this attack does not seem very likely due to the complexity.
Saturday, March 03, 2007
Fun with OpenLDAP, nscd, Cyrus-Imap, and Bind
After updating a server this weekend, I restarted to verify that all services would come back up and that's where the fun started...
The first issue I noticed was that Apache would not start. Nothing, I would issue a restart command:
primary ~ # /etc/init.d/apache2 restart
and I get no output, just a new prompt. The only problem here is that nothing is listening on port 80 or 443 and there are no processes running owned by apache.
primary ~ # netstat -anp --inet | egrep '80|443'
primary ~ # ps -eaf | grep apache
Nothing...
From here, I notice that bind isn't running and my email is getting queued up in postfix and not being delivered to my Cyrus-IMAP server. I see a lot of messages like this:
Mar 2 14:53:43 primary master[15457]: process 15319 exited, signaled to death by 13
Mar 2 14:53:43 primary master[15457]: service imaps pid 15319 in READY state: terminated abnormally
Mar 2 14:53:43 primary master[15457]: process 15320 exited, signaled to death by 13
At this point, I'm at a loss as to what is wrong and I start checking config files -- although this doesn't make a lot of sense since I didn't change any config files...(I do it anyway).
After a few hours of troubleshooting, I've re-installed Apache, Cyrus, Bind and tried different versions of each. I ended up getting Bind to work after compiling it without thread support, although this is not a good thing, as it means something else is wrong. I'm getting pretty frustrated without a working IMAP server and beginning to reconsider my decision to go with Cyrus in the first place.
Well...to make a long story short, it turns out that a few days prior to the updates, I had disabled nscd on this host to see how my OpenLDAP server would stand up to the increased load resulting from no caching. This did not seem to cause any problems and I had made this change persistent. Anyway, after searching around on the web for a while I discovered that another person had a similar issue with Cyrus where it would not start and it was due to an LDAP server being unavailable.
It turns out that if nscd is not available when Cyrus starts, and a multi-threaded bind, and Apache with my configuration, and the system is using LDAP for authentication, then these applications will not startup and run normally.
Big LESSON LEARNED for me -- always document changes, even at home on home servers, and make sure you restart the system after making big changes to verify that they don't affect other daemons. I learn this lesson about once a month on a new server, maybe this time it will persist.
The first issue I noticed was that Apache would not start. Nothing, I would issue a restart command:
primary ~ # /etc/init.d/apache2 restart
and I get no output, just a new prompt. The only problem here is that nothing is listening on port 80 or 443 and there are no processes running owned by apache.
primary ~ # netstat -anp --inet | egrep '80|443'
primary ~ # ps -eaf | grep apache
Nothing...
From here, I notice that bind isn't running and my email is getting queued up in postfix and not being delivered to my Cyrus-IMAP server. I see a lot of messages like this:
master[17957]: process 25160 exited, signaled to death by 13
...and...
Mar 2 14:53:43 primary master[15457]: process 15228 exited, signaled to death by 13
Mar 2 14:53:43 primary master[15457]: service imaps pid 15228 in READY state: terminated abnormally
Mar 2 14:53:43 primary master[15457]: process 15229 exited, signaled to death by 13
Mar 2 14:53:43 primary master[15457]: service imaps pid 15229 in READY state: terminated abnormally
Mar 2 14:53:43 primary master[15457]: process 15230 exited, signaled to death by 13
...and...Mar 2 14:53:43 primary master[15457]: service lmtpunix pid 15318 in READY state: terminated abnormally
Mar 2 14:53:43 primary master[15457]: process 15319 exited, signaled to death by 13
Mar 2 14:53:43 primary master[15457]: service imaps pid 15319 in READY state: terminated abnormally
Mar 2 14:53:43 primary master[15457]: process 15320 exited, signaled to death by 13
At this point, I'm at a loss as to what is wrong and I start checking config files -- although this doesn't make a lot of sense since I didn't change any config files...(I do it anyway).
After a few hours of troubleshooting, I've re-installed Apache, Cyrus, Bind and tried different versions of each. I ended up getting Bind to work after compiling it without thread support, although this is not a good thing, as it means something else is wrong. I'm getting pretty frustrated without a working IMAP server and beginning to reconsider my decision to go with Cyrus in the first place.
Well...to make a long story short, it turns out that a few days prior to the updates, I had disabled nscd on this host to see how my OpenLDAP server would stand up to the increased load resulting from no caching. This did not seem to cause any problems and I had made this change persistent. Anyway, after searching around on the web for a while I discovered that another person had a similar issue with Cyrus where it would not start and it was due to an LDAP server being unavailable.
It turns out that if nscd is not available when Cyrus starts, and a multi-threaded bind, and Apache with my configuration, and the system is using LDAP for authentication, then these applications will not startup and run normally.
Big LESSON LEARNED for me -- always document changes, even at home on home servers, and make sure you restart the system after making big changes to verify that they don't affect other daemons. I learn this lesson about once a month on a new server, maybe this time it will persist.
Wednesday, February 21, 2007
Red Hat Enterprise Linux 5 Beta 2
I recently downloaded the latest beta for RHEL 5 and had a chance to test it out a little. Redhat is moving away from registration keys and is now using "installation numbers" which resemble MS Activation keys. These installation numbers are designed to tie a specific server/installation to a specific Redhat channel to provide a specific set of packages. I can see this as a way to control incoming revenue for Redhat and charge different prices for different channels in much the same way they are doing it now with the AS vs. ES channels.
I was able to test virtualization support included with RHEL 5 which includes Xen 3. The management interface makes it very easy to provision a new virtual machine and monitor resource usage on a host. The one disappointment that I had was that I was not able to use the xm command to get a console to the virtual machine after startup. I could list the running virtual machine and it showed it as "blocked", but it was actually waiting for a graphical login. For some reason there weren't any ttys available for login. I don't have a lot of experience with Xen so I'll have to find a way around this issue.
Anyone out there now the answer to this?
I was able to test virtualization support included with RHEL 5 which includes Xen 3. The management interface makes it very easy to provision a new virtual machine and monitor resource usage on a host. The one disappointment that I had was that I was not able to use the xm command to get a console to the virtual machine after startup. I could list the running virtual machine and it showed it as "blocked", but it was actually waiting for a graphical login. For some reason there weren't any ttys available for login. I don't have a lot of experience with Xen so I'll have to find a way around this issue.
Anyone out there now the answer to this?
Linux 0.1 Source Available
I was referred here by Digg.com earlier today, but the Linux kernel version 0.1 is available for download from kernel.org:
Download
They say it's around 10,000 lines of code so it wouldn't be as daunting to read through and get familiar with as the latest kernel.
I downloaded the source and took a look at the filesystem code to find the following listing of files:
That's an incredibly small number of files compared to the current kernel which has many filesystems! Also, look at the dates on these files. I'm considering creating a filesystem of my own so this find is a goldmine and will provide me with some great resources without having to dig through the current code and the numerous filesystems that come with it.
Download
They say it's around 10,000 lines of code so it wouldn't be as daunting to read through and get familiar with as the latest kernel.
I downloaded the source and took a look at the filesystem code to find the following listing of files:
lu003 linux # pwd
/root/kernel-0.1/linux
lu003 linux # ll fs/
total 108
-rw-r--r-- 1 12041 12005 4735 Sep 17 1991 Makefile
-rw-r--r-- 1 12041 12005 3884 Sep 9 1991 bitmap.c
-rw-r--r-- 1 12041 12005 1786 Sep 13 1991 block_dev.c
-rw-r--r-- 1 12041 12005 6162 Sep 17 1991 buffer.c
-rw-r--r-- 1 12041 12005 1269 Sep 8 1991 char_dev.c
-rw-r--r-- 1 12041 12005 7535 Sep 13 1991 exec.c
-rw-r--r-- 1 12041 12005 1394 Aug 30 1991 fcntl.c
-rw-r--r-- 1 12041 12005 1788 Aug 30 1991 file_dev.c
-rw-r--r-- 1 12041 12005 56 Aug 18 1991 file_table.c
-rw-r--r-- 1 12041 12005 5917 Sep 9 1991 inode.c
-rw-r--r-- 1 12041 12005 935 Aug 30 1991 ioctl.c
-rw-r--r-- 1 12041 12005 14493 Sep 12 1991 namei.c
-rw-r--r-- 1 12041 12005 3846 Sep 8 1991 open.c
-rw-r--r-- 1 12041 12005 1973 Sep 13 1991 pipe.c
-rw-r--r-- 1 12041 12005 2693 Sep 13 1991 read_write.c
-rw-r--r-- 1 12041 12005 1134 Sep 11 1991 stat.c
-rw-r--r-- 1 12041 12005 2421 Sep 17 1991 super.c
-rw-r--r-- 1 12041 12005 1084 Sep 7 1991 truncate.c
-rw-r--r-- 1 12041 12005 4186 Sep 8 1991 tty_ioctl.c
lu003 linux #
That's an incredibly small number of files compared to the current kernel which has many filesystems! Also, look at the dates on these files. I'm considering creating a filesystem of my own so this find is a goldmine and will provide me with some great resources without having to dig through the current code and the numerous filesystems that come with it.
Monday, February 19, 2007
Commodity Hard Disk Drive Failure Analysis
Engadget has an interesting article which details an analysis performed by Google.com on over 100,000 hard drives over a 9 month period. The study behind the article is great as it clears up some common myths in the hard drive world, specifically the effect of temperature on hard disk failure rate. There is a PDF attached to the article with the full study:
Engadget Article
Engadget Article
Trouble with Firefox 2.0.0.1 and Macromedia Flashplayer 9
Ever since I upgraded the flashplayer on my Windows XP SP2 laptop to version 9 it has not worked. I found that I had an extension that conflicted with the Flash player (not sure to what extent) and I had to remove that extension to get it to work.
Notice: AdBlock conflicts with Macromedia Flash 9 when using Mozilla Firefox 2.0.0.1 and I removed the appropriate directory in the extensions directory to resolve the issue.
My directory:
C:\Documents and Settings\%username%\Application Data\Mozilla\Firefox\Profiles\.default\extensions
My verification test is to visit http://www.adobe.com/ and watch for the video in the top section of the page. With the adblock extension installed, that video remained blank.
Notice: AdBlock conflicts with Macromedia Flash 9 when using Mozilla Firefox 2.0.0.1 and I removed the appropriate directory in the extensions directory to resolve the issue.
My directory:
C:\Documents and Settings\%username%\Application Data\Mozilla\Firefox\Profiles\
My verification test is to visit http://www.adobe.com/ and watch for the video in the top section of the page. With the adblock extension installed, that video remained blank.
Saturday, February 17, 2007
Gentoo: emerge broken [solved]
Ok, so the gcc missing in the profile error was where the problem was. I ended up restarting the host and things were back to normal on boot-up.
Gentoo: emerge broken continued
Ok, so I have discovered another clue in the puzzle here, when I execute 'emerge --info', I get the following output at the top:
# emerge --info
!!! No gcc found. You probably need to 'source /etc/profile'
!!! to update the environment of this terminal and possibly
!!! other terminals also.
I also see the following in the FEATURES line:
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
I had no idea that all features were included if not explicitly excluded, so I added this line to my /etc/make.conf:
FEATURES="-*"
Now I need to hunt down the problem with the missing gcc. I believe that is why portage is failing to update itself. I test this theory by removing the downloaded package and trying to run the same command again:
# rm /usr/portage/distfiles/portage-2.1.2.tar.bz2
# emerge portage -v
Calculating dependencies... done!
>>> Emerging (1 of 1) sys-apps/portage-2.1.2-r9 to /
#
I am not so confident in this theory anymore, as I would have expected portage to be downloaded again, but I am going to continue to resolve the issue with the missing gcc.
# emerge --info
!!! No gcc found. You probably need to 'source /etc/profile'
!!! to update the environment of this terminal and possibly
!!! other terminals also.
I also see the following in the FEATURES line:
FEATURES="autoconfig distlocks metadata-transfer sandbox sfperms strict"
I had no idea that all features were included if not explicitly excluded, so I added this line to my /etc/make.conf:
FEATURES="-*"
Now I need to hunt down the problem with the missing gcc. I believe that is why portage is failing to update itself. I test this theory by removing the downloaded package and trying to run the same command again:
# rm /usr/portage/distfiles/portage-2.1.2.tar.bz2
# emerge portage -v
Calculating dependencies... done!
>>> Emerging (1 of 1) sys-apps/portage-2.1.2-r9 to /
#
I am not so confident in this theory anymore, as I would have expected portage to be downloaded again, but I am going to continue to resolve the issue with the missing gcc.
Gentoo: emerge broken
The other day I was trying to update one of my servers which was also my local portage mirror when I received the following surprising output:
# emerge portage -pv
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-apps/portage-2.1.2-r9 [2.1.2] USE="-build -doc -epydoc (-selinux)" LINGUAS="-pl" 20 kB
Total: 1 package (1 upgrade), Size of downloads: 20 kB
# emerge portage -v
Calculating dependencies... done!
>>> Emerging (1 of 1) sys-apps/portage-2.1.2-r9 to /
#
So the server was reading the local portage but was unable to install any applications (or upgrade). This is an unusual issue and I have not encountered an issue like this in the 3 years that I have been using Gentoo. To resolve this issue, I am going to attempt to re-install portage from the latest snapshot.
The first step of restoring a corrupt portage install is to download the latest release from distfiles.gentoo.org.
# cd /tmp/ && wget http://distfiles.gentoo.org/distfiles/portage-2.1.2.tar.bz2
Un-tar the package to a safe location out of the way, possibly /tmp/portage_recover (as recommended by the Gentoo Handbook).
# mkdir /tmp/portage_recover && cd /tmp/portage_recover
# mv /tmp/portage-2.1.2.tar.bz2 /tmp/portage_recover
# tar xjf portage-2.1.2.tar.bz2
You will now have a directory structure like the following:
# ll
total 151
-rw-r--r-- 1 portage portage 133926 Jan 14 15:00 ChangeLog
-rw-r--r-- 1 portage portage 1444 Jan 13 13:01 DEVELOPING
-rw-r--r-- 1 portage portage 3934 Jan 14 12:43 NEWS
-rw-r--r-- 1 portage portage 2406 Dec 23 11:05 RELEASE-NOTES
-rw-r--r-- 1 portage portage 1022 Jan 10 22:12 TEST-NOTES
drwxr-xr-x 2 portage portage 2064 Jan 14 15:00 bin
drwxr-xr-x 2 portage portage 752 Oct 16 12:01 cnf
drwxr-xr-x 2 portage portage 368 Jan 13 23:00 man
drwxr-xr-x 4 portage portage 920 Jan 14 15:00 pym
drwxr-xr-x 4 portage portage 144 Aug 1 2006 src
drwxr-xr-x 6 portage portage 224 Jan 14 14:54 tests
Now the trick is to copy the appropriate binaries and scripts from this location to your system.
# cp -R pym bin /usr/lib/portage/
Unfortunately, this does not solve my problem:
# emerge portage -v
Calculating dependencies... done!
>>> Emerging (1 of 1) sys-apps/portage-2.1.2-r9 to /
#
So I am back to the troubleshooting board.
# emerge portage -pv
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild U ] sys-apps/portage-2.1.2-r9 [2.1.2] USE="-build -doc -epydoc (-selinux)" LINGUAS="-pl" 20 kB
Total: 1 package (1 upgrade), Size of downloads: 20 kB
# emerge portage -v
Calculating dependencies... done!
>>> Emerging (1 of 1) sys-apps/portage-2.1.2-r9 to /
#
So the server was reading the local portage but was unable to install any applications (or upgrade). This is an unusual issue and I have not encountered an issue like this in the 3 years that I have been using Gentoo. To resolve this issue, I am going to attempt to re-install portage from the latest snapshot.
The first step of restoring a corrupt portage install is to download the latest release from distfiles.gentoo.org.
# cd /tmp/ && wget http://distfiles.gentoo.org/distfiles/portage-2.1.2.tar.bz2
Un-tar the package to a safe location out of the way, possibly /tmp/portage_recover (as recommended by the Gentoo Handbook).
# mkdir /tmp/portage_recover && cd /tmp/portage_recover
# mv /tmp/portage-2.1.2.tar.bz2 /tmp/portage_recover
# tar xjf portage-2.1.2.tar.bz2
You will now have a directory structure like the following:
# ll
total 151
-rw-r--r-- 1 portage portage 133926 Jan 14 15:00 ChangeLog
-rw-r--r-- 1 portage portage 1444 Jan 13 13:01 DEVELOPING
-rw-r--r-- 1 portage portage 3934 Jan 14 12:43 NEWS
-rw-r--r-- 1 portage portage 2406 Dec 23 11:05 RELEASE-NOTES
-rw-r--r-- 1 portage portage 1022 Jan 10 22:12 TEST-NOTES
drwxr-xr-x 2 portage portage 2064 Jan 14 15:00 bin
drwxr-xr-x 2 portage portage 752 Oct 16 12:01 cnf
drwxr-xr-x 2 portage portage 368 Jan 13 23:00 man
drwxr-xr-x 4 portage portage 920 Jan 14 15:00 pym
drwxr-xr-x 4 portage portage 144 Aug 1 2006 src
drwxr-xr-x 6 portage portage 224 Jan 14 14:54 tests
Now the trick is to copy the appropriate binaries and scripts from this location to your system.
# cp -R pym bin /usr/lib/portage/
Unfortunately, this does not solve my problem:
# emerge portage -v
Calculating dependencies... done!
>>> Emerging (1 of 1) sys-apps/portage-2.1.2-r9 to /
#
So I am back to the troubleshooting board.
Thursday, February 15, 2007
Creating Virtual IP Addresses on Linux
Virtual IP addresses (or VIPs) allow you to use multiple IPs on a single physical network interface. Creating virtual IP addresses is often done to allow webservers to host multiple SSL encrypted web sites on a single webserver or to allow cluster suites to communicate on a dedicated IP address. This article will cover the two primary means of creating virtual IPs on a Linux host.
ifconfig
The first and most common method employed is to use the Linux command 'ifconfig' to create a VIP in the following manner, assuming that the interface being used is eth1.
# ifconfig eth1:0 192.168.1.28
This command will create a VIP on eth0 with a name of eth1:0 and will look like the following:
eth1:0 Link encap:Ethernet HWaddr 00:14:6C:83:39:92
inet addr:192.168.1.28 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33442 errors:0 dropped:0 overruns:0 frame:0
TX packets:38225 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20240563 (19.3 Mb) TX bytes:3483829 (3.3 Mb)
Interrupt:18
This command creates an apparent separate device from eth1 with it's own IP address, netmask, and broadcast address. This VIP can now be used to host services and servers, fielding connections to clients or other hosts.
To remove the VIP, simply execute ifconfig on the device with the down command:
# ifconfig eth1:0 down
iproute2
The iproute tool set is tremendously powerful and not often used, even by experienced administrators. The description of the ip command from the man pages describes this suite well:
ip - show / manipulate routing, devices, policy routing and tunnels
While one can easily perform complex tasks on the network stack of any Linux host with this tool, this article will restrict it's coverage to creating VIPs. The command to create a VIP using the ip command is as follows:
# ip addr add 192.168.1.28 dev eth1
Interesting enough, when the previous command is issued, ifconfig does not show anything different. To see the new VIP, one must use the ip command as follows:
ip addr show
When this command is executed, the output will appear like the following:
3: eth1: mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:14:6c:83:39:92 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1
inet 192.168.1.28/32 scope global eth1
This output is similar to that of a more traditional UNIX variant when compared to the output of ifconfig. The VIP created here can now be used for any purpose deemed suitable by the administrator.
To remove the VIP, execute the ip command with the following options:
ip addr del 192.168.1.28/32 dev eth1
Note that the device must be specified when creating and deleting the VIP for it to function properly. Note also that the subnet mask was specified on the deletion command and that this is not required.
Conclusion
Creating VIPs is a very simple task and one that can benefit every system administrator. Once learned, these techniques will be a great asset for common networking tasks.
ifconfig
The first and most common method employed is to use the Linux command 'ifconfig' to create a VIP in the following manner, assuming that the interface being used is eth1.
# ifconfig eth1:0 192.168.1.28
This command will create a VIP on eth0 with a name of eth1:0 and will look like the following:
eth1:0 Link encap:Ethernet HWaddr 00:14:6C:83:39:92
inet addr:192.168.1.28 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:33442 errors:0 dropped:0 overruns:0 frame:0
TX packets:38225 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:20240563 (19.3 Mb) TX bytes:3483829 (3.3 Mb)
Interrupt:18
This command creates an apparent separate device from eth1 with it's own IP address, netmask, and broadcast address. This VIP can now be used to host services and servers, fielding connections to clients or other hosts.
To remove the VIP, simply execute ifconfig on the device with the down command:
# ifconfig eth1:0 down
iproute2
The iproute tool set is tremendously powerful and not often used, even by experienced administrators. The description of the ip command from the man pages describes this suite well:
ip - show / manipulate routing, devices, policy routing and tunnels
While one can easily perform complex tasks on the network stack of any Linux host with this tool, this article will restrict it's coverage to creating VIPs. The command to create a VIP using the ip command is as follows:
# ip addr add 192.168.1.28 dev eth1
Interesting enough, when the previous command is issued, ifconfig does not show anything different. To see the new VIP, one must use the ip command as follows:
ip addr show
When this command is executed, the output will appear like the following:
3: eth1:
link/ether 00:14:6c:83:39:92 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.10/24 brd 192.168.1.255 scope global eth1
inet 192.168.1.28/32 scope global eth1
This output is similar to that of a more traditional UNIX variant when compared to the output of ifconfig. The VIP created here can now be used for any purpose deemed suitable by the administrator.
To remove the VIP, execute the ip command with the following options:
ip addr del 192.168.1.28/32 dev eth1
Note that the device must be specified when creating and deleting the VIP for it to function properly. Note also that the subnet mask was specified on the deletion command and that this is not required.
Conclusion
Creating VIPs is a very simple task and one that can benefit every system administrator. Once learned, these techniques will be a great asset for common networking tasks.
Subscribe to:
Posts (Atom)