How to Remove ^M Character

admin    Linux     add-on, bad interpreter, caret, check_summary, cluster, dos line break, dos2unix, edit, editor, fix, Linux, M, nagios, plugin, remove, replace, search, troubleshoot, vim, windows

There are a lot of other systems out there other than Linux, so if you have a file from, let’s say a DOS system, with extra ^M (caret M) characters at the end, you can correct it using vi. The tough part is, you will not be able to see these extra characters immediately, unless you encounter something like this:

$ ./check_summary.pl --help
-bash: ./check_summary.pl: /usr/bin/perl^M: bad interpreter: No such file or directory

(Note: check_summary is a Nagios plugin that I am currently testing.)

See the ^M character at the end? It is called the DOS line break. Unfortunately, Linux is not able to recognize these line breaks so you have to delete them. With vim. Yes, with vim, or with any editor you want, but in this post, I will show how to do it in vi.

First, open up your file where there is an extra ^M characters. While in command mode, type the following:

:%s/^V^M//g

The ^V is a CONTROL+V character and ^M is a CONTROL+M. When you type this, it will look like this:

:%s/^M//g

This command searches for ^M character (the CONTROL+V escapes a control character) the replaces it with null. After doing this, save and exit.

Another way to fix this is to use the dos2unix command like so:

$ dos2unix [file]

This might work, but I have not tried yet. Have you tried using dos2unix? Did it work? Let me know in the comments section.

Strict Standards: date() [function.date] Error

admin    Linux, Troubleshooting     apache, compile, configuration, date, error, fix, Linux, nagios, nagvis, ntpd, php, php.ini, red hat, rhel, sles, source, standards, strict, suse, time zone, timezone, utc, warning

I was installing NagVis when I came across this weird message:

Strict Standards: date() [function.date]: It is not safe to rely on the system’s timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected ‘UTC’ for ‘GMT/0.0/no DST’ instead in /usr/local/nagios/nagvis/nagvis/includes/classes/objects/NagVisStatefulObject.php on line 360

It clearly says that I should check the timezone, which I did. But there’s nothing wrong with time or date. ntpd is running and it set the correct timezone so what could be wrong?

If you are reading this then probably you are seeing this error too. To fix this, open your php.ini using your favourite text editor (like vi) and add this line:

date.timezone=UTC

Take note that depending on how you installed php, it could be in /etc/php.ini (RedHat) or /etc/php5/apache2/php.ini (SLES) or if compiled, /usr/local/php5/php.ini.

You need to restart Apache for changes to take effect.

Sudo error: Sorry, you must have a tty to run sudo

Rai    Linux     configuration, error, fix, Linux, permission, rsync, sudo, troubleshoot, tty, user, visudo

From time to time, we perform remote actions on the servers that we manage, including, but not limited to, automated file transfers. For this, rsync is used to simplify the operation and until recently, I encountered this weird error:

sudo: sorry, you must have a tty to run sudo

But where on this bloody earth did that error came from? All was going well until a new server was added to the pool of money-making machines and powerful enough to throw me off guard. This can’t be happening! I own these machines, I built them from scratch and configured them exactly the way I built the other servers! I could not be any wrong-er, the server must be leading an uprising against me!

Okay, that was an exaggeration (or paranoia). But it is true that the server has the same configuration as the rest. Except for one little line of default configuration:

Defaults requiretty

Comment out this line in visudo (must be root to edit) and everything should checkout.

How to Fix PECL PHP Error: /bin/sh: bad interpreter: Permission denied

Rai    Linux     bash, denied, error, fix, how, interpreter, Linux, pear, pecl, permission, php, red hat, server, xdebug

I recently tried installing xdebug on a RHEL 4 machine, and somehow, the server decided that it should refuse having xdebug installed. As if running a heavy Java app is not enough, I decided to add more processes for the server to run. And it looks like the server has got me:

[root@server src]# pecl install xdebug
downloading xdebug-2.0.5.tgz ...
Starting to download xdebug-2.0.5.tgz (287,621 bytes)
.............done: 287,621 bytes
12 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20060613
Zend Extension Api No:   220060519
/usr/local/bin/phpize: /tmp/pear/temp/xdebug/build/shtool: /bin/sh: bad interpreter: Permission denied

So, like I always do, I tackle the problem with my handy tool: Google. I found out that this error occurs when /tmp is mounted as read-only (ro). You can check this by looking at the /etc/fstab file and check the /tmp partition.

Okay, now I know what the problem is. How do I get over this?

Lazy that I am, I moved the /tmp/pear directory, and create a symlink to the root directory.

[root@server src]# mv /tmp/pear /tmp/pear-ori
[root@server src]# mkdir /root
[root@server src]# ln -s /tmp/pear /root/tmp/pear

Now that the directory from where the PECL scripts are running is in /root, the installation should go smoothly.

Another way to go around this is to remount the /tmp:

[root@server src]# mount -oremount,exec /tmp

I have not tried the above command because I thought that creating symlink is a safer approach rather than messing with the mounts.

If there are other ways to fix this, let me know using the comment box below.

PHP JSON Module Bug Fix

Rai    Linux     bug, compile, download, fix, json, module, php, source

If you are encountering any weird stuff with your PHP-JSON module installation, you might want to reinstall JSON using this link, this might get rid of the bug that is pestering you and your application.

First, uninstall any previous JSON installation you have so as not to conflict with the new one. To make sure you got the old JSON out, check your list of PHP modules by running:

php -m

JSON should not be listed and make sure you do not see any errors either. Doing this will prevent further headaches, trust me.

Perform the following steps to install the bug-free version of JSON from source:

1. Download the JSON source from here. You can use wget to download the source if you are using CLI

wget http://aurore.net/projects/php-json/php-json-ext-1.2.1.tar.bz2

2. Uncompress the archive and change directory.

tar jxf php-json-ext-1.2.1.tar.bz2
cd php-json-ext-1.2.1

3. Run phpize. Make sure that phpize is installed before proceeding to this step. phpize is included in the php-devel package.

phpize

4. Configure, make and make install

./configure
make
make install

JSON is now installed, but make sure that json.so is loaded in your php.ini file.

1. Open php.ini file. If you are unsure about the location of your php.ini file, run

php -i | grep php.ini

You should see something like this:

Loaded Configuration File => /etc/php.ini

2. Add this at the last line of the configuration file:

extension=json.so

3. You might want to restart Apache to make sure everything is still working.

To check if JSON is loaded as module, run php -m again, make sure JSON is in the list.

Now, to test JSON, open an editor and copy these lines:

< ?php
$input = '{ "test" : 12121211212121 }';
$val = json_decode($input, true);
print $val["test"];
?>

Save the file (json-test.php is the filename in this case).

Execute the file by running php json-test.php

The result should be 12121211212121