Browse Tag: howto

Renaming a node in chef

Too bad there’s no `knife node rename ‘, eh?

Here’s what you gotta do instead:

knife client delete oldname
knife node delete oldname

On the node itself:

rm /etc/chef/client.pem
sed -i 's/oldname/newname/g' /etc/chef/client.rb
ls /etc/chef/validation.pem # ensure it's there!
chef-client -N newname

This will register the new node name with chef. The runlist will be empty, so you’ll have to rebuild it. Voila!

Push email on iPhone and other smartphones… without Exchange

Tonight, I found a clever open-source project entitled Z-Push. This small collection of PHP sits in a web directory and responds to ActiveSync queries — the protocol used for Exchange. It then checks and delivers email.

This is useful because of the limitations of some smartphones — such as the iPhone — wherein Exchange-hosted mail is delivered instantly, while standard POP3 or IMAP mail accounts suffer a long polling delay.

On the server side, configuration is fairly simple:

  1. wget
  2. tar xzvf z-push-1.3RC.tar.gz
  3. mv z-push /var/www/html
  4. yum install php-imap
  5. chown apache:apache /var/www/html/z-push/state
  6. vi /var/www/html/z-push/config.php and configure the following:
    define(’IMAP_SERVER’, ‘localhost’);
    define(’IMAP_PORT’, 143);
    define(’IMAP_OPTIONS’, ‘/notls/norsh’);

  8. Add the following Alias to an Apache SSL VirtualHost:
  9. Alias /Microsoft-Server-ActiveSync /var/www/html/z-push/index.php

  10. Restart Apache

On your phone, simply create a new Exchange-type account that points to your server as if it was an Exchange server. Send a test mail and marvel at how fast it appears on your phone! Tested on iPhone and Motorola Droid with excellent success.

Enable WebDAV with Plesk

Configuring WebDAV in Apache is simple, but it’s even easier to configure and manage with Plesk!

1. Create a Protected Directory
Log into Plesk and select the domain that is to receive the DAV repository. Click on “Protected Directories” and create a new one – name it as the DAV share will be named, for they are one and the same.

2. Configure WebDAV Users
Add users who should have access to this DAV repo.

3. Edit vhost.conf and Reconfigure Plesk
On the server, edit the domain’s vhost.conf and enter the following:

[code]<Directory “/var/www/vhosts/”>
DAV on
AllowOverride None

Regenerate Apache’s configuration and you’re golden:

[code]/usr/local/psa/admin/bin/websrvmng -av[/code]

4. Test
You can easily test DAV configuration by using a DAV client such as `cadaver’.

[code][kale@superhappykittymeow ~]$ cadaver
Authentication required for on server `’:
Username: kale
dav:/DAVDir/> ls
Listing collection `/DAVDir/’: collection is empty.[/code]

Success! You can manage access to the DAV share through the Plesk interface.

Apache MultiViews and RewriteRules

Don’t work together.

I think it’s a bug in mod_rewrite, to be honest, though more of a “not thinking these two modules would ever be used together” kind of oversight, rather than a full bug.

Essentially, if you are using MultiViews to make for pretty URLs (say,, where ‘bar’ doesn’t exist, but instead loads the content from bar.php), and you attempt to implement RewriteRules to modify the URL, you will see erratic results.

If, for example, you have a RewriteRule as follows:

[code]RewriteCond %{HTTP_HOST} !^www\.foo\.com
RewriteRule (.*)$1 [R=301,L][/code]

which, essentially, takes all non-WWW requests and makes them, you will find that MultiView URLs will be redirected to their real resources if the URL matches a rule. For example,

will become

after going through the MultiView filter and the RewriteRules. This is due to the way the rules work — essentially, the request will be parsed through mod_rewrite to find a match. If no match against the URL, the MultiView is processed to get the real resource which is then presented to the end user. If a match is made, however, mod_rewrite has mod_negotiation process the MultiView to find the real resource so it can properly do the rewrite — it is never changed back, however, to the pretty MultiView URL. If your goal is pretty URLs without any effort expended, relying on MultiView, you will find that RewriteRules are your nemesis.

There are a few routes available to get around this odd behavior, but my favorite (and easiest to implement) is to move the RewriteRule logic to the site code. It’s much harder to implement MultiView-esque functionality than it is to re-implement RewriteRules.

To implement the above RewriteRule, redirecting non-www to www, simply add an auto_prepend_file to your .htaccess in lieu of the RewriteRule as such:

[code]php_value auto_prepend_file “/var/www/html/prepend.php” [/code]

This file contains simply:

[code lang=”php”][/code]

With this code prepended to every PHP script (assuming your site is written in PHP, of course), all non-www requests will be redirected to www — *after* the MultiView is processed and not interfering with its inner workings.

Email alerts on new virus with Sophos

Sophos’s Linux antivirus product is an interesting beast, but I’ll reserve opinion. We offer a web interface wherein the end-user may review alerts, though some also wish an email alert. This can be configured through savwebd, the web GUI provided with the Sophos antivirus client, or configured on the command line:

[code lang=”bash”]cd /opt/sophos-av/bin
./savconfig -v # review current configuration settings
./savconfig set Email # recipient
./savconfig set EmailNotifier true
./savconfig set EmailDemandSummaryIfThreat true
./savconfig set EmailServer localhost
./savconfig set SendThreatEmail true
./savconfig set ThreatMessage “A virus has been detected and blocked. Please contact your support team for more information.”

Enable core dumps with apache, RHEL5

From this post on Jared’s tech blog:

[code lang=”bash”]echo “ulimit -c unlimited >/dev/null 2>&1” >> /etc/profile
echo “DAEMON_COREFILE_LIMIT=’unlimited'” >> /etc/sysconfig/init
echo 1 > /proc/sys/fs/suid_dumpable
echo “core.%p” > /proc/sys/kernel/core_pattern
echo “CoreDumpDirectory /var/apache-core-dumps” > \
mkdir /var/apache-core-dumps
chown apache: /var/apache-core-dumps
source /etc/profile
/etc/init.d/httpd restart[/code]

Now you can test it by sending a SIGSEGV to a random apache child process:

[code lang=”bash”]tail -f /var/log/httpd/error_log | grep -i seg &
ps auxwww |grep httpd (pick a random pid not owned by root)
kill -11 2014
[Mon Jul 06 21:05:39 2009] [notice] child pid 2014 exit signal
Segmentation fault (11), possible coredump in /var/apache-core-dumps
cd /var/apache-core-dumps

You can then get a backtrace using gdb:

[code lang=”bash”]gdb /usr/sbin/httpd core.2014
(gdb) > bt full[/code]

Brilliant – thanks Jared, I fought Apache for an hour to enable CoreDumps before putting my fist through the monitor!

Mount NTFS drive in RHEL5

Grab fuse, fuse-ntfs-3g and dkms-fuse from Dag’s repo:

[code lang=”bash”]wget


[code lang=”bash”]rpm -Uvh fuse-2.7.3-1.el5.rf.x86_64.rpm fuse-ntfs-3g-1.2310-1.el5.rf.x86_64.rpm dkms-fuse-2.7.2-1.nodist.rf.noarch.rpm[/code]


[code lang=”bash”]mount.ntfs-3g /dev/sdc1 /mnt/usb/ -o force[/code]

Red5 Installation and Usage

Red5 is an open source streaming flash media server. It’s a java-based application that is surprisingly easy to install and well-documented as such, though the documentation fails when it comes to usage — such as streaming live video.


Download from the Red5 page: . Caveat: I’ve never really gotten this page to work. I’ve mirrored it on my slice:

Java 1.5:
Java 1.6:


[code lang=”bash”]tar xzvf red5-0.8.0-java5.tar.gz[/code]


[code lang=”bash”]./[/code]

That’s it for the install. Congratulations! Red5 is running and accessible at http://your-ip:5080 .

Go there and follow the instructions. Namely, click on where it states clearly to “Click here to install demos”. Red5 ships with a number of demos that are inappropriately named but you should probably install anyway if you want to do cool things like stream live video.

“oflaDemo” is the key mis-named application that need be installed. Select and click “install”.

Thereafter, visit the Publisher utility: http://your-ip:5080/demos/publisher.html

You may need to change the server settings to point to your server (hint: won’t work — use the public IP). Create a stream with your input source (webcam, screencast, etc) and assign a stream name, and hit publish. Hurray, now that video is being broadcast over rtmp!

You can connect to this RTMP source using a Flash viewer like Flowplayer, setting the RTMP source as rtmp://your.ip/oflaDemo, with the clip URL as the name you assigned as the name in the publisher app.


Save a file in vi as the superuser

If you’ve opened a file in vi for which you don’t have write privileges, you can save the file as the superuser (if your user is in the sudoers list) by running the following vi command:

[code]:w !sudo tee %[/code]

After doing so, vi will detect that the file has changed and ask if you want to reload it.

The 10 Golden Rules for Troubleshooting Linux

1. Man pages exist and should be used. Seriously, everything’s there, from application docs to syscall docs to syntax and formatting of log files.

2. Don’t reinvent the wheel. 99% of problems you’re experiencing or ever will experience, somebody’s already gone through it and figured it out. Google is your friend.

3. If you don’t know what something’s doing, or why it’s not working, strace it!

4. Logs exist for a reason. Read them.

5. Applications crash, servers don’t. If your server crashes, it’s either bad hardware or a kernel bug (fairly rare on popular distros).

6. Always make backups. Always.

7. Always mount NFS mounts with the ‘intr’ option. Having to reboot because of a network blip is uncool.

8. Learn to use `grep’, `sed’ and `awk’. Learning to manipulate text is surprisingly important for a text-based interface.

9. Load average does not mean CPU usage. 100% memory usage does not mean you don’t have any more available for new applications. You can run out of inodes before you run out of disk space.

10. TCP wrappers suck. If you’ve been hacking at an issue for over 3 hours, look to your TCP wrappers. /etc/hosts, /etc/hosts.allow and /etc/hosts.deny will hold the answer.

Manually mounting a USB drive in Linux

Most modern distros are quite smart and will recognize the variety of USB devices plugged in automagically. Today, for whatever reason, RHEL5 refused to do so, and I had to do it the hard way.

First, make sure you’ve got USB modules loaded:

[code lang=”bash”]modprobe uhci_hcd
modprobe ohci_hcd
modprobe ehci_hcd
modprobe usb-storage[/code]

With the last one, wait a few moments, then run `dmesg’. You should see some useful information:

Initializing USB Mass Storage driver...
scsi1 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 8
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usb-storage: waiting for device to settle before scanning
usb 1-3.3: reset high speed USB device using ehci_hcd and address 8
Vendor: Seagate Model: FreeAgent Go Rev: 102D
Type: Direct-Access ANSI SCSI revision: 04
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 1c 00 00 00
sda: assuming drive cache: write through
SCSI device sda: 625142448 512-byte hdwr sectors (320073 MB)
sda: Write Protect is off
sda: Mode Sense: 1c 00 00 00
sda: assuming drive cache: write through
sda: sda1
sd 1:0:0:0: Attached scsi disk sda
sd 1:0:0:0: Attached scsi generic sg0 type 0
usb-storage: device scan complete

If you’re lucky, you can simple do an `fstab -l’ and see the drive and it’s partitions at the stated point (sda). I wasn’t so lucky, as this server didn’t have device nodes for sda. These, however, are easily created:

[code lang=”bash”]/dev/MAKEDEV sda[/code]

Now you should be able to mount it:

[code lang=”bash”]mount /dev/sda1 /mnt/usb[/code]

Add a system user as a Webmin user

Edit the user file:
[code lang=”bash”]vi /etc/webmin/miniserv.users[/code]

Enter the system user’s name, followed by :x:
[code lang=”bash”]kale:x[/code]

Edit /etc/webmin/webmin.acl to give access to this new user

Restart Webmin