Archive

Archive for the ‘Break-Fix’ Category

Note that the MySQL client library is not bundled anymore. Solved!

January 31st, 2010

This error is not specific to Litespeed but can be encountered while building PHP with MySQL support on 64-bit systems. The fix is to tell the build that the MySQL client is indeed installed, but in a different directory, by adding the following flag to the configure line in Litespeed:

--with-libdir=lib64

The reason being the build doesn’t know at this point that it is dealing with a 64-bit OS. If adding the above switch does not work, be sure to install the MySQL client and libraries.

That’s all folks!

Joe Break-Fix , , , , , ,

SSL Errors With Apache

October 16th, 2009

If you receive one of the following errors, it’s very possible the Apache process is listening on port 443 but is not responding using the SSL protocol routines. In brief it is a protocol mismatch. Here’s a list of possible errors:

Firefox error: SSL received a record that exceeded the maximum permissible length

Apache error log: \x80d\x01\x03\x01

Curl CLI error: curl: (35) error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol

The fastest way to recover from such error is to restore the most recent Apache configuration file from backup. If you do not have a backup copy, you will need to look at your virtualhost section associated with the domain and SSL port combination. Chances are it does not exist. In cPanel, this issue can be corrected with a simple run of the script rebuildhttpdconf as such:

/scripts/rebuildhttpdconf

After making the necessary changes, and whether you are running cPanel or not, you will need to stop Apache then restart it.

That’s all folks!

UNIXy Break-Fix , , , ,

Outlook SSL Certificate Issues After Changing Servers

August 24th, 2009

Outlook fails to login or retrieve emails after a server move. This is due to the SSL certificate on the new server confusing Outlook. This is especially important when the mail server name used in Outlook doesn’t change during the move. The solution is to reset or regenerate the email services certificates on the new server then restart outlook. Or you could also delete the certificate pertaining to the host name used in outlook (ex: mail.vpslux.com). If you are using cPanel on the server, you can reset the SSL certificate via WHM -> Manage Service SSL Certificates.

That’s all folks!

UNIXy Break-Fix , ,

Strace a process in Linux

August 9th, 2009

strace is a command line program that runs from one of the Linux shells. A shell is another program that allows a system administrator to interact with a Linux operating system – for example to run strace.

The strace utility is the crudest form of trouble shooting in Linux. It essentially hijacks the target program and traces all system function calls. Think of it as another program that attaches to the target program and snoops on its actions. The output of strace isn’t pretty either. One has to build a certain understanding and intuitiveness to make good use of it.

So how many times have you wondered what that Apache process is doing exactly pegging the CPU? Or how many times have you wondered why a certain PHP process dies unexpectedly? Well strace might help answer those questions. The strace output looks like this (don’t let this scare you. I’ll explain):


Process 6716 attached - interrupt to quit
restart_syscall(<... resuming interrupted call ...>) = 0
gettimeofday({1249790094, 207969}, NULL) = 0
open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_RDONLY) = 18
read(18, "ondemand\n", 1024) = 9
read(18, "", 1024) = 0
close(18) = 0
open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq", O_RDONLY) = 18
read(18, "1200000\n", 1024) = 8
read(18, "", 1024) = 0
close(18) = 0
read(3, 0x80708a4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1249790094, 209927}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}], 10, 0) = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"5\30\4\0\327W\300\2#\0\300\2S\0\27\0\233\4\5\0\330W\300"..., 520}], 1) = 520
read(3, 0x80708a4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
read(3, 0x80708a4, 4096) = -1 EAGAIN (Resource temporarily unavailable)
gettimeofday({1249790094, 212466}, NULL) = 0
poll([{fd=4, events=POLLIN}, {fd=3, events=POLLIN}, {fd=8, events=POLLIN|POLLPRI}, {fd=10, events=POLLIN|POLLPRI}, {fd=11, events=POLLIN|POLLPRI}, {fd=12, events=POLLIN|POLLPRI}, {fd=14, events=POLLIN|POLLPRI}, {fd=13, events=POLLIN|POLLPRI}, {fd=15, events=POLLIN|POLLPRI}, {fd=16, events=POLLIN|POLLPRI}], 10, 996) = 0
gettimeofday({1249790095, 208261}, NULL) = 0
open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_RDONLY) = 18

Each line in the above output represents an action made by the target program except the first two lines. The first one informs us that strace will begin tracing the program in question. The second one is made to recover from a half executed function system call.

The remaining lines are of importance and that’s what we need to study to figure what our target program is doing. Each line represents a function call the program is making and the result of the call. For example, this system call open

open("/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor", O_RDONLY) = 18

opens a file with certain attributes. The returned status is 18. What does the number 18 mean? What does O_RDONLY mean? RTFM! That is Read The Fine Manual! Linux comes with documentation tools that explain all these function calls and whatnot. In this example, open is the function. We can search for it and read its manual as such:

# apropos open
open (3posix) – open a file
# man 3 open

The manual page format can be cumbersome at first and it takes a bit of time to get used to it. Don’t let it discourage you! From reading manual we are able to understand more about the function call. Per the manual, return value 18 represents the “lowest numbered unused file descriptor.” We also understand what O_RDONLY means: Open file for reading only. Etcetera.

If you look back up at the strace output, you’ll note that shortly after the open() function call was made, close(18) followed it. We’ll need to go through the same process to read up on the system call close(). But the value 18 is deja vu! That’s the file descriptor number returned by open(). In other words, the program is opening a file /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor read-only then and then closing it.

We cannot go over each and every system call but you should be able to use the above process to understand pretty much any system call. But what would one be looking for when a program is not doing what it’s supposed to do and is failing? The Matrix sends agents after it to kill it! Just kidding! You have to go through each and every system call and check on the return status in the manual to understand if that is normal behavior or not. You can redirect the strace output to file so you can sift the (enormous) amount of data it produces:

strace -o /tmp/progra_strace.out -p

That’s all for today folks. I hope you enjoyed this one!

UNIXy Break-Fix , , , , , , , ,

Get rid of those injected iframes in index.html and index.php files

April 16th, 2009

In a perfect world, no one would need such a hack to clean up infected files. But as it is today, so much poorly-written software finds its way into people’s hands and Websites. All it takes is to fall behind by one minor release or sometimes a rare vulnerability to find yourself in hot water.

There are many ways one can end up with iframe-infected files. The most common reason is weak FTP / user passwords! If your password is too easy to guess or is weak, someone will definitely find it and use the password against to say upload modified public files with iframes in them. Another one is vulnerabilities in software you install on your Web server. For example, if you have an outdated version of Wordpress or Joomla, someone somewhere will exploit it and find a way to upload iframes throughout your files. So be on top of your software updates and create long and secure passwords!

Here’s a way to safely clean up your index.php, index.html, default.php, and all iframe-infected files in your public_html folder. Before you run this code against any files, please make a backup of your folder(s). Also, this fix won’t prevent the attacker from injecting the  iframes again unless you patch up the software / application and reset passwords.

So, if your index.html files are infected, simply run the following command against the directory that’s infected (but mostly public_html/):

# cd /home/username/public_html && find ./ \( -iname ‘index.html’ \)|while read file; do sed -i ’s/<iframe.*<\/iframe>//g;’ ${file}; done &

If you need to patch up multiple file names at once, for example index.html and index.php, add them as such (-o -iname newfilename.ext):

# cd /home/username/public_html && find ./ \( -iname ‘index.html’ -o -iname ‘index.php’ \)|while read file; do sed -i ’s/<iframe.*<\/iframe>//g;’ ${file}; done &

That’s all folks. I hope this helps someone somewhere. Feel free to post your comments or questions.

UNIXy Break-Fix