Couple of more bash commands…

Get your external IP address and other infos…
curl -> IP Adress
curl -> Remote Host
curl ->User Agent
curl -> Port

intercept stdout/stderr of another process
strace -ff -e trace=write -e write=1,2 -p SOME_PID

Delete all files in a folder that don’t match a certain file extension
Deletes all files in a folder that are NOT *.foo, *.bar or *.baz files. Edit the pattern inside the brackets as you like.
rm !(*.foo|*.bar|*.baz)

How to kill an unresponsive ssh session


I often find myself in the somewhat cumbersome situation that a currently running ssh session stops responding, often due to a lost connection. The normal ctrl+c of course doesn’t work, the ssh client catches all the usual commands, which is very handy while you are still connected to the host but not very handy at all in this case.

My usual approach has been to switch to another terminal window or shell and then killing the process in question. Today I happened to be skimming through the ssh client’s man page and I found a section about escape characters. Suddenly I gazed upon the glory of the disconnect key sequence: a newline followed by ~.. It works like a charm. As always, I thought I should share.

tar.gz comamnds

.tar.gz – Archiving and Extracting files

Create a .tar.gz file from a folder:

tar czf /path/to/output/folder/filename.tar.gz /path/to/folder

Extract a .tar.gz file:

gunzip -c /path/to/folder/filename.tar.gz

View a list of all files in a .tar.gz archive:

gunzip -c /path/to/folder/filename.tar.gz | tar -tvf -

Extract a single file from a .tar.gz file:

gunzip -c /path/to/folder/filename.tar.gz | tar -xvf - path/within/archive/filename.php

Use a ninja to help protect your server

From and

Ninja is a privilege escalation detection and prevention system for GNU/Linux hosts. While running, it will monitor process activity on the local host, and keep track of all processes running as root. If a process is spawned with UID or GID zero (root), ninja will log necessary information about this process, and optionally kill the process if it was spawned by an unauthorized user.

A “magic” group can be specified, allowing members of this group to run any setuid/setgid root executable.

Individual executables can be whitelisted. Ninja uses a fine grained whitelist that lets you whitelist executables on a group and/or user basis. This can be used to allow specific groups or individual users access to setuid/setgid root programs, such as su(1) and passwd(1).

How to Ninja and How to Ninja – Ubuntu 10.04 by bodhi.zazen

Read the online man page here.

0.1.3 – ChangeLog

Source repository

Ninja is released under the General Public License (GPL) version 2 or higher

Download ninja from – here
Untar the source, goto the ninja directory and type following command to compile and install the ninja:

make install

copy the white-list file to the /etc/ninja directory

cp examples/whitelist/simple.wlist /etc/ninja/

Add group “ninja” (note down the group id):

groupadd ninja

Add user ‘root’ and all other required users to this group:

usermod -G ninja nikesh
usermod -G ninja root

Create the ninja log files:

touch /var/log/ninja.log

Open the ninja configuration file:

vi /etc/ninja/default.conf

and change the following settings

daemon = yes
interval = 0
logfile = /var/log/ninja.log
whitelist = /etc/ninja/simple.wlist
external_command = /root/bin/alert

Here you also need to create a simple script alert (/root/bin/alert) with following entries

echo 'Alert - Unauthorized Access to system.' | mail -s "'Alert - Unauthorized Access to system."

Edit the whitelist file located under the


The first field is the full path to the executable you wish to white-list. The second field is a comma separated list of groups that should be granted access to the executable. The third field is a comma separated list of users.


The second or third field can be left empty. Please refer to the example whitlist located in “examples/whitelist/”.

Remember that it is a good idea to whitelist programs such as passwd and other regular setuid applications that users require access to.

Finally start ninja using following command:

/usr/local/bin/ninja /etc/ninja/default.conf

Testing Ninja:
Create a test user ‘test’
Login to the system using this test user
now attempt to become ‘root’ user by typing command ‘su – ‘
Here ninja will come into action and will kill the entire session and dump the information into the log

3 nameserver for Europe… Yea

European countries are now requiring three nameservers. I have dug up the information about it so we all know.

When reports are run, they recommend the following:

“You have multiple nameservers. According to RFC2182 section 5 you must have at least 3 nameservers, and no more than 7”

I went and looked up RFC2182 section 5 and got its exact wording pertaining to three namservers or more issue. The RFC states:
“It is recommended that three servers be provided for most organization level zones, with at least one which must be well removed from the others.”

Basically the European countries have started enforcing three nameservers, but only one of which is required to be in a separate class C range. This should clear up any unanswered questions regarding this.

Cpanel protect directories thing

Ran across a silly issue the other day while trying to password protect a couple of subdirectories. After I setup the folder above the 2 subdirectories, it worked fine. I did the exact same setup and was unable to login, slaved at this for about an hour with no productive results.

I Finally broke down and contacted cpanel, which promptly told me I was a senseless slag with no hope of my knuckles ever leaving the ground…

well, not really, they actually answered me with 5 minutes and said there needed to be index files in the directories in the folders before the password protection would work.


In working with cpanel for the last 10+ years, I have never come across this issue… I learn something from them everyday… I love those guys…

Centos issue with plesk

A recent CentOS update is evidently causing issues with the plesk daemon. I ran afoul of it when I discovered that plesk would not start up after being shut down.

The daemon will be running fine, but will break on the next restart. I imagine this may affect all plesk servers until plesk pushes out the update from their end.

Signs of issue:
2010-03-29 11:31:29: (log.c.75) server started
2010-03-29 11:31:29: (network.c.336) SSL: error:00000000:lib(0):func(0):reason(0)

Relevant Plesk KB link with fix: