Home

sandip's blog

Importing existing SSL key and certificate for tomcat

Fri, 07/25/2008 - 16:50 — sandip
  1. Convert key and cert to a single pkcs12 format.

    openssl pkcs12 -export -inkey <pathto>/key.txt -in <pathto>/cert.txt -out cert.pkcs12

  2. Remove existing tomcat aliased PrivateKeyEntry from cacerts.

    keytool -delete -alias tomcat -keystore <pathto>/cacerts

  3. Use java-1.6 keytools to import PKCS12 keystoretype into existing cacerts keystore file.

    keytool -importkeystore -destkeystore cacerts -srckeystore cert.pkcs12 -srcstoretype PKCS12

  4. Note the alias of the newly imported PrivateKeyEntry, which would normally be 1.

    keytool -list -keystore <pathto>/cacerts | grep PrivateKeyEntry

  5. Change the alias to tomcat.

    keytool -changealias -alias 1 -destalias tomcat -keystore <pathto>/cacerts

Simple captcha for oscommerce contact form

Thu, 07/24/2008 - 21:52 — sandip

Embed the captcha image by calling a php script in "contact_us.php":

<input type="text" name="verify" />
<img src="/image.php" width="60" height="20" alt="Please enter the values from this image" />

Edit contact_us.php file and exactly after the below line:

  if (isset($HTTP_GET_VARS['action']) && ($HTTP_GET_VARS['action&#039;] == 'send')) {

place the verification code:

        // Captcha check
    &nbsp;   $t = trim($HTTP_POST_VARS['verify']);
    &nbsp;   if ($t == "") {
    &nbsp;    &nbsp;    &nbsp; $captcha_error = "Enter the verification code!";
    &nbsp;    &nbsp;    &nbsp; $error = true;
    &nbsp;    &nbsp;    &nbsp; $messageStack->add('contact', $captcha_error);
    &nbsp;   } else if (trim($_SESSION["thecode&quot;]) == "") {
    &nbsp;    &nbsp;    &nbsp; $captcha_error = "No verification code generated!";
    &nbsp;    &nbsp;    &nbsp; $error = true;
    &nbsp;    &nbsp;    &nbsp; $messageStack->add('contact', $captcha_error);
    &nbsp;   } else if ($_SESSION["thecode"] != strtoupper($t)) {
    &nbsp;    &nbsp;    &nbsp; $captcha_error = "Invalid verification code!";
    &nbsp;    &nbsp;    &nbsp; $error = true;
    &nbsp;    &nbsp;    &nbsp; $messageStack->add('contact', $captcha_error);
    &nbsp;   }
    &nbsp;   else
    &nbsp;   { // End Captcha Check

Support for 32 bit development libraries on 64 bit CentOS

Fri, 07/18/2008 - 09:45 — sandip

To support C/C++ 32 bit development libraries on CentOS-5.2 x86_64 arch the below devel packages are required:

yum install glibc-devel.i386 libstdc++-devel.i386

Below is example output of multilib support for gcc:

$ gcc -print-multi-lib; gcc -print-multi-os-directory; gcc -print-multi-os-directory -m32
.;
32;@m32
../lib64
../lib

Create users in OpenVZ Containers

Fri, 07/11/2008 - 00:35 — sandip

Helper script to create users on all OpenVZ VEs simultaneously:

#!/bin/bash
# create_ve_users.sh
# Usage: ./create_ve_users.sh <username> <password> <uid> <group1,group2>

USERNAME=$1
PASSWORD=$2
USERID=$3
GROUP=$4
EXPECTED_ARGS=4

OUT_FILE=.create_users_$$ />
if [ $# -ne $EXPECTED_ARGS ]
then
  echo "Usage: `basename $0` <username> <password> <uid> <group1,group2>" />  exit 65
fi

VE_LIST=$(/usr/sbin/vzlist -H -o veid)

for VE in ${VE_LIST}
do
    &nbsp;   vzctl exec $VE \
    &nbsp;    &nbsp;    &nbsp; "echo useradd -u $USERID -G $GROUP -p \''`openssl passwd -1 $PASSWORD`'\' $USERNAME > /tmp/${OUT_FILE} ; \
    &nbsp;    &nbsp;    &nbsp; sh /tmp/${OUT_FILE} ; \
    &nbsp;    &nbsp;    &nbsp; rm -f /tmp/${OUT_FILE}"
done

exit 0

Update OpenVZ containers

Wed, 07/09/2008 - 16:51 — sandip

If you manage several OpenVZ containers, here is a simple bash script to keep the OpenVZ containers upto date.

#!/bin/bash
# vzyum_updates.sh
# updates VEs

VE_LIST=$(/usr/sbin/vzlist -H -o veid | grep -v Warning)

for VE in ${VE_LIST}
do
  /usr/bin/vzyum $VE update
done

exit 0

OpenVZ CentOS template cache creation with vzpkgcache

Mon, 07/07/2008 - 23:44 — sandip

Following the instruction over at OpenVZ Wiki, I've had no problems with the installation and creation of templates prior to CentOS-5.2 on x86_64 systems. However, with the latest set of updates to CentOS-5.2, the vzpkgcache seems to have been broken as sysklogd is no longer being installed by default. Below is how I got it to work:

Note: edit /vz/template/centos/5/x86_64/config/minimal.list and append .x86_64 to all except for the addons packages. Then run:

# vzpkgcache -f centos-5-x86_64-minimal

which gives the below error at the end:

sed: can't read /etc/init.d/syslog: No such file or directory
ERROR: Script install-post failed

The solution was to edit "/vz/template/centos/5/x86_64/config/install-post" and set syslog and syslog.conf sed replacements with exit status of "0".

# Disable klogd
$VZCTL exec2 $VEID \
    &nbsp;   "sed -i -e 's/daemon\\ klogd/passed\\ klogd\\ skipped/' \
    &nbsp;    &nbsp;    &nbsp; -e 's/killproc\\ klogd/passed\\ klogd\\ skipped/' \
    &nbsp;    &nbsp;    &nbsp;    &nbsp;    /etc/init.d/syslog; exit 0"
...
# Disable fsync() in syslog
$VZCTL exec2 $VEID \
    &nbsp;   "sed -i -e 's@\\\([[:space:]]\\\)\\\(/var/log/\\\)@\\\1-\\\2@'; \
    &nbsp;    &nbsp;    &nbsp; /etc/syslog.conf; exit 0"

Reducing logical volume

Thu, 07/03/2008 - 09:56 — sandip

I've had to reduce the logical volume that was alloted for mysql data from 8GB to 4GB, which was a breeze with e2fsadm available for lvm1 on RHEL-3 .

Stop the running serivces using the volume:

# service httpd stop
# service mysqld stop

e2fsadm will reduce the filesystem and then the logical volume.

# umount /mnt/lv-mysql
# e2fsadm -L -4G /dev/hdb2-vg00/lv-mysql
# mount /mnt/lv-mysql

Check with df, which should now show the new volume size:

$ df -h /mnt/lv-mysql
Filesystem              Size  Used Avail Use% Mounted on
/dev/hdb2-vg00/lv-mysql 4.0G  531M  3.3G  14% /mnt/lv-mysql

Start the running serivces using the volume:

# service httpd start
# service mysqld start

Note: e2fsadm is not available in lvm2 and will need to reduce in two steps:

1. Reduce the filesystem residing on the logical volume.
2. Reduce the logical volume.

# resize2fs /dev/vg0/lv0 4G
# lvreduce -L -4G /dev/vg0/lv0

ffmpeg with mp3 encoder support on Ubuntu Dapper

Wed, 07/02/2008 - 00:26 — sandip

The default install of ffmpeg on Ubuntu Dapper does not come with support for encoding mp3. I had to get the source and re-compile with mp3 support using lame as the encoder.

Make sure you have multiverse and universe enabled.

$ sudo apt-get build-dep ffmpeg
$ sudo apt-get install liblame-dev libfaad2-dev libfaac-dev libxvidcore4-dev liba52-0.7.4 liba52-0.7.4-dev libx264-dev
$ apt-get source ffmpeg
$ cd ffmpeg-*/
$ ./configure --enable-gpl --enable-pp --enable-pthreads \
    &nbsp;   --enable-libogg --enable-a52 --enable-dts \
    &nbsp;   --enable-dc1394 --enable-libgsm --disable-debug --enable-mp3lame \
    &nbsp;   --enable-faad --enable-faac --enable-xvid --enable-x264
$ make
$ sudo make install

APF on CentOS-5 OpenVZ Containers

Tue, 06/24/2008 - 12:00 — sandip
  1. Increase the NUMIPTENT values in VE conf file to 1000 on the host:
    NUMIPTENT="1000:1000";
  2. Edit "/etc/sysconfig/vz" on the host:
    IPTABLES="ipt_REJECT ipt_tos ipt_TOS ipt_LOG ip_conntrack ip_conntrack_ftp ip_conntrack_irc ipt_owner ipt_length ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state iptable_nat ip_nat_ftp ipt_recent"
  3. Make sure the above modules are loaded on the host, so it would help if you have APF on the host as well.
  4. Restart the VE
    # vzctl restart <VEID>
  5. It is normal to get ipt_recent error as below:
    Warning: Unknown iptable module: ipt_recent, skipped

    You can verify the modules loaded via:

    # vzctl exec <VEID> grep ipt_recent /proc/net/ip_tables_matches

    Note: ipt_recent is required for passive ftp to work, else... will need to specify passive ftp ports in ftp conf file and open those ports via apf as well.

  6. Here is a typical apf config on a VE with CentOS-5 running ISPConfig.

    DEVEL_MODE="0"
    IFACE_IN="venet0"
    IFACE_OUT="venet0"
    IFACE_TRUSTED=""r />SET_MONOKERN="1"r />IG_TCP_CPORTS="21,22,25,53,80,81,110,143,443" />IG_UDP_CPORTS="53"
    EGF="1"
    EG_TCP_CPORTS="21,25,80,443,43"
    EG_UDP_CPORTS="20,21,53"

Trusting CAS Self-signed Certs

Mon, 06/23/2008 - 11:24 — sandip

Yales' CAS client attempts to verify the service ticket it received from CAS, and when it tries to connect to the CAS server, it encounters SSL handshake error caused by using a self-signed SSL certificate on the CAS server. The Java process running tomcat does not trust the certificate presented by the CAS server. This is part of Java security.

A work around the issue would be to tell Java to trust the self-signed certificate as below:

# keytool -importcert -trustcacerts -alias {cert_alias_name} -file \
    &nbsp;     /path/to/self-signed.cer -keypass changeit -keystore  \
    &nbsp;     /usr/local/java/jre/lib/security/cacerts

Use the below command to list:

$ keytool -list -keystore /usr/local/java/jre/lib/security/cacerts | grep -A 1 {cert_alias_name}

Comment