Pages

Monday, October 20, 2014

Tomcat Version Change

While working with Tomcat, we observed that Tomcat displays Error Page which has the Tomcat version on it. When ever we call a page which is not available , the tomcat server will push a Error page along with the version like














The Error page will also display the Version of the apache which may allow people to exploit the server since old tomcat server has some known exploits.

In this article we will see how we can change the version number on the error page to a different one.

Create a Directory location in  Tomcat Server lib location as
mkdir –p /lib/org/apache/catalina/util/

In the util location, create a properties file as
[root@localhost util]# cat ServerInfo.properties
server.info=Apache Tomcat Version XXX

Now restart tomcat and access a application which is not available and we will see this,


Read More

Apache – Custom Error Page

Error handling is one of the important parts when running a server. The application running inside the server provides the necessary services to the client but it is the responsibility of the server to serve custom pages for errors. In this article we will see how we can configure custom error page 404 for Apache web server along with Tomcat.

1. Create a 404 error page as
<html>
<head> Hello This a 404 Error page </head>
<body bgcolor="green">
</h3> this is green and 404 </h3>
</body>
</html>

Copy the file to /var/www/webroot/ROOT/ location

2. Once the file is created, configure Apache Configuration file as

<VirtualHost *:80>
   ServerAdmin webmaster@dummy-host.example.com
   DocumentRoot /var/www/webroot/ROOT/
   ErrorDocument 404 /404.html
   ServerName dummy-host.example.com
   ErrorLog logs/dummy-host.example.com1-error_log
   CustomLog logs/dummy-host.example.com1-access_log common
   ProxyRequests Off
   ProxyPreserveHost On

   <Proxy *>
    Order deny,allow
    Allow from all
    Options +Indexes
   </Proxy>

   ProxyPass /application1 http://localhost:8080/myApp/
   ProxyPass /application2 http://localhost:8080/Sample-app/test.html

   ProxyPassReverse /application1/ http://localhost:8080/myApp/
   ProxyPassReverse /application2/ http://localhost:8080/Sample-app/test.html
</VirtualHost>

All we need to do is add an ErrorDocument entry to our http.conf file. On the ErrorDocument line, we specify the error code, which in this case is a 404. After that, we can specify either a text message or the page to display and then file to be displayed ( 404.html ). Restart the Apache server.

Now once we access a different path, we see the 404 error page as,


Read More

Wednesday, October 15, 2014

Working with GIT

GIT is now considered as a most versatile distributed version control system. The GIT is not completely different from the sub-version we use. The main benefit of using GIT is that it provides better ways when tracking and handles file changes.

Normally with the SVN, we configure a SVN Repository and then use a client to connect to the repository to download the project. Once we have the project in our space, we make changes and then commit the files to the repository again. This is much like a Client-Server model.

But GIT works in a different way, when we download a Project from a remote GIT location we actually download everything from version history to individual files along with the changes done. Once the download is done the local GIT repository acts as a server. We can do a Check-in, check-out and all other version control activities. When we are ready we can merge our changes to the remote GIT location

With GIT developers don’t need to connect to the master Repository all the time. It is also good at branching and merging. GIT is considered best for the Open Source projects. We just need to make changes and push to our local repository. When connected we can ask the project manager to push the changes from our repository to the master repository. GIT is also good in bridging between it and SVN.

In this article we will see how we can install and Configure GIT in a Linux environment.

1. Download GIT from here
2. Configure the GIT using,
 [root@localhost git-2.1.2]# cd GIT/
 [root@localhost git-2.1.2]# ./configure
 [root@localhost git-2.1.2]# make
 [root@localhost git-2.1.2]# make install

3. Check the installation using
[root@localhost git-2.1.2]# whereis git
git: /usr/bin/git /usr/local/bin/git /usr/share/man/man1/git.1.gz

[root@localhost git-2.1.2]# git --version
git version 2.1.2

Once we see the correct responses, we can confirm that GIT is configured correctly.

4. Our next step is to create a Project. Create a Directory as gitpasswordtest and from inside the location use

[root@localhost gitpasswordtest]# git init
Initialized empty Git repository in /root/dump/gitpasswordtest/.git/

Once the command returns we can see file created in the location as,

[root@localhost gitpasswordtest]# ls -alrt
drwxr-xr-x. 7 root root 4096 Oct 15 17:45 .git

[root@localhost gitpasswordtest]# cd .git/
[root@localhost .git]# ls -alrt
drwxr-xr-x. 4 root root 4096 Oct 15 17:45 refs
-rw-r--r--. 1 root root   73 Oct 15 17:45 description
drwxr-xr-x. 3 root root 4096 Oct 15 17:45 ..
drwxr-xr-x. 2 root root 4096 Oct 15 17:45 info
drwxr-xr-x. 2 root root 4096 Oct 15 17:45 hooks
-rw-r--r--. 1 root root   23 Oct 15 17:45 HEAD
drwxr-xr-x. 2 root root 4096 Oct 15 17:45 branches
drwxr-xr-x. 4 root root 4096 Oct 15 17:45 objects
-rwxr--r--. 1 root root   92 Oct 15 17:45 config
drwxr-xr-x. 7 root root 4096 Oct 15 17:45 .

5. Create a File and commit the file. Our next step is to create a file and commit the file to the GIT repository.

[root@localhost gitpasswordtest]# touch hello
[root@localhost gitpasswordtest]# echo “This is Jagadish” >> hello

Once the file is created , add the file to GIT repository as
[root@localhost gitpasswordtest]# git add hello

We can add files even as
[root@localhost gitpasswordtest]# git add *.java
[root@localhost gitpasswordtest]# git add *.c

In most cases we use below which will add all files under the current location
[root@localhost gitpasswordtest]# git add .

One the file is added , commit the changes as
[root@localhost gitpasswordtest]# git commit -m 'First basic File to Git'
[master (root-commit) 0fe6798] First basic File to Git
 Committer: root <root@localhost.localdomain>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
You can suppress this message by setting them explicitly:

    git config --global user.name "Your Name"
    git config --global user.email you@example.com

After doing this, you may fix the identity used for this commit with:

    git commit --amend --reset-author

 1 file changed, 1 insertion(+)
 create mode 100644 hello

From the above output we can see that the file commit to GIT is successfully. But we a warning that name and password are not configured.

For configuring these, we can use
[root@localhost gitpasswordtest]# git config --global user.name "GIT Admin"
[root@localhost gitpasswordtest]# git config --global user.email admin@git.com

Verify the git configuration information as,
[root@localhost gitpasswordtest]# git config --list
user.name=GIT Admin
user.email=admin@git.com
core.repositoryformatversion=0
core.filemode=true
core.bare=false
core.logallrefupdates=true
This information is stored in the .gitconfig file under your home directory.

$ cat ~/.gitconfig
[user]
        name = GIT Admin
        email = admin@git.com

6. Make changes to the file and commit
[root@localhost gitpasswordtest]# vi hello ( make some changes )
[root@localhost gitpasswordtest]# git diff
diff --git a/hello b/hello
index 167f877..4ae8d27 100644
--- a/hello
+++ b/hello
@@ -1 +1 @@
-this is jagadish
+this is jagadish after changes

[root@localhost gitpasswordtest]# git add hello
[root@localhost gitpasswordtest]# git commit -m "this is second change"
[master 4f48fe8] this is second change
 Committer: root <root@localhost.localdomain>
Your name and email address were configured automatically based
on your username and hostname. Please check that they are accurate.
1 file changed, 1 insertion(+), 1 deletion(-)

7. Status check. Once the changes are committed ,we can check the status using
[root@localhost gitpasswordtest]# git status
On branch master nothing to commit, working directory clean

We can also see changes done to the file using
[root@localhost gitpasswordtest]# git log hello
commit 4f48fe8ce43b8aa9fc90903a197e057cb94a75a9
Author: root <root@localhost.localdomain>
Date:   Wed Oct 15 17:52:26 2014 +0530

    this is second change

commit 0fe679861458c3a34da30c7ecc4f4ee1dca39ec4
Author: root <root@localhost.localdomain>
Date:   Wed Oct 15 17:50:45 2014 +0530

    First basic File to Git

By this we cover the basics of using GIT server. I will be providing more doc on how to handle advanced operations on GIT.
Read More

RPM – Script Execution

There may be cases where we need to perform a action whenever we install a RPM. Consider a Case where we need to create a User when a RPM is Installed or execute a Script to change the permissions on the locations installed by a RPM.

RPM in linux provides us various options in doing these. RPM supports a script run prior to installation, %pre, and a script run after installation, %post. The same concepts apply when a package is erased, or uninstalled. The %preun script is run just before the uninstall and the %postun script just after the uninstall.

In this post we will see how we can execute a Shell script after the installation of the RPM. We will follow the Basic RPM created here.

The steps are same. The only thing we need to add was a %post element to the SPEC file. The final Spec file looks as

[root@localhost SPECS]# cat hello.spec 
Name:           hello
Version:        1
Release:        1%{?dist}
Summary:        Hello Program

Group:      Utilities
License:    GPL    
Source:  %{name}.tar.gz      
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}

%description
Test Program For Build

%prep
%setup -n hello

%install
mkdir -p "$RPM_BUILD_ROOT/opt/hello"
cp -R * "$RPM_BUILD_ROOT/opt/hello"

%clean
rm -rf $RPM_BUILD_ROOT

%files
/opt/hello

%post
sh /opt/hello/hello.sh >> /tmp/hello

The %post element tells us to execute a Shell Script and redirect the Output to /tmp/hello file.

Once the creation of the RPM , we will install using
[root@localhost x86_64]# rpm -ivh hello-1-1.el6.x86_64.rpm 
Preparing...                ########################################### [100%]
   1:hello                  ########################################### [100%]

Once the RPM is installed check,
[root@localhost x86_64]# cat /tmp/hello 
this is hello world

The Shell Script is executed correctly once the RPM is installed.

More to come , Happy Learning J


Read More

Thursday, October 9, 2014

Sub version in Linux

Subversion is a free/open source version control system (VCS). That is, Subversion manages files and directories, and the changes made to them, over time. This allows you to recover older versions of your data or examine the history of how your data changed.

In this article we will see how we can configure a Sub version in Linux.

1. In order for the sub version to work we need a couple of tools to be available. Install the tools using yum install -y subversion mod_dav_svn

2. Once the tools are installed, We need to make changes to the svn configuration file. The file exists in /etc/httpd/conf.d/ subversion.conf. The final version of this file after making changes looks as

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

<Location /svn>
   DAV svn
   SVNParentPath /var/www/svn
   AuthType Basic
   AuthName "subversion repositories"
   AuthUserFile /etc/svn-auth-users
   Require valid-user
</Location>

I added the modules to be loaded and also user file.

3. Create a user “sk” for the svn repo using

[root@localhost conf.d]# htpasswd -cm /etc/svn-auth-users sk
New password:
Re-type new password:
Adding password for user sk

4. Once the user is created, we need to create a repository where we push the file. Use the following commands to create the directory structure

[root@localhost conf.d]# mkdir /var/www/svn
[root@localhost conf.d]# cd /var/www/svn/

Once the directory structure is created, we need to create a repository using the svnadmin command as
[root@localhost svn]# svnadmin create test_repo
Now the test_repo svn is created.We need to change the permissions using
[root@localhost svn]# chown -R apache.apache test_repo/

Now if we check the files available, we will see
[root@localhost svn]# ll
drwxr-xr-x. 6 apache apache 4096 Oct  9 17:41 test_repo

5. The next thing is we need to change the security level for the svn. We can do this using
[root@localhost svn]# chcon -R -t httpd_sys_content_t /var/www/svn/test_repo/
[root@localhost svn]# chcon -R -t httpd_sys_rw_content_t /var/www/svn/test_repo/

6. Make sure the port 80 is accepted in the Iptables. For this make changes as below

[root@localhost svn]# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A INPUT -p tcp -m state --state NEW --dport 80 -j ACCEPT
-A INPUT -p udp -m state --state NEW --dport 80 -j ACCEPT
COMMIT

Add the bold lines to the file.

7. Once the changes to security is changes, restart the iptables using
[root@localhost svn]# service iptables restart
iptables: Flushing firewall rules:                                             [  OK  ]
iptables: Setting chains to policy ACCEPT: nat mangle filte          [  OK  ]
iptables: Unloading modules:                                                [  OK  ]
iptables: Applying firewall rules:                                                      [  OK  ]

8. Restart Apache using
Service httpd restart

9. Test the subversion using

The url will ask for a User name and password. For this we will use the sk and the password created in step 3

Disable anonymous access
In order to disable anonymous access to users, we can change the setting in the svnserve.conf file. For this go to the test_rpm location

[root@localhost test_repo]# ll
drwxr-xr-x. 2 apache apache 4096 Oct  9 17:41 conf
drwxr-sr-x. 6 apache apache 4096 Oct  9 17:41 db
drwxr-xr-x. 2 apache apache 4096 Oct  9 17:41 hooks
drwxr-xr-x. 2 apache apache 4096 Oct  9 17:41 locks
-rw-r--r--. 1 apache apache  229 Oct  9 17:41 README.txt
-r--r--r--. 1 apache apache    2 Oct  9 17:41 format

[root@localhost test_repo]# cd conf/
[root@localhost conf]# ll
-rw-r--r--. 1 apache apache 1080 Oct  9 17:41 authz
-rw-r--r--. 1 apache apache  309 Oct  9 17:41 passwd
-rw-r--r--. 1 apache apache 2279 Oct  9 17:41 svnserve.conf

Un comment the lines in the svnserve.conf location as

anon-access = read
auth-access = write

Import Sample content
Once the configuration of SVN is done, we need to import some files to the repository. For this create a sample directory structure as

mkdir subversion-test
cd subversion-test
mkdir subversion-test/updates
mkdir subversion-test/fix
mkdir subversion-test/softwares

Now import the files using
[root@localhost dump]# svn import -m 'First Test Import' subversion-test/ http://localhost/svn/test_repo
Authentication realm: <http://localhost:80> subversion repositories
Password for 'root':
Authentication realm: <http://localhost:80> subversion repositories
Username: sk
Password for 'sk':
Adding         subversion-test/updates
Adding         subversion-test/fix
Adding         subversion-test/softwares

Committed revision 1.

More to Come, Happy learning J
Read More

Wednesday, October 8, 2014

Build a RPM

Previously Linux programs used to come in source code with all files, configuration stuff so that the user has to build them to work. Now days they are coming in the form of packages which ship ready for installation. We just need to download the RPM and install that into the system using the package management tools like RPM and YUM. For more details see here.

In this article we will see how we can build a Sample RPM in Linux.

1. For building RPM we need the following tools rpmdevtools, rpm-build and make. In order to install them use
yum install rpmdevtools rpm-build make

2. Lets create our sample project. We will create a Sample Shell file which will be installed as a part of the RPM. For this

mkdir hello
touch hello/hello.sh

Create a tar for the directory
tar czvf SOURCES/hello.tar.gz hello/
hello/
hello/hello.sh

3. Create the RPM directory Structure using
rpmdev-setuptree

4. Once the command is executed we can see a rpmdbuild directory created in the home location. It looks as

[oracle@localhost ~]# ls -l rpmbuild/
total 20
drwxr-xr-x. 2 root root 4096 Oct  8 19:58 BUILD
drwxr-xr-x. 2 root root 4096 Oct  8 19:58 RPMS
drwxr-xr-x. 2 root root 4096 Oct  8 19:58 SOURCES
drwxr-xr-x. 2 root root 4096 Oct  8 19:58 SPECS
drwxr-xr-x. 2 root root 4096 Oct  8 19:58 SRPMS

5. Copy the hello.tar.gz to the ~/rpmbuild/SOURCES location
6. Now in order to create a RPM file we need a Spec file which describes the process to build, install the sources. For creating a Spec file use,
rpmdev-newspec  ~/rpmbuild/SPECS/hello.spec

7. Now we can see the hello.spec file in the SPECS directory.

The stages of the Spec File include
Stages:
● Preamble
● Setup
● Build
● Install
● Clean
● Files
● Changelog

Preamble: This is the initial section which defines package characteristics, name, version, group, license, Build, Install, Summery, description and release information
Setup: In the setup stage, the source tree are generated, unpacked and patches are applied. All Pre-build actions are performed here.
Build: the Build stage makes sure all the necessary binaries are created.
Install: In the install stage,  the buildroot is created , the file system is set  ,Puts built files in buildroot and also Cleans up unnecessary installed files
Clean: the buildroot set in the previous stage is removed at this point.
Changelog: the change log allows for auditing and also used to track package changes.

8. After making some necessary changes to the hello.spec file, the final version looks as

Name:           hello
Version:        1
Release:        1%{?dist}
Summary:        Hello Program

Group:      Utilities
License:    GPL   
Source:  %{name}.tar.gz     
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}

%description
Test Program For Build

%prep
%setup -n hello

%install
mkdir -p "$RPM_BUILD_ROOT/opt/hello"
cp -R * "$RPM_BUILD_ROOT/opt/hello"

%clean
rm -rf $RPM_BUILD_ROOT

%files
/opt/hello

9. Once the file changes are done, run the rpmbuild command as

[oracle@localhost SPECS]$ rpmbuild -bb -v hello.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.7hgZ7L
+ umask 022
+ cd /home/oracle/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/oracle/rpmbuild/BUILD
+ rm -rf hello
+ /usr/bin/gzip -dc /home/oracle/rpmbuild/SOURCES/hello.tar.gz
+ /bin/tar -xvvf -
drwxr-xr-x oracle/oinstall   0 2014-10-08 21:24 hello/
-rw-r--r-- oracle/oinstall  39 2014-10-08 21:24 hello/hello.sh
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd hello
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.AL04Os
+ umask 022
+ cd /home/oracle/rpmbuild/BUILD
+ '[' /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64 '!=' / ']'
+ rm -rf /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64
++ dirname /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64
+ mkdir -p /home/oracle/rpmbuild/BUILDROOT
+ mkdir /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64
+ cd hello
+ LANG=C
+ export LANG
+ unset DISPLAY
+ mkdir -p /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64/opt/hello
+ cp -R hello.sh /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64/opt/hello
+ /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot
+ /usr/lib/rpm/redhat/brp-compress
+ /usr/lib/rpm/redhat/brp-strip /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-static-archive /usr/bin/strip
+ /usr/lib/rpm/redhat/brp-strip-comment-note /usr/bin/strip /usr/bin/objdump
+ /usr/lib/rpm/brp-python-bytecompile
+ /usr/lib/rpm/redhat/brp-python-hardlink
+ /usr/lib/rpm/redhat/brp-java-repack-jars
Processing files: hello-1-1.el6.x86_64
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64
Wrote: /home/oracle/rpmbuild/RPMS/x86_64/hello-1-1.el6.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.5cV57Q
+ umask 022
+ cd /home/oracle/rpmbuild/BUILD
+ cd hello
+ rm -rf /home/oracle/rpmbuild/BUILDROOT/hello-1-1.el6.x86_64
+ exit 0

10. Now the build is executed with no issues. If we check the files in the RPMS location we can see

[oracle@localhost rpmbuild]$ cd RPMS/
[oracle@localhost RPMS]$ ll
drwxr-xr-x. 2 oracle oinstall 4096 Oct  8 21:37 x86_64
[oracle@localhost RPMS]$ cd x86_64/
[oracle@localhost x86_64]$ ll
-rw-r--r--. 1 oracle oinstall 2196 Oct  8 21:37 hello-1-1.el6.x86_64.rpm

11. Now in order to install the RPM created we can use
[root@localhost x86_64]# rpm -ivh hello-1-1.el6.x86_64.rpm
Preparing... ########################################### [100%]
   1:hello    ########################################### [100%]

12. In order to make sure the rpm is installed use,
[root@localhost x86_64]# rpm -q hello
hello-1-1.el6.x86_64


Happy learning, more to come
Read More