Here are configurationsteps for mail-sending with Exim and Googlemail account (google Apps accounts work the same way too).

1. first of all we need working Exim. If not installed – install exim4.

   $ apt-get update
   $ apt-get install exim4
   

2. Configuration should start after the installation. However you can start configuration of exim every-time with

   $ dpkg-reconfigure exim4-config
   

3. Answer the questions of configuration wizard. The important one is.
   a general type of mail configuration. Choose “sent by smarthost”
   if you wanna use the ability of e.g. Googlemail account. Then SMTP with dynamic IP would be difficult
4. answer other questions
   • Provide a System Mail Name: e.g. mycompany.com
   • Provide IP addresses to listen on for incoming SMTP connections
     User 127.0.0.1 if you don’t want only send mail from local machine and nothing for all IP’s.
   • Provide Machine handling outgoing mail for this host (smarthost): smtp.gmail.com::587

   Other parameter are not so important for a start. However read more about debconf questions and other configuration if you like.

5. Now it’s time to provide credentials information of your gmail account. Therefore you need edit /etc/exim4/passwd.client file with your favorite editor.
   Insert that for Standard or google app account but replace with valid mail and password.

   gmail-smtp.l.google.com:yourYourMail@googlemail.com:yourPass
   *.google.com:yourYourMail@googlemail.com:yourPass
   smtp.gmail.com:yourYourMail@googlemail.com:yourPass
   

6. Make sure /etc/exim4/passwd.client belongs to user root and group Debian-exim which is normal so on my Debian. If not, run that command:

   $ chown root:Debian-exim /etc/exim4/passwd.client
   

7. Actualize the whole configuration with:

   $ update-exim4.conf
   

   Your ‘re done!

Now it’s test it with.

echo "Server Mail Test Message " | mail -s "Just Test" SomeMail@someDomain.org

Watch logs:

$ tail -1000f /var/log/exim4/mainlog

When you see something like this. Everything should vent perfect.

2010-02-14 23:00:26 1NgmVu-0007v8-Kt < = root@mail-server1.mycompany.com U=root P=local S=424
2010-02-14 23:00:28 1NgmVu-0007v8-Kt => testMail@mycompany.org R=smarthost T=remote_smtp_smarthost H=gmail-smtp-msa.l.google.com [72.14.221.109] X=TLS1.0:RSA_ARCFOUR_MD5:16 DN="C=US,ST=California,L=Mountain View,O=Google Inc,CN=smtp.gmail.com"

Two words on theory. Password-less connections have to be authenticated at least so strong like the password enabled one, so asymmetric cryptography which enables certificates comes into play.  The clue is to have private and public keys and share your public key with domains which should be able identify you.

So therefore let’s start by generation a needed key-pair.

Generating Keys

It is possible to create key with pass-phrase and without (or empty pass-phrases). I prefer to not use pass phrase because it is asked every-time on later usage of a ssh.
Even there are ways to gives the pass-phrase to ssh command, but it is more work, with no significant security benefits. So i do the following statement and do not enter any pass-phrase (just hit enter on question).

$ ssh-keygen -t rsa

This will create RSA key-pair as following files in ~/.ssh directory:

• id_rsa
• id_rsa.pub

Now public key need to be copied to remote host and has to be added to end of ~/.ssh/authorized_keys file.

Transfer Public keys

The best way to do it is to use ssh-copy-id program which is inside of many linux distributions.

$ ssh-copy-id -i ~/.ssh/id_rsa.pub remote-user@remote-server.org

In that case everything is done automatically and you are ready after that. But if ssh-copy-id is not available, you can copy keys manually e.g. like that.

$ cat ~/.ssh/*.pub | ssh remote-user@remote-server.org 'umask 077; cat >>.ssh/authorized_keys'

Attention! On some linux distrs SSH2 searches for keys in ~/.ssh/authorized_keys2 . Not so in actual Debian (Lenny), but seems to be so in SuSe linux.

Test

Now remote login, scp and sftp can be used without password.
Test it:

# establish connection
$ ssh remote-user@remote-server.org
#or copy files secure and password-less.
$ scp /home/user/some-file remote-user@remote-server.org:/some-path/dir/

More information on SSH related man pages.

Installing Java SDK

Nowadays  installing Java environment on Debian is an easy task. I used JDK 1.6. Don’t confound JDK with JRE, because bare Java Runtime Environment is not enough for running JBoss. Debian Wiki maintains (hope) a list of available java .deb packages, which are easily can be installed with your preferred way. I prefer aptitude, but apt-get of course works too.

$ aptitude install sun-java6-jdk
#or by good old apt-get.
$ apt-get install sun-java6-jdk

Installation is done after seconds. Now test your java installation with

$ java -version
# Here example result on my configuration:

java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)

If you get something like this, you’re done and your java should be already in the PATH.

Installing JBoss AS

Now let’s install  JBoss Application Server.

Preparing

Normally you are not willing  to start services (especially when they are accessed from outher machines) with root privileges. Therefore we have to define new user and group which will be used to manage JBoss.  So next line will create new group and new user with this group.

 $ groupadd jboss
 $ useradd -s /bin/bash -d /home/jboss -m -g jboss jboss

This jboss user has no password, so nobody can login with this username. If you consider to  login with jboss user,  password has to be set. Use passwd jboss command for that.

Download, Installation,  filesystem layout

Now  download desired Jboss version. I started with JBoss 5.1.0 GA, which can be download with:

$ cd /tmp # swithch to temp dir
$ wget http://sourceforge.net/projects/jboss/files/JBoss/JBoss-5.1.0.GA/jboss-5.1.0.GA.zip/download

Check also the whole list of verisons if interested. As you may noticed JBoss binaries are packaged with ZIP. So it is comfortable to use unzip tool. Maybe you have to install it first.

But before you extract  downloaded file, we have to decide, where exactly should JBoss files be placed on a  file-system. Unfortunately JBoss is not quite conform to Linux File System Hierarchy Standard per default, so there are many possibilities for a location configuration. Some of you may want to place JBoss  into /opt directory. But I prefer to split the installation a little bit and  want to start by putting  JBoss core files in /usr/local/, where local, unchangeable and read-only files usually placed. E.g. I use  /usr/local/jboss/510 as JBoss 5.1.0 GA root.  So let’s create that location and extract files into it.

mkdir /usr/local/jboss #create new jboss directroy
chown jboss:jboss /usr/local/jboss #now its belongs touser jboss and group jboss
su jboss
mkdir /usr/local/jboss/510
cd /usr/local/jboss/510
unzip /tmp/jboss-5.1.0.GA.zip

At this moment you should have new working JBoss. If you want, test it with

bin/run.sh -b 0.0.0.0

Where -b 0.0.0.0 means that JBoss is listening for every ip address of current machine.

However at this stage the installed Jboss still brakes the  Linux Filesystem Hierarchy Standard, so let’s improve this situation.

After the first start of the server used configuration will have new directories /tmp and /work . The /tmp directory contain the temporarily state of the deployed applications and /work is contains compiled jsp pages of deployed applications. Therefore both directories are of temporal character and  should be on more appropriate place according to Linux standards.

I use only a default JBoss configuration,  which is defined under <jboss_root>/server/default, so I need to do further changes only for this configuration. My decision is to put both directories to /var /tmp/jboss.:

$ mkdir /var/tmp/jboss
$ chown jboss:jboss /var/tmp/jboss/
$ su jboss
$ mkdir /var/tmp/jboss/510
$ mkdir /var/tmp/jboss/510/tmp # creating alternavtive location for tmp
$ mkdir /var/tmp/jboss/510/work # creating alternavtive location for work
$ cd /usr/local/jboss/510/server/default # switch to configuration directory if not allready here.
$ rm -R tmp # delete existing tmp directory (server should not run at this moment)
$ rm -R work # delete existing work directory
$ ln -s /var/tmp/jboss/510/tmp ./tmp # Finaly create symbolic link to new place$
$ ln -s /var/tmp/jboss/510/work ./work # Finaly create symbolic link to new place

repeat the same for /log directory. It is common to have logs at one place in /var/log
create a log directory tree e.g. /var/log/jboss/510/ and let log link to it as was shown for tmp and work directories.

After that your configuration directory should look like:

$ ls -l /usr/local/jboss/510/server/default
drwxr-xr-x  6 jboss jboss 4096 22. Mai 2009  conf
drwxr-xr-x  6 jboss jboss 4096 23. Jan 00:10 data
drwxr-xr-x 15 jboss jboss 4096 22. Mai 2009  deploy
drwxr-xr-x 12 jboss jboss 4096 22. Mai 2009  deployers
drwxr-xr-x  2 jboss jboss 4096 22. Mai 2009  lib
lrwxrwxrwx  1 jboss jboss   19 23. Jan 01:07 log -> /var/log/jboss/510/
lrwxrwxrwx  1 jboss jboss   23 23. Jan 01:13 tmp -> /var/tmp/jboss/510/tmp/
lrwxrwxrwx  1 jboss jboss   24 23. Jan 01:13 work -> /var/tmp/jboss/510/work/

And your logs are of course accessible directly at new location e.g.

tail -1000f /var/log/jboss/510/server.log

Furthermore you should deploy your applications to /srv/jboss/510 to enable this location for automatically scan and deployment,just create a link from /default/deploy/. Call it e.g. applications.:

$ ln -s /srv/jboss/510 ./usr/local/jboss/510/server/default/deploy/applications #

So applications which are placed to /srv/jboss/510 will be automatically deployed on the server.

Start JBoss on boot

First of all you need a life-cycle management script used by init. Jboss already provides some of then.  Let’s use one of Red Hat default script by adopting it a little bit. First of all copy the script to common place (feel free to ad version ti scriptname if you need or like)

$ cp /usr/local/jboss/bin/jboss_init_redhat.sh /etc/init.d/jboss

If you want to access you fresh JBoss also from other IP addresses you need to change
JBOSS_HOST line according to:

JBOSS_BIND_ADDR=${JBOSS_HOST:-"-b 0.0.0.0"}.

0.0.0.0. binds it on all IP addresses. Consider to change also other param this file to mach your personal needs. Now you can automatically create all the symbolic links used by init service.

$ update-rc.d jboss defaults

Now your Jboss will start automatically after reboot…

Additional configuration

• <jboss_root>/bin/run.conf file configures the start parameters of the server. Maybe default limits are not suitable for your applications. So check it.
• Under <jboss_root>/server/default/conf you will find some configuration files of the default server configuration. One of the interesting is of course jboss-lo4j.xml, where you can precisely define logging processing.

Questions & Suggestions

Thank you for reading this. Please feel free to provide any suggestions to the topic of JBoss installation on Linux and specially on Debian. Of course your questions are welcome too!

RAID 1

Sometimes you need to store data relative save and high available. That is where RAID solutions come in to play. Especially RAID 1 (mirroring) based solutions provide better availability of your data. But don’t forget to use backs anyway

Some days ago i installed RAID 1 on Debian Lenny (amd64 arch) without any troubles for now.
I just was following Jerry’s description which is enough detailed to make no mistakes except maybe one thing.
The Partitions used in the RAID /dev/md0/ should both enable boot flag if you want to boot from RAID.
This is worked for me.

Configuration

My configuration is the same as Jerry’s except partition sizes and chosed LVM. So boot is done form RAID partition /dev/md0. And SWAP is on RAID too, which is controversy solution but it the best one for me, of course availability of a system is primary goal.

So how to check the state of raid after installation. The simplest is to look on /proc file-system with $cat /proc/mdstat. Here is my configuration.

$cat /proc/mdstat
Personalities : [raid1]
md1 : active raid1 sda2[0] sdb2[1]
476560128 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
497856 blocks [2/2] [UU]

unused devices: <none>

Here you see two RAID arrays md0 and md1. Also information about used devices and state are peresent. [UU] stand for “used” for every disc is used in a raid. On diskfailure you wold see something like [U_] and sdb2(F).

Next example utilizes mdadm which is used by kernel in latest kernel versions. My is 2.6.26-2-amd64 (lenny default)
Use of –detail or -D option with a device name gives more information. Here my example.

# mdadm --detail /dev/md1
/dev/md1:
Version : 00.90
Creation Time : Wed Jan  6 00:51:37 2010
Raid Level : raid1
Array Size : 476560128 (454.48 GiB 488.00 GB)
Used Dev Size : 476560128 (454.48 GiB 488.00 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 1
Persistence : Superblock is persistent

Update Time : Mon Jan 11 02:18:01 2010
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

UUID : fe3bbbfd:2c6963e7:9785a408:be715448
Events : 0.8

Number   Major   Minor   RaidDevice State
0       8        2        0      active sync   /dev/sda2
1       8       18        1      active sync   /dev/sdb2

GRUB Config

If you wish that your system is able to boot even if one of disks fails completely. You need to write  GRUB loader on every hard disk separately.

Here the example for hd0 ( fist hard disk)

$ grub
grub> root (hd0,0)
Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
Checking if "/boot/grub/stage1" exists... no
Checking if "/grub/stage1" exists... yes
Checking if "/grub/stage2" exists... yes
Checking if "/grub/e2fs_stage1_5" exists... yes
Running "embed /grub/e2fs_stage1_5 (hd0)"...  17 sectors are embedded.
succeeded
Running "install /grub/stage1 (hd0) (hd0)1+17 p (hd0,0)/grub/stage2 /grub/menu.lst"... succeeded
Done.

Run the same also for second disk.

grub> root (hd1,0)
...
grub> setup (hd1)

Also your GRUB configuration should enabe loading form the first and alternatively the second disk.

default 0
fallback  1
# is there after installation
title           Debian GNU/Linux, kernel 2.6.18-6-686 Raid (hd0)
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.18-6-686 root=/dev/md0 ro
initrd          /boot/initrd.img-2.6.18-6-686

# manually created
title           Debian GNU/Linux, kernel 2.6.18-6-686 Raid (hd1)
root            (hd1,0)
kernel          /boot/vmlinuz-2.6.18-6-686 root=/dev/md0 ro
initrd          /boot/initrd.img-2.6.18-6-686

The default option declares the first configuration to run on default. fallback option forces grub to load fallback configuration (here hd1)
when the firt one could not start.

You’r done.

Monitoring

Once you run your “high”-available RAID you’re probably very interested to be informed about problems with it.
E.g. on a failure of one (hope only one) HD device.

Yet i know only two most common solutions for monitoring Software RAID. First of it bases on Nagios tool, but is not described here, because not tired yet. The second is to involve mdadm again.

The option –monitor causes mdadm periodically poll a your md arrays and to inform you on every events that occurs. mdadm should never exit process, so it should normally be run in the background.
Here is example of sending a mail on event. Of course sendmail must be configured.

mdadm --monitor --mail=admin@yourcompany.com --scan --delay=1800 -ft

It would run a monitor deamon which scanns all of RAID arrays with delay. The option f starts it as deamon process and t option generates test messages on a startup.

When you want to run mdadm through crone job so use option -1

mdadm --monitor--scan -1

Also this would send your mail or run program which are specified in /etc/mdadm.conf file.
Please see manual of mdadm for more details.

Test Performance

You can test our physical drives with hdparm utility e.g.

hdparm -tT /dev/hda

But hdparm would not correct work on your mdX RAID arrays.

So one of the simplest methods is to try time utility.

time dd if=/dev/md0 of=/dev/null bs=1024k count=1000

This test reads 1 GB data file from you RAID Array but reports to copy only something like “509804544 Bytes (510 MB) in 5,73989 s, 88,8 MB/s” by me. So why only half of the Gigabyte? Just be cause it utilizes two devices, as i think, and indeed it copies 500MB two times parallel = 1 Gig. And this only in the half of time as it needed to red 1 Gigabyte from physical /dev/sda directly.

time dd if=/dev/zero bs=1024k count=1000 of=/home/1Gb.file

This test writes 1 Gb file on RAID partition /home . Therefore you can compare write performance with RAID and non raid partitions but don’t expect any considerable advantages on Mirroring systems

The last one more professional but also complex tools is iozone. It can perform a various of tests,which can’t be explained here detailed.
Please read manual if you really need to test your raid that way. Alternatively you can start iozone in automatic mode, which performs various of tests (relative long-running) and prints on console.

iozone -a

See on Strided Read column which should consider software RAID bonus.

Failure and Recovery

RAID 1 should preserve you from data loose and improve your scalability. So it  is very good idea to has relative good knowledge of what to do on Failure. Best way to get this knowledge is to simulate failure. Take try to remove one disk and put it again into array.

tar

Tar archives are the most common way of distributing bundles of files under Linux or UNIX. A .tar file is simply a bundle of files packaged with GNU tar program. To extract such files use following:

tar xf somearchive.tar
tar xvf somearchive.tar

• Provide option f if you want to extract content of files. Tar (from tape archive) has long history and was intended to work with tape media, so when you omit f tar tries to work with tape device.
• v- stands for verbose. List all the files by extract process.
• x- Extract command

Before extracting you may be interested in Looking inside of tar. Do it with option “t” :

tar tf archive.tar

For more tar parameters see Man pages.

gzip

Often tar-files are also compressed. One of the most known compressed formats is GNU Zip (gzip).  Tar bundeld and zipped file would  normally  have extension .tar.gz. To extract such files you can use tar with  “z” option, which causes tar to automatically invoke gzip. Modify abow example  and you get able to extract tar.gz  files too.

tar -xzf somearchive.tar.gz

In old tar version the “z” option is may be not available. In that case just use UNIX pipes:

gzip -dc target.tar.gz | tar xf -

Meaning of gzip options

• d – Do decompress!
• c – write to console (So that tar can take it from there )
• t – Tests file integrity
• l – lists archive file information

You will find more on Man pages.

bzip2

Sometimes you can find files ending with .tar.bz2. That are files packaged with bzip (a block-sorting file compressor). Use it like gzip

tar xjvf filename.tar.bz2

Options d,c,t have the same meaning. More on Man pages.

zcat

Some files have .tar.Z endings. They can be extracted by

zcat somearchive.tar.Z | tar xf -

Look in Man pages for more.

Any questions? You are welcome to comment!