The problem most likely to hit you with one of these drives is very slow write performance. This is caused by improper logical-to-physical sector alignment. OS’s like Linux use 4K blocks (or multiples of 4K) to store data, which matches well with the physical sector. However, nothing restricts you from creating a partition that starts on an odd-numbered 512-byte logical sector. This misalignment causes a performance hit since the drive has to read and rewrite the 4K sectors with whatever 512-byte slices changed.

The article author continues with a test he performed on two identical WD Green drives containing one partition. On the first drive he used fdisk defaults for the partition boundaries, while on the second drive he manually aligned the partition. The results show that a misaligned drive can be up to 3 times slower than a properly aligned one.

…I formatted both drives using the command “time mke2fs /dev/sdc1″ (and sdd1).

/dev/sdc, which was aligned, took 5m 45.716s to format.
/dev/sdd, which was not aligned, took 19m 53.609s to format.

That’s a difference of greater than a factor of three!

The article author conducted several other tests. This is a very good read. Read the full article.

Related Articles

• Howto: Run VMWare on a Physical Windows Partition
• Effective data wiping with a single complete overwrite
• Partition images with Partimage and Partimaged
• Hard disk upgrade on an old motherboard
• Windows 7, OpenSolaris – put to the test

function rsse_add_related_posts($PostBody) {
  if (!rsse_verify_feed()) { return $PostBody; }
  if (function_exists('yarpp_related')) {
    $PostBody .= yarpp_related(array('post'),array(),false,false,'rss');
  }
  return $PostBody;
}
 
add_filter('the_content', 'rsse_add_related_posts', 252);

This code used a function of another plugin to attach a ‘related posts‘ section at the end of the full content of each feed entry. As soon as I commented out the above filter and started attaching the related-posts section to the feed content through the YARPP plugin’s administration interface, everything was normal again. No more php-cgi processes timing-out or over-consuming the CPU cycles.

The following graph shows clearly the problematic period:

php-cgi processes consuming the CPU

The httpd error_log included many errors like the following:

[...]
Allowed memory size of 33554432 bytes exhausted (tried to allocate 18893 bytes)
[...]
mod_fcgid: process ... exit(communication error), terminated by calling exit(), return code: 1
[...]
[warn] (104)Connection reset by peer: mod_fcgid: read data from fastcgi server error.
[...]
[warn] mod_fcgid: stderr: PHP Fatal error:  Allowed memory size of 33554432 bytes exhausted (tried to allocate 4864 bytes)
[...]
Premature end of script headers: index.php
[...]

Note that these errors might appear in several occasions.

In my case, finding that faulty piece of code was a huge relief, I can tell you.

Related Articles

• WordPress 2.0.6 – Feed Issues Resolved
• G-Loaded Feeds
• Redmine deployment delayed
• Issue addressed: Author feeds deliver full content
• Status of content availability via feeds

The permissive mode exists mainly for testing. In this mode, the auditing mechanism generates notices (AVC Denials) about the action/event that was blocked, but without actually blocking that action/event. It is just a way to check what would have happened if SELinux had been running in enforcing mode. There are two ways to switch SELinux to permissive mode. One is to configure it through its configuration file (/etc/selinux/config on EL) to start in permissive mode on boot and the other is to use the aforementioned utility, setenforce, to switch modes while the system is live.

When performing tests on a live system, I usually take all precautions to minimize the risk of failure and usually, if possible, I am around to monitor the progress of the test. But, this time I had to use the custom SELinux policy for some days to see if it is actually effective or it needs further fine-tuning.

The Mistake: I used setenforce to set SELinux into permissive mode (/usr/sbin/setenforce 0). setenforce is for temporary changes and it is definitely not suitable for testing the policy for a long period of time. This is because if for any reason the system reboots, SELinux will be set back into the mode that is defined into its configuration file. The mode set by setenforce does not survive a reboot. So, if the custom policy happens to be incomplete, it will block the server’s normal operation after the reboot. And such reboots can happen…

This is exactly what I experienced yesterday. The datacenter on which my virtual server is hosted had problems with its main power supply. This caused one hour of downtime. But G-Loaded’s outage was a lot greater, because my custom SELinux policy was incomplete. SELinux was started in enforcing mode, so my faulty policy blocked my www service.

This should be a lesson to anyone who performs tests on live systems. The Right Thing™ was simple: boot the server into permissive mode and do as many tests as desired. I can blame the datacenter for the one-hour downtime, but for the 7-hour unavailability of G-Loaded I am the only one to blame.

Related Articles

• SELinux audit reports script
• Using a switch to prevent system shutdown/reboot/suspend
• Server upgraded to Fedora 6
• Use the Alternatives System to switch to a custom Firefox release
• How to integrate seaudit-report in logwatch

Configuration

The procedure must be performed by root.

First of all, you need to edit the /etc/sysconfig/clock file:

ZONE="Etc/GMT"
UTC=true

Please, read the notes below for more information about the settings above.

Then run the tzdata-update utility. This copies the correct zonefile to /etc/localtime:

/usr/sbin/tzdata-update

Finally, update the system time by either running ntpd or the ntpdate utility. Both are part of the ntp RPM package, so if this is not installed, just use “yum install ntp” to get it installed.

/usr/sbin/ntpdate -b pool.ntp.org

This will make sure your time is correct.

You can set a cronjob to update the system’s time using ntpdate, like this:

#
# Update the system time
#
55 23 * * * root /usr/sbin/ntpdate -4 -b pool.ntp.org 2>&1 >> /var/log/ntpdate.log

Notes

Here are some notes about the configuration of the timezone:

1. You can find the valid timezones by changing to the /usr/share/zoneinfo/ directory. From there, any relative path to a timezone file is a valid timezone. For example, “Etc/GMT“, “Europe/Athens“, “America/New_York” et cetera.
2. GMT and UTC time are practically the same and they both refer to the Greenwich Mean Time, so setting the timezone to “Etc/UTC” or “Etc/GMT” is practically the same.
3. In /etc/sysconfig/clock you can set whether the hardware clock is set to UTC/GMT time or to Local Time. I am not sure in what way the hardware clock gets involved is the time of the Operating System. But, anyway, if you know how the hardware clock is configured, set this accordingly to true or false. Usually, if I set the OS to use GMT time, I also set this to true regardless of the actual hardware clock configuration. More info on this is still needed.
4. In /etc/sysconfig/clock you may see the options ARC=false and SRM=false. These change the way the “epoch” is assumed by the console on Alpha systems and have no effect if you do not use such a platform. Delete them or leave as is, unless you know you need to set one of them to true.
5. In order to set the correct timezone, you could just create a symlink at /etc/localtime pointing to the correct timezone file in /usr/share/zoneinfo/. Then again, this would render the system configuration file /etc/sysconfig/clock (and thus all other applications that use it) useless and ineffective, so this method is generally not recommended.

Final thoughts

Setting your server to use the correct time is very important. Generally, I hate it when I see web sites or other services having incorrect time. This reveals the web server or the web application administrator’s laziness or inability to properly configure the time. I hope this guide will help get rid of this issue.

Related Articles

• Maxmind’s GeoIP.dat.gz location change
• Change console font in Fedora
• Assign Virtual IPs to your NIC
• How to Disable IPv6 in Fedora and CentOS
• How to change the expiration date of a GPG key

UPDATE: I just read the news about lastfm’s new policy after March 30. It is a pity. I joined about a month ago and also subscribed without actually enjoying any of the features. It’s not about the money. 3 EUR per month is not a lot of money for such a service. It’s the different treatment of their customers I cannot accept. So long lastfm.

[gnot@galeon ~]$ rpm -q --changelog imsettings-libs
* Wed Mar 18 2009 Akira TAGOH  - 0.105.1-4
- Fix a dead key not working. (#483840)
- Get rid of more debugging messages. (#484142)
- Disable imsettings-xim in xinput.sh. (#485595)
- Fix a parser error on reading Compose data.
- Fix a double-free issue.
- Workaround to get the accelerator keys working again.
  Note that this workaround might affects to the performance. you may want
  to disable this with:
  gconftool-2 -t bool -s /apps/imsettings-applet/sync_on_forward false
  (#488675)
- Fix getting-stuck-issue on keyevent. (#488976, #489611)

I am not quite sure which one fixed the aforementioned issue, but I am really glad things work again normally.

Related Articles

• The hole trick
• Using a switch to prevent system shutdown/reboot/suspend

While I was performing the operating system installations, everything seemed to work as expected. Each virtual machine obtained a dynamic IP address and the DNS records were updated correctly. Glad that things work, I turned off Dom0 after the tests.

At a later time, when I switched Dom0 on again, I noticed that I could not reach any of the virtual machines. Their fully qualified domain names that had been allocated to them by the DHCP service would not resolve to the proper IP. To make it worse, it seemed that the virtual machines had no active leases at all!

Soon I discovered that xendomains, the service responsible for starting and stopping the unprivileged Xen domains (DomU), whenever Domain Zero was shut down, it just saved the domain U’s state for later restoration instead of initiating the DomU’s shutdown procedure. When Dom0 was brought up again, xendomains restored the saved DomU states instead of forcing the domains to boot up normally.

I assume this is like suspending a laptop, which has obtained its IP automatically from a DHCP service within LAN A, moving it to a LAN B, and then bringing it up again within that LAN. It is almost certain that for an arbitrary amount of time you would experience connectivity problems.

In both cases above, at the time the machine resumes operations, the dhclient script (or any other similar script) is not run in order to renew the machine’s IP address.

Fortunately, this behaviour of the xendomains service is configurable. In order to force all DomUs to shutdown, instead of suspending, during Domain 0′s shutdown, all you have to do is make following changes in /etc/sysconfig/xendomains:

Leave empty the XENDOMAINS_SAVE variable. By default, it uses /var/lib/xen/save as the directory where the states of the DomUs are saved. By leaving it empty, the states of the virtual machines are not saved, but they are shut down as usual.

XENDOMAINS_SAVE=""

The second modification involves setting the XENDOMAINS_RESTORE variable to false. This determines whether saved domains will be restored from the directory set in the XENDOMAINS_SAVE variable during the Dom0 startup:

XENDOMAINS_RESTORE=false

From now on, whenever Dom0 starts up, it will force all U domains to boot up normally. Contrariwise, whenever Dom0 shuts down, it will force all DomU to shut down as well. No domain state saving or restoration happens any more.

This means that the network service on each DomU, hence the dhclient script, will run every time the domain U starts up or shuts down, ensuring proper allocation of dynamic IP addresses and hostnames by the DHCP service. Of course, this adds much overhead to both the boot and power off process of Domain Zero (Dom0), but it seems that there is no other way to overcome this problem. If you know of a better way, please let me know.

Related Articles

• Howto: DHCP Server (dhcpd) Configuration
• Assign Virtual IPs to your NIC
• Set up the VNC Server in Fedora
• Partition images with Partimage and Partimaged
• Almost saying goodbye to innovation

To be able to correct things I had to boot using a Fedora 9 kernel in order to make any changes to the files and get rid of this issue. What was needed was to stop using device names in fstab, but use UUIDs instead. To get the UUID for a particular block device, for example /dev/sda1, I ran as root:

# blkid /dev/sda1
/dev/sda1: LABEL="/boot" UUID="xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" TYPE="ext3"

Now replace the device node name in /etc/fstab to read:

UUID=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx    /boot    ext3    defaults    1 2

Of course, I could have used the label of that partition, but I guess UUIDs are more unique and therefore preferred.

Related Articles

• A different approach…HAL
• Hard disk upgrade on an old motherboard
• UDEV
• Encrypt devices using dm-crypt and LUKS
• CloneZilla instead of Partimage

#! /bin/sh
 
if [ -f /var/lock/noshutdown.lock ] ; then
  logger -t shutdowndog shutdown prevented
  exit 1
fi
 
/sbin/shutdown "$@"

Then, I created the file that would act as a switch:

touch /var/lock/noshutdown.lock

Then, I initiated the shutdown procedure from the command line:

shutdown -h +0

There was no shutdown! It had worked!

Syslog confirmed that the check had taken place:

Nov 25 19:19:04 galeon shutdowndog: shutdown prevented

I rushed to try to shut down the system from GNOME’s shutdonw panel (Menu System -> Shut Down...), but, after pressing the relevant button, the system went down normally…

It was obvious that GNOME had not used my override, but another mechanism to power-off the system instead. Since I use the GNOME menu to shutdown/reboot/suspend the system, I spent a couple of hours trying to find what was going on in GNOME and finally discovered the file /usr/bin/gnome-power-cmd.sh:

#!/bin/sh
# Copyright (C) 2007 Richard Hughes <richard@hughsie.com>
#
# Licensed under the GNU General Public License Version 2
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
 
#$1 = method name
execute_dbus_method ()
{
        dbus-send --session --dest=org.freedesktop.PowerManagement              \
                  --type=method_call --print-reply --reply-timeout=2000 \
                  /org/freedesktop/PowerManagement                      \
                  org.freedesktop.PowerManagement.$1
        if [ $? -eq 0 ]; then
                echo "Failed"
        fi
}
 
if [ "$1" = "suspend" ]; then
        echo "Suspending"
        execute_dbus_method "Suspend"
elif [ "$1" = "hibernate" ]; then
        echo "Hibernating"
        execute_dbus_method "Hibernate"
elif [ "$1" = "reboot" ]; then
        echo "Rebooting"
        execute_dbus_method "Reboot"
elif [ "$1" = "shutdown" ]; then
        echo "Shutting down"
        execute_dbus_method "Shutdown"
elif [ "$1" = "" ]; then
        echo "command required: suspend, shutdown, hibernate or reboot"
else
        echo "command '$1' not recognised, only suspend, shutdown, hibernate or reboot are valid"
        exit 1
fi

So, GNOME makes the appropriate calls for power-related events through D-bus. I initially thought that GNOME used /usr/bin/gnome-power-cmd.sh whenever the shutdown/reboot/suspend button was pressed, so I modified it so to check for my switch (/var/lock/noshutdown.lock) and then proceed accordingly. It did not work out…

I had already spent much time on this, so I decided to quit. But, it is crucial for me to make this thing work and I will probably investigate it a bit more and report back at some later time.

Related Articles

• delayed-shutdown initscript
• Using setenforce to switch SELinux mode wisely
• Use the Alternatives System to switch to a custom Firefox release
• Dictionary Lookups Anywhere
• Access gvfs mounts from the command line

So, since email notifications are preconfigured, the first thing to do after a clean Linux system installation is to set the email redirection. This can be done with the following:

# echo "root:   youruser" >> /etc/aliases
# newaliases

If it happens that you find root’s or any other user’s mailbox with tons of email notifications from your system, you can delete them by entering the console mail client “mail“:

# mail

…and enter the following command at its prompt:

& delete *

I guess there are many desktop users out there with their root account’s mailbox full of system notifications. At least, for desktop systems, there should a note about setting up the redirection of root’s email to your user’s mailbox.

Related Articles

• Problems using libnotify for User to User Notifications
• Organizing Mailing List messages with Evolution
• SELinux audit reports script
• Free Personal Email Certificates Program discontinued by Thawte
• High traffic on the email server

VMWare is an incredibly useful piece of software. Problem is, it feels like it’s perched on the tip of an eggshell. Any change to its environment tends to cause it to fall over, isolating all your data in the VM until you can find the time to get it working again. It’s not fun to trust important data to such a brittle environment.

Apart from the concern about the stability of the environment that hosts the guest operating system I can think of 1 or 2 more reasons why someone would want to run VMWare on a pre-existing installation of Windows on a physical volume. The first would be “convenience” and the other would be just “fun“.

Read the entire article »

Related Articles

• Partition Misalignment Slows Down 4096-Byte Sector Hard Disks
• High CPU usage while running CentOS as guest on Virtualbox or VMware
• LDAP HOWTO
• Partition images with Partimage and Partimaged
• chroot Environment Howto