Config Subversion & LDAP & Apache on ubuntu

Install subversion and apache2 with the SVN module:

apt-get install subversion
apt-get install apache2 libapache2-svn

Enable the SVN Apache module:

a2enmod authnz_ldap

Since I use a self-signed certs and I’m too lazy to install my SSL chain, I have to turn off Apache’s checks (you may not want to do this). Add to the end of /etc/apache2/apache2.conf:

LDAPVerifyServerCert Off

After troubleshooting, you need to set this in your /etc/ldap/ldap.conf file to avoid errors similar to “[warn] [client x.x.x.x] [636] auth_ldap authenticate: user foo authentication failed; URI /secret [ldap_search_ext_s() for user failed][Operations error]”


Now, you need to add it to your apache2 configuration so that you can access it via http. You will need to edit this to suit your own needs, I hope it’s relatively self-explanatory, but I’ve made some comments in red. Add this after your last </directory>  statement:

DAV svn
SVNParentPath /data/svn # Your SVN repository data
SVNListparentPath on
SVNAutoversioning On
AuthType Basic
AuthBasicProvider ldap
AuthzLDAPAuthoritative on
AuthName "svn"
AuthUserFile /dev/null
AuthLDAPURL "ldaps://DOMAINCONTROLLER/DC=domain,DC=com?sAMAccountName?sub?(objectClass=*)" # You want this pointed at your base DN. Also, some (even most) of you may not be running LDAPS (SSL LDAP) # you may need to change this to ldap://.
AuthLDAPBindDN "DOMAIN\User" # Any user will do, since by default Windows allows any user to query active directory for auth. I suggest making a separate user for just this.
AuthLDAPBindPassword Password
AuthLDAPGroupAttributeIsDN on
AuthLDAPGroupAttribute member
Require ldap-group cn=svn,ou=securitygroups,ou=IT,dc=domain,dc=com # This is optional, but allows you to limit SVN access to a specific group.

#Once you're done, it's time to create your first repository:

svncreate /data/svn firstrepository

Now you need to change the owner to www-data so apache2 can read/write it:

chown -R www-data svn
chgrp -R www-data svn
chmod -R g+rws svn

Installing and configuring mod_jk

Installation of Mod_jk is not that hard but to make it work or integrate with apache and tomcat a bit tricky. I am explaining here how to install and configure apache to serve the java pages or webapps with the help of mod_jk module.

Let me brief my scenario here, yours may be different. You can take the refference from here. I am having app1 and app2 and i want URL to serve the pages from app1 tomcat webapp and serve the pages from app2 tomcat webapp. Also you need to take care for the tomcat port also, if you want to use two tomcat instace you you have to use the two diff ports like i am using. app1 is on 8080 port and app2 is on 8081 port.

You can install apache and tomcat via yum if you are using Redhat/CentOS distro and if you are using any Debian based system you can use apt-get/aptitude utility for the same.
I am explaining here on CentOS-5.4 disto

#yum install httpd
#/etc/init.d/httpd restart
#chkconfig httpd on

Now its time to install mod_jk, i am using here the rpm package you can even compile it from source as well.
You can download it from centOS testing repo.


#rpm -ivh mod_jk-ap20-1.2.26-1jpp.i386.rpm or
#rpm -ivh  mod_jk-ap20-1.2.28-2.el5.centos.i386.rpm

Now its time to install tomcat. You can install it via yum or compile it from source. I am using the source here.

Get the tar.gz for Tomcat 5.5 — you can download it from the Apache Tomcat download site( I am using tomcat-5.5 version you can use the latest release also.

Unpack apache-tomcat-5.5.23.tar.gz under /usr/local. Rename apache-tomcat-5.5.23 to tomcat8080. Unpack the tar.gz one more time, rename it to tomcat8081.

cd /usr/local/tomcat8081/conf
- edit server.xml and change following ports:
8005 (shutdown port) -> 8006
8080 (non-SSL HTTP/1.1 connector) -> 8081
8009 (AJP 1.3 connector) -> 8010

There are other ports in server.xml, but I found that just changing the 3 ports above does the trick.

I won’t go into the details of getting the 2 Tomcat instances to run. You need to create a tomcat user, make sure you have a Java JDK or JRE installed, etc., etc.
One more thing i want to mention here, you have to set JAVA_HOME variable set to make the java application to find the exact JRE/JAVA location. If you want to set them system wide then mention that variable in /etc/profile file instead if ‘export’ on shell.

The startup/shutdown scripts for Tomcat are /usr/local/tomcat808X/bin/|

I will assume that at this point you are able to start up the 2 Tomcat instances. The first one will listen on port 8080 and will have an AJP 1.3 connector (used by mod_jk) listening on port 8009. The second one will listen on port 8081 and will have the AJP 1.3 connector listening on port 8010.

I am assuming that you are well aware, how to deploy the tomcat apps.So i am skipping that section. Please write me at if you want to have a chapter on this as well.

Create Apache virtual hosts for and and tie them to the 2 Tomcat instances via mod_jk.

Here is the general mod_jk section in httpd.conf — note that it needs to be OUTSIDE of the virtual host sections:

# Mod_jk settings
# Load mod_jk module
LoadModule    jk_module  modules/
# Where to find
JkWorkersFile conf/
# Where to put jk logs
JkLogFile     logs/mod_jk.log
# Set the jk log level [debug/error/info]
JkLogLevel    emerg
# Select the log format
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
# JkOptions indicate to send SSL KEY SIZE,
JkOptions     +ForwardKeySize +ForwardURICompat -ForwardDirectories
# JkRequestLogFormat set the request format
JkRequestLogFormat     "%w %V %T"

Note that the section above has an entry called JkWorkersFile, referring to a file called, which I put in /etc/httpd/conf. This file contains information about so-called workers, which correspond to the Tomcat instances we’re running on that server. Here are the contents of my file:

# This file provides minimal jk configuration properties needed to
# connect to Tomcat.
# The workers that jk should create and work with

worker.list=app1, app2



The file declares 2 workers that I named app1 and app2. The first worker corresponds to the AJP 1.3 connector running on port 8009 (which is part of the Tomcat instance running on port 8080), and the second worker corresponds to the AJP 1.3 connector running on port 8010 (which is part of the Tomcat instance running on port 8081).

The way Apache ties into Tomcat is that each of the VirtualHost sections configured for and declares a specific worker. Here is the VirtualHost section I have in httpd.conf for

DocumentRoot "/usr/local/tomcat8080/webapps/ROOT"

  # Options Indexes FollowSymLinks MultiViews
  Options None
  AllowOverride None
  Order allow,deny
  allow from all

ErrorLog logs/app1-error.log
CustomLog logs/app1-access.log combined
# Send ROOT app. to worker named app1
JkMount  /* app1
RewriteEngine On
RewriteRule ^/(images/.+);jsessionid=\w+$ /$1

The 2 important lines as far as the Apache/mod_jk/Tomcat configuration is concerned are:

JkMount /* app1

The line “JkMount /* app1″ tells Apache to send everything to the worker app1, which then ties into the Tomcat instance on port 8080.

The line “JkUnMount /images/* app1″ tells Apache to handle everything under /images itself — which was one of our goals.

At this point, you need to restart Apache, for example via ‘sudo service httpd restart’. If everything went well, you should be able to go to and and see your 2 Web applications running merrily.

You may have noticed a RewriteRule in each of the 2 VirtualHost sections in httpd.conf. What happens with many Java-based Web application is that when a user first visits a page, the application does not know yet if the user has cookies enabled or not, so the application will use a session ID mechanism fondly known as jsessionid. If the user does have cookies enabled, the application will not use jsessionid the second time a page is loaded. If cookies are not enabled, the application (Tomcat in our example) will continue generating URLs such as;jsessionid=0E45D13A0815A172BD1DC1D985793D02

In our example, we told Apache to process all URLs that start with ‘images’. But those URLs have already been polluted by Tomcat with jsessionid the very first time they were hit. As a result, Apache was trying to process them, and was failing miserably, so images didn’t get displayed the first time a user hit a page. If the user refreshed the page, images would get displayed properly (if the user had cookies enabled).

The solution I found for this issue was to use a RewriteRule that would get rid of the jsessionid in every URL that starts with ‘images’. This seemed to do the trick.

That’s about it. I hope this helps somebody

How to install LAMP on CentOS 6 server

You can check yum by running


yum update

Now if everything went well with yum, lets setup the hostname of the server – in case you didn’t already.
First check the current short hostname with


command, then you can try the same command with


switch to show the FQDN (fully qualified domain name) version of the hostname.
In case you have to setup the hostname you can perform the following steps:
Edit /etc/sysconfig/network and add this


Or run the following command:

echo "HOSTNAME=yourhostname.tld"

Now run

 hostname "yourhostname.tld"

and you are done setting your hostname.
Re check with



hostname -f

Now lets install the Apache web server. This is the most popular choice today among web browsers and usually it is the best solution combining easy configuration, wide compatibility, stability, maturity of the platform and performance.
Do not forget to run

yum update

unless you listened and already did that at the first stages fot this tutorial.
After the update run:

yum install httpd

Now make backup for the original Apache configuration file, usually this backup is not needed but in case you will need to restore the default configuration you will be glad you have it.
Backup the configuration by running:

mkdir /yournewconfbackupdir
cp /etc/httpd/conf/httpd.conf /yournewconfbackupdir/httpd.conf.original

It is a very recommended practice to backup configuration files before you edit and save the changes. Takes only one simple command to do it just as it will take another simple command to restore the configuration backup in case of multiple mistakes in configuration file on a production server leading to long downtime until you will find the mistakes in the configuration. It is much simpler to restore the file from backup and shortening the downtime to mere seconds instead of minutes or tens of minutes.

Now we will use this directory /etc/httpd/conf.d/ – Apache threats any files with .conf extensions in this path as its configuration files and it will load any such file on start or reload.
I’m going to to show you how to create Name based Virtual Hosts in /etc/httpd/conf.d . There are different approaches to this but personally I’ve always preferred to create Virtual Hosts as different configuration files in the conf.d directory, you can of course make one configuration file and include all your virtual hosts in this file. In this example I will show how to divide the configuration to separate files.
So for example you would like to create a virtual host for domain, what you are going to do is to create a new file in /etc/httpd/conf.d/:

 touch /etc/httpd/conf.d/

Now you are going to edit this file and add the configuration itself:

     DocumentRoot /http/www/
     ErrorLog /http/www/
     CustomLog /http/www/ combined

Now you have to create the directories we specified in the configuration:

mkdir -p /http/www/
mkdir /httpd/www/

Before you can start apache and test the configuration you have to edit


the same file you backed up at the beginning of this tutorial. Find the part with name-based Vritual Host and uncomment NameVirtualHost directive:

# Use name-based virtual hosting.
NameVirtualHost *:80
# NOTE: NameVirtualHost cannot be used without a port specifier
# (e.g. :80) if mod_ssl is being used, due to the nature of the
# SSL protocol.

Now you can try to start Apache for the first time:

service httpd start


/etc/init.d/httpd start

If the service is already running just use restart instead of start.
After you tested everything and you are sure about the configuration you can add the Apache (httpd) service to the system start up so that next time you will reboot the server you won’t have to worry about Apache service.
Run this command to make sure that the Apache service will auto start next time on server reboot:

chkconfig --levels 235 httpd on


/sbin/chkconfig --levels 235 httpd on

Do not forget to reload Apache service on each configuration edit, both httpd.conf or vhost configuration files:

service httpd reload


/etc/init.d/httpd reload

Now that you are finished with Apache, its time to continue with the process and install MySQL. MySQL is a database server and today most web applications, cms or blog system use mysql databases. So probably you will need MySQL anyway.

Install mysql-server packages from the repository:

yum install mysql-server

Now add the MySQL server to the startup so you won’t have to worry about it either when you reboot the server:

chkconfig --levels 235 mysqld on


/sbin/chkconfig --levels 235 mysqld on

and its time to test the installation and start the mysql server:

service mysqld start


/etc/init.d/mysqld start

After insuring mysql is running and everything is ok you should run the following command to make sure you secure your mysql installation, remove default databases and users and disable root logins except from localhost:


You should answer yes to all of the questions that will follow and do not forget to set the mysql root password.
Now login to mysql server:

mysql -u root -p

Enter your mysql password and you will get mysql prompt where you can run sql statements.
For example you can create a database and give permissions to user by running the following commands:

create database mydatabase;
grant all on mydatabase.* to 'myuser' identified by 'mypassword';

You can quit the mysql prompt by running the following command:


In case you have to change mysql configuration, your configuration file is my.cnf and you can find it in /etc.
You are almost done and what’s left is to install PHP on the server, you probably already know what PHP is and why should you need PHP on your server, in case you don’t – PHP is a general-purpose scripting language for web development, its main purpose is to create dynamic pages, websites and web applications.
Install PHP by running the following command:

yum install php php-pear php-mysql

Now you can change defaults in /etc/php.ini if you already know what you are doing and there are specific settings you need to change. If you are not sure about this one, do not worry – you can always do it later if you encounter problems with web applications that will demand different PHP settings.
You can reload everything again or just reboot the server and make sure everything works and you are done. Congratulations! You have a working LAMP server setup.

Understanding logrotate on CentOS

Tying it all together: virtual host logs

To show how you can use logrotate for your own applications, let’s look at an example that will come in handy for a lot of people: rotating logs for your custom virtual hosts. We’ll use apache for this example, but it can be tweaked pretty easily for other web servers like nginx or lighttpd, usually just by changing the postrotate script.

First we’ll want to create a file to hold the configuration that will tell logrotate what to do with the virtual host’s log files. We won’t edit the main config file or the web server’s config file, since there’s always a possibility that a future package upgrade might want to overwrite the config. Instead we’ll make our own. Let’s call it:


This example tosses all the virtual hosts into one file, but if you have one that’s busier than others you may want to create separate config files to handle the needs of your different domains. We’ll also specify several items that are probably already set in your main config, just so we cover all the bases.

The files

We’ll say that we have two virtual domains, and, and that the log files for each are in /home/demo/public_html/(domain name)/log. The first thing we’ll do in our config file is tell logrotate where to find the log files, then start the config block for them:

/home/demo/public_html/*log /home/demo/public_html/*log {

If you have more log directories or files to add, just insert them into that list.


Next we’ll want to make sure logrotate only keeps as many old logs as we want:

rotate 14

We’ll use 14 in this example to keep two weeks’ worth of logs, but you can of course adjust that number to something suitable to your requirements.


Now we’ll tell the web server to rotate these logs daily (again, change it if you prefer a longer interval):


Size (optional)

If you prefer a weekly rotation it’s wise to specify a max log size as well, to be on the safe side. The max size setting doesn’t make much difference if you have the logs rotating daily, but if you use “weekly” or longer instead you might also include the line:

size 50M

That way if a log starts getting too large (from unexpectedly heavy traffic, for example) it will be rotated early rather than allowing it to get too unwieldy.


We’ll specify whether or not we want these logs to be compressed when they’re archived. For this example we’ll use delaycompress to account for the graceful restart of apache, which means we also need to turn compression on:

compress delaycompress


You might have several virtual hosts, and that would mean several logs to rotate. To make sure the web server only gets restarted after all the rotations are done we add:



We’ll specify a postrotate script that will restart the web server:

postrotate /usr/sbin/apachectl graceful > /dev/null endscript

And finally, we close the config block with a curly bracket:


The whole shebang

Once we bring it all together our config file will look like this:

/home/demo/public_html/*log /home/demo/public_html/*log { rotate 14 daily compress delaycompress sharedscripts postrotate /usr/sbin/apachectl graceful > /dev/null endscript }

You’ll want to test that, of course, either by making sure you’re watching things when the nightly cron jobs are run, or by running logrotate right now:

/usr/sbin/logrotate /etc/logrotate.conf

If you don’t get any errors back you should be okay. But if you want to be absolutely certain you can run through some of the tests we would use when we suspect something isn’t working right.

Testing logrotate

If you suspect logrotate is having some trouble, or you just want to make sure a new config you’ve put in place will work, there are some useful flags you can pass to logrotate when you run it from the command line:


The verbose flag, “-v”, tells logrotate to say what it’s doing while it’s doing it. It’s very useful when trying to find out why logrotate doesn’t rotate a log when you want it to.


The debug flag, “-d”, tells logrotate to go through the motions of rotating logs but not actually rotate them. It can be handy if you want to test a new config file but don’t want any actual log rotation run when you do (if you’re working on a production server, for example).

The debug flag is good for checking that the config file is formatted properly and that logrotate can find the log files it would rotate. However, since it doesn’t actually run the rotations it doesn’t test some parts of the process like the postrotate scripts.


The force flag, “-f”, forces logrotate to rotate all logs when it runs, whether or not they would normally need to be rotated at that time. If you want to thoroughly test logrotate’s configs this is the flag to use. Just remember that logrotate will be rotating logs and deleting old ones according to the configuration you’ve set up, so don’t accidentally rotate out a recent log you needed to keep.

The force flag can be useful if you’re convinced that logrotate should be rotating a log, but it isn’t. Forcing the issue will help you tell if the problem is that logrotate doesn’t think the log needed rotating (if you run with the force flag and the log is rotated), or if the problem is that logrotate isn’t able to affect the log file (if you run it and nothing happens to the log).

Note that if logrotate is set to add a date to the name of an archived log, not even using the force flag will get logrotate to make a new archive in the same day (since the name it would use for the archive is already taken). In that circumstance you may need to rename the most recent archive (for each log file in a given config block) before you can force a log rotation.

Combining flags

The testing flags can be used together quite effectively. To have logrotate tell you what it would do if you made it rotate everything, but not actually rotate anything, you can combine all three:

/usr/sbin/logrotate -vdf /etc/logrotate.conf

You’ll get treated to a long list of things logrotate would do, including which log files it would rotate and what it would do during that process.

If you then want to test all the rotate configs in their entirety — including the scripts run after rotations — you can run logrotate without the debug flag:

/usr/sbin/logrotate -vf /etc/logrotate.conf

All the logs will be rotated, and skimming the output should help you catch any obvious problems. You’ll also want to make sure that all your services are still running okay (that there was nothing wrong with the postrotate scripts), and that all the logs actually did get rotated.

How logrotate remembers

If you find that a log isn’t rotating even though it’s old enough that it should, a simple way to fix the problem is to manually run logrotate with the “-f” flag. But if you’re the sort who wants to know why something’s gone wrong, there’s one more file you can check before forcing a rotation:


That file is where logrotate stores information about when it last rotated each log file. If you look inside you’ll see something like:

logrotate state -- version 2 "/var/log/acpid.log" 2010-6-18 "/var/log/iptables.log" 2010-6-18 "/var/log/uucp.log" 2010-6-29 ...

It’s a straightforward format – the log file location is on the left, and the date when it was last rotated is on the right. Sometimes it can happen that the dates on your server get a little wonky (if you were tinkering with an NTP service or the like), and the date when a log was last rotated winds up being a future date. If that’s happened you’ll see it here.

If you want to check logrotate out with a particular log file but don’t want to force everything to rotate, you can delete the log’s entry from the logrotate status file. Then when you run logrotate normally it should create a new entry for the log with today’s date (even though it may not actually rotate the log – it uses that first run as a baseline if it’s just interval-based).


For something that runs quietly in the background and only really performs one type of task, logrotate does quite a bit. You hopefully understand logrotate better than you wanted to. At the least you should be able to set up new logrotate config files for your own purposes, either creating them from scratch or copying existing configs and modifying them appropriately. And most importantly, you can keep your logs from getting out of control.

Auto backup all project SVN

First , download backup SVN of

write script

appname=`basename $0`

# Set some defaults

for project in $( ls /home/svn )
if [ ! -d “$backuppath$project” ]; then
# Control will enter here if $DIRECTORY doesn’t exist
mkdir $backuppath$project
/home/scripts/svnbackup-1.8/ -v -i 100 –file-name “backup” –out-dir $backuppath$project /home/svn/$project

exit 0

Use Rsa log to SSH

#create keygen at local

#use command

$ ssh-keygen -t rsa -b 2048

Add ssh key to server copy keygen at ~/.ssh/

On server

create .ssh directory with  permission is 755 at folder ~

touch ~/.ssh/authorized_keys2

#quick copy rsa key to ssh on server
ssh-copy-id ‘-p XXXX -i ~/.ssh/ username@host’

add public key to authorized_keys2

change mode from 644 to 400

if edit , you must change mod file authorized_keys2 to 644,

when finish, make sure permission of .ssh is 700 , authorized_keys2 is 400.