MogileFS with Postgres

First of all, you need Postgres version 8.2 or newer since mogdbsetup refuses to run with older versions.

Anyways, I spent a quite a bit of time trying to install MogileFS with Postgres. I was getting "Can't create temporary test database:" errors. The answer was in the ~/.cpan/build/mogilefs-server-2.34/blib/lib/MogileFS/Test.pm file. The temp_store subroutine was defaulting to MySQL...

Here is the setup step by step on my Fedora 12:

yum install mogilefsd
yum install mogstored
yum install perl-CPAN // if needed
yum install perl-MogileFS-Client perl-MogileFS-Utils
yum install perl-DBD-Pg
yum install perl-IO-AIO


Setup services.

chkconfig --levels 345 mogilefsd on
chkconfig --levels 345 mogstored on


Setup a test database to be used during compilation.

$ createuser -SRlD mogile
$ createdb -E UTF8 -O mogile tmp_mogiletest


Setup environment variables for testing

$ MOGTEST_DBUSER=mogile
$ MOGTEST_DBHOST=dbhost
$ MOGTEST_DBNAME=tmp_mogiletest
$ MOGTEST_DBTYPE=Postgres
$ export MOGTEST_DBUSER MOGTEST_DBNAME MOGTEST_DBTYPE MOGTEST_DBHOST


Download and install MogileFS::Store::Postgres from CPAN. (This is going to download the whole mogilefs-server package)

$ cpan
cpan> install MogileFS::Store::Postgres


Setup database

template1=# create user mogilefs with encrypted password 'password';
template1=# create database mogilefs with owner=mogilefs encoding='UNICODE';


Run mogdbsetup

mogdbsetup --type=Postgres --dbhost=localhost --dbname=mogilefs --dbuser=mogilefs --dbpass=password


Setup config


db_dsn DBI:Pg:dbname=mogilefs;host=mogilefs-db
db_user mogilefs
db_pass password
conf_port 6001
listener_jobs 5


Start tracker
service mogilefsd start


Update mogstored.conf
httplisten=0.0.0.0:7500
mgmtlisten=0.0.0.0:7501
docroot=/var/mogdata


Define hosts and devices

mogadm host add mogilestorage-1 --ip=127.0.0.1 --port=7500 --status alive
mogadm host list
mogadm device add mogilestorage-1 1
mogadm device add mogilestorage-1 2
mkdir /var/mogdata/dev1
mkdir /var/mogdata/dev2
chown mogstored:mogstored /var/mogdata/dev1/
chown mogstored:mogstored /var/mogdata/dev2/
service mogstored start


Define domains and classes

mogadm domain add domain1
mogadm class add domain1 class1 --mindevcount=2


And don't forget to clean up the test user and database.

Fedora 12 upgrade woes: Apache issues

Could not start the httpd service for a while due to:

Syntax error on line 196 of /etc/httpd/conf/httpd.conf: Cannot load /etc/httpd/modules/mod_file_cache.so into server: /etc/httpd/modules/mod_file_cache.so: cannot open shared object file: No such file or directory


I had to manually comment out two unneeded modules from the /etc/httpd/conf/httpd.conf:

#LoadModule file_cache_module modules/mod_file_cache.so
#LoadModule mem_cache_module modules/mod_mem_cache.so


More here.

Passive checks with Nagios

Today, while I was trying to set up Nagios on my local box at work when Nagios refused to start due to bad configuration error.

Starting nagios:CONFIG ERROR! Start aborted. Check your Nagios configuration.


It took some to time to realize that a "check_command" line has to be defined even for passive check.

define service {
    use                        local-service
    service_description        passive_service
    check_command              check_dummy!2
    active_checks_enabled      0
    passive_checks_enabled     1
    }

The best explanation is from the 2.0 docs located at: http://nagios.sourceforge.net/docs/2_0/freshness.html


What Happens When A Service Check Result Becomes "Stale"

If the check results of a service are found to be "stale" (as described above), Nagios will force an active check of the service by executing the command specified by the check_command option in the service definition. It is important to note that an active service check which is being forced because the service was detected as being "stale" gets executed even if active service checks are disabled on a program-wide or service-specific basis.


In the above example, if the service becomes "stale", the check_dummy command would simply reply with a critical(2) return code.

Fedora 10 (Cambridge) to Fedora 12 (Constantine) with PreUpgrade

Ok, here goes my first blog post ever...

Last Friday, I decided to upgrade from Fedora 10 to 12 using the PreUpgrade tool. The download and the installation process went well until the time came to boot into the new system. I suspected something was wrong when I realized the fc12 kernel line was missing from the Grub menu, and I was "relieved" to see I was right the whole time when I was presented with:

Give root password for maintenance (or type Control-D to continue):

I could not even type. Every time I hit a key, i was prompted with the same line... Thankfully, I had that old custom compiled vanilla kernel sitting in the Grub menu that allowed me to boot and utilize the command line at least.

Although I was able to interact with Grub during the boot process, I decided to complicate the problem for no apparent reason and thought there must be something wrong with the grub itself... I burned the Fedora 12 DVD iso image and booted the computer into rescue mode... Two commands:


chroot /mnt/sysimage
grub-install /dev/sda


and a reboot later, I was staring at the same screen again...

This time I decided to check the /boot partition to see if the new kernel was properly installed. And voila: No fc12 vmlinuz or initrd files there! As usual, without any respect to conventional wisdom, I forcefully installed the first kernel rpm package that I could find on the Fedora 12 DVD. A quick check revealed that the required image files were created in the /boot partition along with the Grub entry. Confident, I rebooted with a smirk on my face only to discover a corrupted display - imagine a GUI with heavy texture and kaleidoscope effects.

A quick examination of the log revealed the following error:

Unable to load the kernel module 'nvidia.ko'

So I tried to reinstall the NVIDIA drivers:


yum remove kmod-nvidia
yum install kmod-nvidia


I had no luck there. Further investigation into /etc/rc.d/init.d/nvidia file clarified the loading process for nvidida.ko:

modname="nvidia.ko"
modpath="/lib/modules/$(uname -r)"
# Default to no module
module="noneWithSomeCrazyNameSoItsNeverFound"
# If one exists, then use it.
if test -e "${modpath}/extra/${modname}";then
    module="${modpath}/extra/${modname}"
elif test -e "${modpath}/extra/nvidia/${modname}";then
    module="${modpath}/extra/nvidia/${modname}"
elif test -e "${modpath}/kernel/drivers/video/nvidia/${modname}";then
    module="${modpath}/kernel/drivers/video/nvidia/${modname}"
fi

In my case, the older version of the kernel rpm package that I had forcefully installed was causing "uname -r" to return "2.6.31.5-127.fc12.i686". On the other hand, yum was installing everything into "/lib/modules/2.6.31.12-174.2.3.fc12.i686" due to the original kernel package that was also present on the system. I simply removed the old kernel package, reinstalled the original kernel package to generate the /boot images and the grub entry, and ran the nvidia install commands above...

After wasting six hours due to another logic exception, I got my computer working again.