Racker Hacker

Here’s a pretty weird kernel panic that I came across the other day:

Enforcing mode requested but no policy loaded. Halting now.
Kernel panic - not syncing: Attempted to kill init!

This usually means that you’ve set SELINUX in enforcing mode within /etc/sysconfig/selinux or /etc/selinux/selinux.conf but you don’t have the appropriate SELINUX packages installed. To fix the issue, boot the server into the Red Hat rescue environment and disable SELINUX until you can install the proper packages that contain the SELINUX targeted configuration.

This kernel panic appeared on a Red Hat Enterprise Linux 4 Update 5 server.

A few days ago, I began to install a group of packages with up2date, and the person next to me was surprised that up2date even had this functionality. I use it regularly, but I realized that many users might not be familiar with it.

You can install package groups using an at-sign (@) in front of the group name:

# up2date -i "@X Window System"

This will tell up2date to install all of the packages that are marked within the “X Window System” package group. That would include X drivers, the X libraries/binaries, and twm (among many other packages). If you’re not sure which groups are available, just pass the --show-groups flag and review the list:

# up2date --show-groups
Administration Tools
Arabic Support
Assamese Support
Authoring and Publishing
Base
Bengali Support
Brazilian Portuguese Support
British Support
Bulgarian Support
Catalan Support
Chinese Support
Compatibility Arch Development Support
Compatibility Arch Support
Core
Cyrillic Support
Czech Support
DNS Name Server
Danish Support
Development Libraries
Development Tools
Dialup Networking Support
Dutch Support
Editors
Emacs
Engineering and Scientific
Estonian Support
FTP Server
Finnish Support
French Support
GNOME
GNOME Desktop Environment
GNOME Software Development
Games and Entertainment
German Support
Graphical Internet
Graphics
Greek Support
Gujarati Support
Hebrew Support
Hindi Support
Hungarian Support
ISO8859-2 Support
ISO8859-9 Support
Icelandic Support
Italian Support
Japanese Support
KDE
KDE (K Desktop Environment)
KDE Software Development
Korean Support
Legacy Network Server
Legacy Software Development
Mail Server
Miscellaneous Included Packages
MySQL Database
Network Servers
News Server
Norwegian Support
Office/Productivity
Polish Support
Portuguese Support
PostgreSQL Database
Printing Support
Punjabi Support
Romanian Support
Ruby
Russian Support
Serbian Support
Server
Server Configuration Tools
Slovak Support
Slovenian Support
Sound and Video
Spanish Support
Swedish Support
System Tools
Tamil Support
Text-based Internet
Turkish Support
Ukrainian Support
Web Server
Welsh Support
Windows File Server
Workstation Common
X Software Development
X Window System
XEmacs

I’ve revamped a few of the recommendations in MySQLTuner, and revision 19 is now available tonight! Here’s the main changes:

* Adjusted infoprint to use asterisks (cosmetic)
* Per-thread/global buffer counts are now displayed
* Key buffer increases are only recommended if the buffer is smaller than total indexes and hit rate is < 95%
* Dropped max_seeks_for_key checks
* Temporary table size increases are not recommended over 256M
* Aborted connection calculation and recommendation adjustments

You can download the latest copy on the MySQLTuner page, and you can get diffs for the new version as well.

If you’re using Plesk 8.0 or later, you can set up Dr. Web to be enabled for all new mail accounts. To do this, you have to create an event handler.

Here’s the steps you will need:

» Log into Plesk
» Click “Server”
» Click “Event Manager”
» Choose “Mail Name Created” next to “Event”
» In the command area, enter /usr/local/psa/bin/mail.sh --update $NEW_MAILNAME -antivirus inout
» Click “OK”

When you dump table data from MySQL, you may end up pulling a large chunk of data and it may exceed the MySQL client’s max_allowed_packet variable. If that happens, you might catch an error like this:

mysqldump: Error 2020: Got packet bigger than 'max_allowed_packet' bytes when dumping table `tablename` at row: 1627

The default max_allowed_packet size is 25M, and you can adjust it for good within your my.cnf by setting the variable in a section for mysqldump:

[mysqldump]
max_allowed_packet = 500M

I was recently working on a server where a user on the server was concerned with these log messages:

Oct 7 20:59:33 web named[13698]: client 111.222.333.444#50389: updating zone ‘domain.com/IN’: update failed: ‘RRset exists (value dependent)’ prerequisite not satisfied (NXRRSET)
Oct 7 20:59:34 web named[13698]: client 111.222.333.444#50392: update ‘domain.com/IN’ denied
Oct 7 21:59:35 web named[13698]: client 111.222.333.444#50422: updating zone ‘domain.com/IN’: update failed: ‘RRset exists (value dependent)’ prerequisite not satisfied (NXRRSET)
Oct 7 21:59:35 web named[13698]: client 111.222.333.444#50425: update ‘domain.com/IN’ denied
Oct 7 22:59:20 web named[13698]: client 111.222.333.444#50458: updating zone ‘domain.com/IN’: update failed: ‘RRset exists (value dependent)’ prerequisite not satisfied (NXRRSET)

The messages here are actually showing that named is doing its job well. Some user was attempting to dynamically update a DNS zone repeatedly, but named was rejecting the updates since they were not coming from a valid sources.

Further reading:
Zytrax.com: DNS BIND Zone Transfers and Updates
Internet Systems Consortium: Dynamic Updates

In some situations with dovecot running on your server, you may receive a message from your e-mail client stating that the “connection was interrupted with your mail server” or the “login process failed”. This may happen even if you’ve created the e-mail account, created the mail spool, and set a password for the user.

If you check your /var/log/maillog, you will generally find errors like these:

Oct 7 09:37:45 mailserver pop3-login: Login: newuser [111.222.333.444]
Oct 7 09:37:45 mailserver pop3(newuser): mbox: Can’t create root IMAP folder /home/newuser/mail: Permission denied
Oct 7 09:37:45 mailserver pop3(newuser): Failed to create storage with data: mbox:/var/spool/mail/newuser

Dovecot is telling you that it wants to store some mail-related data in the user’s home directory, but it can’t get access to the user’s home directory. If the home directory doesn’t exist, create it and set the permissions properly:

# mkdir /home/newuser
# chown newuser:newuser /home/newuser
# chmod 755 /home/newuser

If the directory is already there, double check the ownership and permissions on the directory. If filesystem acl’s or filesystem quotas might be in play, be sure to check those as well.

On brand new Plesk 8.2.x installations or on servers that have been upgraded to Plesk 8.2.x, you might run into this error when you attempt to log into squirrelmail after it was installed via RPM:

Error opening /var/lib/squirrelmail/prefs/default_pref
Could not create initial preference file!
/var/lib/squirrelmail/prefs/ should be writable by user apache
Please contact your system administrator and report this error.

No matter what you do to the /var/lib/squirrelmail/prefs/default_pref file, even if you chmod 777 the file, you will still get the error. If you check the /etc/php.ini, you will normally find safe_mode set to on.

;
; Safe Mode
;
safe_mode = Off

Simply change safe_mode to off and reload Apache. If you try to log into squirrelmail again, it should complete successfully. I’ve tested this on Red Hat Enterprise Linux 4:

# rpm -q squirrelmail
squirrelmail-1.4.8-4.0.1.el4

I’ve seen quite a few situations where the Horde login process can take upwards of 45 minutes to log a user into the webmail interface. There’s a few issues that can cause these extended delays, and most of them can be fixed rather easily:

Too many filters / Giant whitelists and blacklists
This is the biggest cause that I’ve seen. Some users will create gigantic white and black lists (upwards of 5,000 is my record that I’ve seen) and this makes Horde compare each and every message in the inbox against these lists upon login. This also applies to filters as Plesk does not use sieve/procmail for mail delivery. Horde is forced to do all of the filtering upon login (in some versions) and this can cause extreme delays.

Mailbox is gigantic
I’ve seen Horde logins take quite a while in mailboxes that are over 500MB in size. If the size of your e-mails is large, and you have a large mailbox with fewer e-mails, Horde can normally work quickly. But, if your inbox is full of tiny e-mails, Horde takes a long time to fully index your mail and display the list (even though it only displays 25-30 at a time).

Too many users logged into Horde simultaneously
In my opinion, Horde’s CPU and memory requirements are too large for a webmail application. I’ve seen 30-40 simultaneous Horde sessions bring a dual-core box with 2-4GB of RAM and SCSI disks to its knees. Consider installing squirrelmail or roundcube webmail for some of your users and urge them to use it instead.

IOwait caused by something else
Sometimes the server can simply be bogged down with other requests from other daemons, and this slows Horde down. Make sure that your MySQL installation is tuned properly, and that users are not abusing scripts running through Apache.

One of the most annoying (and explosive) changes in Plesk 8.2 is the automatic addition of up2date sources for its use. As of 8.2.0, the packages are not signed, and they generate errors with up2date. Also, Plesk often keeps adding the sources over and over to /etc/sysconfig/rhn/sources, and this causes additional errors and delays when you use up2date.

You can disable this behavior entirely by running the following:

# echo ALLOW_TO_USE_UP2DATE=no > /root/.autoinstallerrc

This will instruct Plesk’s autoinstaller to not add any sources to the up2date sources list.