Recently I ran into a situation where an object (db conf) that was being called repeatedly via a web application ~100x more then any other cached item was being stored on one of four memcached servers. This item was stored as a flat file originally but had been implemented into a database which is how memcached came into play.

The excitement starts here, the four memcached servers were Dell 1950’s Dual Core Intel Xeon 2.0 GHz with 8 Gigs of RAM on each running Centos. Version of Memcached was 1.2.1. The particular object being cached ended up on a server as designed, however was being called by the web application a ~100x more then any other cached object and had a 5 minute expire. The particular memcached server with the object ended up taking a whopping 800+megabit/second in traffic, see the below graph:

*The reads and writes are reversed was the way cacti was set up.

The other server vitals at the time were:
CPU = 60%
Memcache Misses = 681 k/s
Memcache Hits = 1.16 M/s
Memcache Requests/sec (get&set) = 1.66 million
Server Load = 1.29

I haven’t ever had a single server reach passed 300 megabit in traffic first off so that was a new lesson of capacity and threshold. Also when memcached states it is not CPU intensive they really mean it. The server started crapping out meaning not serving requests properly at 780+megabit, so amazingly enough memcached can handle quite a lot of traffic/requests. Our switch port was saturated prior to memcached failing.

So lesson learned BEWARE what you cache when you are using memcached you don’t want to see the stats I did… Hope this helps with giving the community a case study of memcached out in the wild.

ShareThis

Let’s outline the benefits first regarding the mod_status module and what it allows you to see (Documented on Apache’s Site):

1) Number of children serving requests
2) Number of idle children
3) Status of each child, the number of requests that child has performed and the total number of bytes served by child
4) Total number of accesses and byte count served
5) Time the server was started/restarted and the time it has been running for
6) Averages giving the number of requests per second, the number of bytes served per second and the average number of bytes per request
7) Current percentage CPU used by each child and in total by Apache
8 ) Current hosts and requests being processed

*All which can be beautifully graphed using Cacti btw for historical analysis.

I find mod_status most useful for tuning settings when using a prefork configuration, balancing the server resources and application memory usage.

So the downfall of using mod_status is upon every request Apache will perform two calls to gettimeofday. These calls are done so that the status report contains timing information. The theory is that this information is taxing in retrieval and calculation.

So as a limited but real world test using a production server I administer, I discovered only a small impact with or without mod_status enabled.

The test was on a Dell 1950 Dual Core Intel Xeon 2.0 GHz 8 Gigs of RAM Linux with Apache 2.0

I considered server load decrease as the marker for success, in that I compiled Apache with and without mod_status and looked for differences in cpu usage, memory usage, and load stats. The Apache server in question received on average 18 requests per second, mostly API application calls through PHP. And the test lasted a week for each configuration.

I saw no differences even in the slightest in server memory, nor server cpu utilization. I did notice server load was on average .29 with mod_status in extended mode compiled, and average load was .20 without mod_status compiled. So a savings of .09 on average load for a server over the course of 1 week of testing with an average 18 requests per second was seen. Regarding actual http requests I saw no speed increase or decrease.

So my conclusion, is every little bit counts however if you find that you need to tune your Apache servers often given sporadic changes in usage, you may want to enable mod_status with extended status on and reap the benefits of graphing that data using a tool like Cacti for the greater good of tuning other aspects of Apache for a more significant gain.

ShareThis

mkdir /var/log/logins
chown youruser:youruser /var/log/logins

Create the below script and place it some where permissions 755:

#!/bin/sh
#
#The Below Directory Path is where the script will keep track of logins
BASE=/var/log/logins
#
# The two files below checked for a delta against each other
HISTORY=${BASE}/history
CURRENT=${BASE}/current
#
# Failure Function
fail()
{
echo “Failed: $*”
exit 1
}
#
# Function to clean output from the last command
clean_last()
{
/usr/bin/last | sed ‘{
/^reboot /d
/^$/d
/^wtmp begins /d
}’
}
MYGROUP=`id -gn`
MYIDENT=`id -un`
#
# Checking the env or error
[ -d ${BASE} ] || mkdir -p ${BASE}
[ -d ${BASE} ] || fail could not create ${BASE}
[ -G ${BASE} ] || fail ${BASE} not owned by ${MYGROUP}
[ -O ${BASE} ] || fail ${BASE} not owned by ${MYIDENT}
#
# Store current info
clean_last >${CURRENT}
# Is there a history file?
if [ -f ${HISTORY} ]
then
#
if ! `cmp –silent $CURRENT $HISTORY`
then
# Yes mail someone
#
diff $HISTORY $CURRENT |mail youremail@whatever.com -s “Login report”
fi
fi
#
# Make current history
#
mv ${CURRENT} ${HISTORY}
[ $? -eq 0 ] || fail mv ${CURRENT} ${HISTORY}
exit 0

#END OF SCRIPT

Create a crontab for your user to run the script:

*/5 * * * * /path/to/my/script/checklogin.sh

This should do it, gives a little more comfort, but I still recommend your typical safe guards IPTABLES, SNORT, etc… best practices.

ShareThis

The first script encrypts and pads data from a plaintext.txt file using Crypt::Blowfish into a ciphertext.txt file. The second script decrypts the cipher and writes it to a file.

blowfish.pl

#!/usr/bin/perl
use Crypt::Blowfish;
$key = ‘12345678123456781234567812345678′;
$cipher = Crypt::Blowfish->new($key);
open (PLAINTEXT, “plaintext.txt”);
while (read(PLAINTEXT, $block, 8)) {
$len   = length $block;
$size += $len;
# Add padding if necessary
$block .= “\000″x(8-$len) if $len < 8;
$ciphertext .= $cipher->encrypt($block);
}
# Record the size of the plaintext, so that the recipient knows how much padding to remove.
open (CIPHERTEXT, “>ciphertext.txt”);
print CIPHERTEXT “$size\n”;
print CIPHERTEXT $ciphertext;

decryptblowfish.pl

#!/usr/bin/perl
use Crypt::Blowfish;
$key = ‘12345678123456781234567812345678′;
$cipher = Crypt::Blowfish->new($key);
open (CIPHERTEXT, “ciphertext.txt”);
$size = <CIPHERTEXT>;
while (read(CIPHERTEXT, $ct, 8)) {
$pt .= $cipher->decrypt($ct);
 }
# Write only $size bytes of the output; ignore padding.
open (PLAINTEXT, “>decrypted.txt”);
print PLAINTEXT substr($pt, 0, $size);

ShareThis

vi ~/.bashrc

then activate your changes by sourcing it

source  ~/.bashrc

1) To display the username, short version of hostname, and the current working directory (light blue)

export PS1=’\[\033[1;34m\][\u@\h:\w]\$\[\033[0m\]‘

Output:

[phil@server1:/usr/local/bin]$

2) To display username, short version of hostname, date, time, and the current working directory

export PS1=’[\u@\h \d \A] \w \$ ‘

Output:

[phil@server1 Sat Jul 28 15:44] /usr/local/lib $

3) To display new line, username, short version hostname, base PTY, shell level, history number, new line, and the current working directory

export PS1=’\n[\u@\h \l:$SHLVL:\!]\n$PWD\$ ‘

Output:

[phil@server1 0:1:123]
/usr/local/bin$

4) To display, username, short version hostname, number of jobs in the background a new line and working path

export PS1=’\n[\u@\h jobs:\j]\n$PWD\$ ‘

Output:

[phil@server1 jobs:0]
/usr/local/bin$

ShareThis

server1# mkdir ~/.ssh

Step 2:

server1# cd ~/.ssh

Step 3:

server1# ssh-keygen -t rsa

Generating public/private rsa key pair.
Enter file in which to save the key (”your_local_home”/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in id_rsa.
Your public key has been saved in id_rsa.pub.
The key fingerprint is:
18:6a:e3:78:ab:2d:0c:8e:f9:67:f7:30:32:44:77:34 phil@server1

Step 4:

server1# scp ~/.ssh/id_rsa.pub phil@server2.philchen.com:/home/phil/id_rsa.server1.pub

Step 5:

server1# ssh phil@server2.philchen.com
Password:

Step 6:

server2# mkdir .ssh

Step 7:

server2# chmod 700 .ssh

Step 8:

server2# cat id_rsa.server1.pub >> .ssh/authorized_keys

Step 9:

server2# chmod 644 .ssh/authorzied_keys

Step 10:

server2# exit
server1# ssh phil@server2.philchen.com

*Note repeat steps 4-10 for all target servers you would like passwordless access from server1

* FYI Ensure your /home/user directory has the permission 755 also!

You should be all set!

ShareThis

Configuring MCrypt support for Mod_PHP can be a pain so hopefully this article will help!

The below was tested on a Centos 4.4 64 Bit server.

Package Dependencies:

libmcrypt-2.5.8.tar.gz
mhash-0.9.9
mcrypt-2.6.4
php-5.2.1.tar.gz

Installation Notes:

libmcrypt:

gunzip -c libmcrypt-2.5.8.tar.gz | tar xf -
cd libmcrypt-xxx
./configure –disable-posix-threads
make
make check (note: ‘make check’ is optional)
make install
added /usr/local/lib to ld.so.conf
ldconfig or LD_LIBRARY_PATH=/usr/local/lib
(Below is important)
cd libmcrypt-2.5.8/libltdl
./configure –enable-ltdl-install
make
make install

mhash:

ldconfig
gunzip -c mhash-0.9.9.tar.gz | tar xf -
cd mhash-xxx
./configure
make
make check (note: ‘make check’ is optional)
make install

mcrypt:

ldconfig
gunzip -c mcrypt-2.6.4.tar.gz | tar xf -
cd mcrypt
./configure
make
make check (note: ‘make check’ is optional)
make install

PHP:

gunzip -c php-5.2.1.tar.gz | tar xf -
./configure –with-apxs2=/usr/sbin/apxs –with-jpeg-dir=lib64
–BLAH –BLAH –BLAH –with-mcrypt=/path/to/mcrypt-2.6.4
(*NOTE the path of –with-mcrypt= install directory source code)
make
make install

This should get you up and running to use mcrypt!

ShareThis

########################################################
#!/bin/sh
# SAMPLE BASIC INIT SCRIPT
#
# Below is the chkconfig syntax for auto startup at different run levels
# Note runlevel 1 2 and 3, 69 is the Start order and 68 is the Stop order
# Make sure these are unique by looking into /etc/rc.d/*
# Also below is the description which is necessary.
#
# chkconfig: 123 69 68
# description: Description of the Service
#
# Below is the source function library
#
. /etc/init.d/functions
#
if [ -f /etc/sysconfig/BLAH ]; then
. /etc/sysconfig/BLAH
fi
#
# Below is the Script Goodness controlling the service
#
case “$1″ in
start)
echo -n “Start service BLAH”
/usr/sbin/BLAH start
;;
stop)
echo -n “Stop service BLAH”
/usr/sbin/BLAH stop
;;
restart)
echo -n “Restart service BLAH”
/usr/sbin/BLAH restart
;;
*)
echo “Usage: $0 {start|stop|restart}”
exit 1
;;
esac
######################################################

Now to run chkconfig commands:

bash-3.00$ chkconfig BLAH –add

bash-3.00$ chkconfig BLAH on

The above will read the Init script and add and enable the script at the proper run level
specified in the script. Appending the start command on boot.

You could also do the below to be more specific in which run level to enable:

bash-3.00$ chkconfig –level 123 BLAH on (to turn on at run level 1 2 3)

or

bash-3.00$ chkconfig –level 123 BLAH off (to turn off at run level 1 2 3)

To list all run:

bash-3.00$ chkconfig –list

This should be a quick and dirty to get you going.

ShareThis

To run string substitution globally to the target file you can do the following:

perl -pi -e ’s{original string}{replacement string}g’ targetfile

To run string substitution globally to the multiple files in the directory you can do the following:

perl -pi -e ’s{original string}{replacement string}g’ *

ShareThis

shellprompt$ vi test-1.txt

while in VI enter the following

:new

This will open a new split screen session, in order to navigate between the two windows in VI do the following

<ctrl-w>
j

Or

<ctrl-w>
k

Using the first will move you to the lower window and using the latter will move you to the upper window.

To make one of the windows full screen and out of the dual screen mode use the following

:only

*Important Side Notes

If you used :new and opened up a new window session it will not have a name so you cannot save it without entering the following

:wq whatevername.txt

Also if you want to open a file in split screen mode that is not new and exists you can enter the following

:new /path/to/whateverfile

Happy Editing!

ShareThis