Archive for *NIX

Skype and Google Earth Causes X To Crash On Ubuntu 10.10

[UPDATED 19-JAN-2010 – Thanks to Drew (in the comments) for bringing up the fact that this is only for 64-bit versions of Ubuntu. The filenames would indicate that, but no sense wasting your time if you’re looking for a 32-bit solution. Well, at least not yet. I may do a 32-bit build if there’s a need, but it seems as though the official repos may now have the patched versions. Have you gotten an official solution that resolved the issues? Feel free to let me know in the comments.]

After months of dealing with the mouse getting stuck between monitors, blinking like crazy and freezing all but remote SSH administration of my Ubuntu 10.04 (Lucid) desktop with triple-head monitor setup, I gave up and upgraded to 10.10 (Maverick) in hopes that it would fix the issues. I didn’t know if it did or not, because it introduced new errors. Worst of all: any time I would launch Skype, the screens would go black and X would crash in a segfault and restart. The same was true of Google Earth and of at least all Qt applications on the desktop. It took a good thirty-six hours before I traced everything back and came up with a solution. So now I’m running 10.10, which not only has a couple of minor improvements, but also seems to have finally fixed the mouse-locking issue. Hooray!

My issue turned out to be rooted in an issue with Xinerama on X with multiple monitors on an x86_64 box running the final stable of Ubuntu 10.10 (Maverick). If you have the same issues (Skype crashes X), try downloading the following file (routed through my company’s URL service so that it’s easier to share):

http://links.parasane.net/fvsq

The filename is xorg_crash_fix_debs_and_NVIDIA_driver_x86_64.tar.bz2, with the following hashes:

MD5: fe2fa5684a0f051d552bd7d0b4ee6f6a
SHA1: 0edea79d4832ce31954e29991405a67403732639

Applying it is simple (provided you have experience in knowing how to resolve your own dependencies, if any are missing). If you’d like to nip it in the bud before getting started, here’s an all-inclusive list of all packages of which I’m aware that you should have installed or which may be needed to finish this process without errors (feel free to pick and choose on your own, if you’re more comfortable doing a minimalist installation):

sudo apt-get install debhelper quilt bison flex xutils-dev x11proto-bigreqs-dev x11proto-composite-dev x11proto-damage-dev x11proto-xinerama-dev x11proto-randr-dev x11proto-record-dev x11proto-render-dev x11proto-resource-dev x11proto-scrnsaver-dev x11proto-video-dev x11proto-xcmisc-dev x11proto-xf86bigfont-dev x11proto-xf86dga-dev x11proto-xf86vidmode-dev x11proto-dri2-dev libxfont-dev libxkbfile-dev libpixman-1-dev libpciaccess-dev libgcrypt-dev nettle-dev libudev-dev libselinux1-dev x11proto-xf86dri-dev x11proto-gl-dev libxmuu-dev libxrender-dev libxi-dev x11proto-dmx-dev libdmx-dev libxpm-dev libxaw7-dev libxmu-dev libxtst-dev libxres-dev libxv-dev libxinerama-dev devscripts build-dep xserver-xorg-core

The steps to installing the fixed binaries are:

  • Drop to an alternative TTY prompt: Press CTRL+ALT+F1
  • Download the package file: wget http://links.parasane.net/fvsq -O xorg_crash_fix_debs_and_NVIDIA_driver_x86_64.tar.bz2
  • Uninstall your current NVIDIA drivers: sudo nvidia-uninstall
  • Decompress the file linked above: tar -xjvf xorg_crash_fix_debs_and_NVIDIA_driver_x86_64.tar.bz2
  • Change to the newly-created directory: cd xorg_crash_fix_debs_and_NVIDIA_driver_x86_64/
  • Install the core and common packages: sudo dpkg -i xserver-xorg-core_1.9.0-0ubuntu7_amd64.deb xserver-common_1.9.0-0ubuntu7_all.deb xvfb_1.9.0-0ubuntu7_amd64.deb
  • Set execution permissions on the included NVIDIA driver: chmod 0755 ./NVIDIA-Linux-x86_64-260.19.21.run
  • Execute the new NVIDIA driver: sudo ./NVIDIA-Linux-x86_64-260.19.21.run
  • Reboot the system: sudo shutdown -r now

You should now have a fully-working X system again. And if you upgraded because of the mouse-hang issues, you should be in good shape there, too!

NOTE: It should be VERY obvious, but this comes with absolutely no warranty or guarantee whatsoever, and you’re completely responsible for any issues that arise, directly and/or indirectly, from usage of these packages or instructions, et cetera. You know the drill by now, I’m sure.

Goodbye, s9y!

I’d finally had it.

Serendipity had a bunch of issues that were interruptive at best — destructive at worst.  I know plenty of other people have had success and been quite pleased with it, but it just wasn’t the right fit for me.  I’d known it for some time, but let’s face it: unless you’re a “blogger” by trade, you probably have more important things to do than update your personal hobby site.  I fell right into that camp myself.  I just couldn’t be bothered trying to convert it to something else.

Enter: WordPress.

Through one of my companies, PilotPig Web Hosting, we frequently get hosting orders for WordPress sites.  So the account is created, activated, and WordPress is installed for the customer.  I’ve done literally a few hundred installations and some basic customizations of the package, but I’ve never actually used it myself — until right now.  Seems decent.

Well, the one problem I thought I’d be facing was getting the posts from Serendipity imported into WordPress.  I was wrong.  All I needed to do was grab the full RSS 2.0 feed from s9y (/rss.php?version=2.0&all=1), save it to my Desktop, then run it through a quick conversion script that took all of two minutes to write:
<?php
if (!isset($argv[1])) {
echo 'Enter the RSS feed file to convert: ';
$argv[1] = trim(fread(STDIN,128));
}

$data = file_get_contents(dirname(__FILE__).DIRECTORY_SEPARATOR.$argv[1]);

file_put_contents(dirname(__FILE__).DIRECTORY_SEPARATOR.$argv[1].'-converted',
htmlspecialchars_decode($data,ENT_QUOTES));

Then just import it using the WordPress RSS importer tool, and – ta-da! – my work here was done, and I could go back to my day.  Neat.

SSH Client On Ubuntu Desktop Timing Out

It would happen again and again and again…. I’d walk away from the computer (yeah, on rare occasions that happens), or I’d flip to another terminal and get sidetracked there:

Write failed: Broken pipe

Son of a bitch! And why the hell don’t I remember to vi in screen until moments like this?!?

Well, unless I keep ‘top’ open or run a while [ 1 ]; do echo -n '';sleep 30; done, it continues to drop out without fail. And an interesting (to me) fact that I’ve actually recorded: I spend more than 60% of my day on the command line.

Logically, the first things I tried were to add /etc/ssh/ssh_config parameters for both KeepAlive and TCPKeepAlive, but that still had no positive effect. Then I started to dig deeper into the issue to see what other options I had. There were no network problems or abnormally-high numbers of dropped packets or shards, it would happen regardless of whether it was WiFi, 3G, or LAN cabled, and all other network services and applications were working just fine — including things like telephony, which was perfectly clear. I knew that it had to be a timeout issue, and since it wasn’t restricted to just a single server (or even to just thirty or forty servers, for that matter), nor was it an issue until I [finally] switched from Mandriva to Ubuntu, it had to be a local problem.

I dug and dug and dug, almost all the way to Virtual China, and finally found my Holy Grail:

ServerAliveInterval

Right now, I’m using ServerAliveInterval 120 and, for the first time since the issue reared its ugly head, I’ve been able to keep SSH sessions open and idle overnight. Hoorayings for Internets funs again and stuffs! Now maybe I can stop losing time on this and go back to only dealing with the issue of my mouse getting stuck between screens with Xinerama

ImageMagick `convert` 100% CPU Usage

Plain and simple: upgrade to the latest, if necessary, and compile with the flag:

–disable-openmp

Flashy and complicated: if you’re on CentOS5, specifically, you can do what I needed to do. I needed to write a patch for a client’s network of systems. You don’t need to do that, though, unless you need OpenMP on there (which you probably don’t). Wish I’d realized that was the issue before I went hog-wild.

So if you’re running into an issue where the ‘convert’ command is using 100% of your CPU (we had it running 800% — 100% x 8 cores), try the above. Most likely, that’ll fix ‘er.

Binding Windows Key to KDE Menu In KDE4

Seems to be a lot of confusion in KDE4 as to how to bind the Windows key on a standard keyboard to the KDE menu. Well, let’s make the solution brief:

1.) Drop to a command prompt (such as konsole).
2.) Type: xev
3.) Press the Windows key (either side, or both sides individually) and notice the number assigned to the ‘keycode’ identifier.
4.) Create (or edit) your .Xmodmap profile file. Example: vi ~/.Xmodmap
In your .Xmodmap profile, add the following, where ### is your keycode from above, and save the file:
keycode ###=F13
5.) Back at the command line, activate the above by typing: xmodmap -e ‘keycode ###=F13’
6.) Right-click the KDE menu and click “Application Launcher Menu Settings” from the menu that appears.
7.) Click “Keyboard Shortcut”.
8.) Click the button with the picture of the wrench on the “Keyboard Shortcut” screen and press the Windows key. You should see F13 appear in the box.
9.) Move your mouse out of the box and click the “OK” button to close the dialog and activate the key.
10.) Press the Windows key and see the menu pop up as expected. NOTE: You can’t tap it again to close the window. Instead, you’ll need to press the ESC key or click elsewhere.

NOTE: The above is done for brevity. A good lesson to learn from this is that ‘xev’ is a useful tool, and ‘xmodmap’ is your friend. Oh, and that the KDE folks still haven’t gotten their crap entirely straight with KDE4 as of version 4.2.4 (the version in which this was tested).

There are also other ways. In fact, I did the following for my Mandriva 2009.1 + KDE 4.2:

cat << EOT >> ~/.kde4/Autostart/bindWindowsKey.sh
xmodmap ‘keycode 133=F13’;
xmodmap ‘keycode 134=F14’;
xmodmap ‘keycode 135=F15’;
EOT

Now to figure out why Plasma keeps interfering and disabling the damn thing when I restart X or relaunch the session…. maybe I’ll post back here later.

Add New Domains to Apache On Command Line

I had a need to add several domains to Apache for a client about an hour ago, and instead of copying, pasting, changing, and repeating, I opted to script it. It’s very simple (read: not secure for multiple users in production), but served my needs today beautifully. Feel free to clean it up and use it, change it, whatever.

The primary reason this is added is to show how CLI scripts can be made to wait for and accept user input. Note the use of STDOUT and STDIN in the script. This is something that I’ve found to be quite unfortunately overlooked in a lot of CLI scripts. Using this, you can make a PHP CLI script interactive, instead of requiring arguments to be passed on the command line.

Also, note that this particular script wasn’t needed for user creation, DNS, or anything of the like. Strictly for adding an Apache directive for the domain.

(The code itself is indented, but I’m learning more and more why Philip Olsen scoffed at me for installing Serendipity last year. Eventually my error in judgment shall be rectified.)


#!/usr/bin/php
<?php

if(trim(`whoami`) != 'root') die("You must be root to run this command.\n");

fwrite(STDOUT,"Domain to be added: ");
$domain = trim(fgets(STDIN));

fwrite(STDOUT,"Username to use for this domain: ");
$user = trim(fgets(STDIN));

fwrite(STDOUT,"Group to use for this domain: ");
$group = trim(fgets(STDIN));

fwrite(STDOUT,"Path to use for the web root of this domain: ");
$path = trim(fgets(STDIN));

fwrite(STDOUT,"Server administrator's email address to use: ");
$email = trim(fgets(STDIN));

echo "Writing.... ";

$newHost =<<<TXT

NameVirtualHost *:80
<VirtualHost *:80>
ServerAdmin $email
DocumentRoot $path
ServerName $domain
ServerAlias www.$domain
ErrorLog logs/$domain-error_log
CustomLog logs/$domain-access_log combined
<IfModule mod_suphp.c>
suPHP_Engine On
suPHP_ConfigPath "/etc/"
suPHP_AddHandler x-httpd-php
suPHP_AddHandler php5-script .php
suPHP_UserGroup $user $group
</IfModule>
</VirtualHost>
TXT;

file_put_contents('/etc/httpd/conf/httpd.conf',$newHost,FILE_APPEND);

echo "Done.\n";

fwrite(STDOUT,"Should I restart Apache now for the changes to take effect? (y/N) ");
if(preg_match('/^ye?s?$/i',trim(fgets(STDIN)))) {
exec('service httpd restart');
echo "Apache restarted.\n";
}

?>

Finding Which php.ini Is Loaded

This is actually a throwback to the post Overriding PHP Settings, but is presented here separately due to the number of times the question is asked.

If you’re on a *NIX-based system and are trying to figure out which php.ini is being loaded by the CLI, simply run the following command:

ls -l `/bin/env php -i | grep "Loaded Configuration File" | sed 's/.*=> //g'`

If you want to edit the file right from that command, simply replace ‘ls -l’ with an editor of your choice, such as:

vi `/bin/env php -i | grep "Loaded Configuration File" | sed 's/.*=> //g'`

Script to Automate Multi-User Development Permissions In Linux: Part II

As discussed in the previous entry a few moments ago:

While deploying a large virtual server for a client, one of the obstacles they had faced with their previous setup was multi-user permissions with regard to everyone modifying files and directories with their own FTP and/or SSH accounts. Unfortunately, for reasons that won’t be divulged here (quite frankly because I don’t know), and even after I suggested alternatives such as updating policies and standard operating procedures, the client opted to continue using previous methods, but still wanted a resolution to issues they faced in their multi-developer environment.

The following simple Bash script is called directly via a cron job every fifteen minutes:


#!/bin/bash

mode='4771';

# The directory in which "multiUserPermissionsFix" resides.
dir='/danbrown/scripts/';

if ( test "`whoami`" != 'root' ); then
echo "$0 MUST be run as root!";
exit -1;
fi;

if ( test "$1" == "" ); then
echo "You must specify the base directory.";
exit -1;
fi;

if ( test "$2" == "" ); then
echo "You must specify the group ownership to set.";
exit -1;
fi;

if [ -d "$1" ]; then

echo -n "Verifying ownership and group ownership of all files.... ";
chown -R $2:$2 $1;
echo "Done.";

cd $1;

echo -n "Resetting permissions now.... ";
find . -type d -exec chmod $mode '{}' \;
# for i in `find . -type d`; do
# chmod $mode $i;
# done;
echo "Done.";

echo -n "Verifying ownership requirements.... ";
find . -type d -exec chmod o+s '{}' \;
# for i in `find . -type d`; do
# chmod o+s $i;
# done;
echo "Good.";

echo -n "Verifying group requirements.... ";
find . -type d -exec chmod g+s '{}' \;
# for i in `find . -type d`; do
# chmod g+s $i >> /dev/null 2>&1
# done;
echo "Good.";

if [ "$?" != "0" ]; then
echo "That group does not exist!";
exit -1;
fi;

echo -n "Fixing bad permissions.... ";
$dir/multiUserPermissionsFix $1;
echo "Done.";

echo "Task Complete.";

exit 0;

else

echo "That directory doesn't exist!";
exit -1;

fi;

Script to Automate Multi-User Development Permissions In Linux: Part I

While deploying a large virtual server for a client, one of the obstacles they had faced with their previous setup was multi-user permissions with regard to everyone modifying files and directories with their own FTP and/or SSH accounts. Unfortunately, for reasons that won’t be divulged here (quite frankly because I don’t know), and even after I suggested alternatives such as updating policies and standard operating procedures, the client opted to continue using previous methods, but still wanted a resolution to issues they faced in their multi-developer environment.

To address one particular issue, I wrote the following very simple Bash script and set it on a cron running every 15 minutes, dumping all errors and standard output to a black hole.


#!/bin/bash
# Name: multiUserPermissionsFix
# Mode: 0755

function usage {
echo "USAGE: $0 base_directory";
exit -1;
}

# If we didn't even bother to pass an argument to this script, die.
if ( test "$1" == "" ); then
usage;
fi;

# Set up find correctly.
export IFS=$'\n';

# If this is a valid directory, do the work.
if [ -d "$1" ]; then

# Force a trailing slash - workaround for symlinked directories, etc.
d="$1/";

# Find and fix all file permissions --- but ignore all 'cache' cases.
find . -type f -not -path "*cache*" -exec chmod 0664 '{}' \;

exit 0;

# If it wasn't a valid directory passed to this script, die on an error.
else
echo "That directory does not exist!";
exit -1;
fi;

This script is actually not called directly, but instead by a parent script. It recursively runs through all files and sets the permissions to 0664 (owner read/write, group read/write, world read) so that users within the group can update or delete the files within the directory without requiring administrative intervention.

Overriding PHP Settings

Getting the following error?

Invalid command ‘php_flag’, perhaps mis-spelled or defined by a module not included in the server configuration

Well, if your host and server configuration allow it, and should you so desire, you can override some of the php.ini settings for your site (and each subdirectory within your web directory). While you can’t override PHP_INI_SYSTEM settings, there’s still a host of other settings that can be overridden while still maintaining the rest of the configuration of the system – if your server is set up to allow it. And no, n00bZ, it won’t override php.ini for the rest of the box.

To grab your php.ini and copy it to the current directory, just run this command:

cp `/bin/env php -i | grep "Loaded Configuration File" | sed 's/.*=> //g'` .

Then just edit the php.ini and save it in place. Voila! No need to restart Apache or anything.