Just another Scott Alan Miller Sites site

Elastix is possibly the most powerful packaging of the Asterisk server.  Elastix comes as its own distribution built on top of CentOS and for most users going with the Elastix-provided install media is the best process.  However, if you wish to install the Elastix packages onto your own install of CentOS, like for times when you need to install to a Xen-based virtual server, then you need to use a different process.

Elastix provides its packages through a standard YUM repository system making it very easy to work with.  Using these repos is barely documented, if at all, and not all dependencies are addressed through these repos.  Additionally, with the introduction of Elastix 2.x, some of the necessary packages are handled by the Elastix 1.x branch while others are handled by the 2.x branch making the process a little more confusing.

To begin, we need a base installation of the CentOS 5 series.  Start with any CentOS 5 minimal install and updated it to the latest patches.

yum -y update

Then we will need to install the EPEL extensions from the Fedora Project.

rpm -ivh ftp://mirror.cs.princeton.edu/pub/mirrors/fedora-epel/5/i386/epel-release-5-4.noarch.rpm

Now let’s add some useful packages that we are sure to want.

yum -y install sysstat fail2ban bwm-ng system-config-securitylevel-tui

To install Elastix itself we need to upload the CD ISO image that we have downloaded from the Elastix website. To make things simple, simply upload it to the /tmp directory of our new server. Once we have the file there, we need to mount it so that we can use it like a local filesystem.

mkdir /mnt/iso
mount -o loop /tmp/Elastix-2.3.0-x86_64-bin-02abr2012.iso /mnt/iso
cd /mnt/iso

In order to utilize the new Elastix repo that we have just mounted we need to create a YUM repo entry for this.

vi /etc/yum.repos.d/elastix-cd.repo

[elastix-cd]
name=Elastix RPM Repo CD
baseurl=file:///mnt/iso/
gpgcheck=0
enabled=1

And at this point we should be ready to actually install Elastix which is about 266 packages.

yum -y install elastix

Once that completes we will want to reboot. You will want to be connected to the server via the console, not via SSH, as Elastic’s First Boot system will come up and step you through the basic setup of the system which just requires you to set two key passwords. If you are not at the console you will never see this dialog and you will be unaware that the application needs your attention.

Once the system comes back up, we should remove some unneeded services. No need to have extra stuff running. It is unlikely that we will be using iSCSI or NFS on our PBX so we will turn those services off.

chkconfig iscsi off
chkconfig iscsid off
chkconfig netfs off

A common Linux task is to mount a locally storage ISO image as if it was another filesystem.  This can be very handy for times when you need to install software from a CD or DVD image but do not have ready access to a physical drive.

First we need a place to mount the ISO image.  A handy location is often under the /mnt directory as it is obvious that something odd is going to be mounted there temporarily.  Let’s make a directory called /mnt/iso.

mkdir /mnt/iso

Now we have a place to mount our ISO image. In this example, the image file is just called /tmp/image.iso to make things simple. The simple “mount -o loop” command takes care of the rest.

mount -o loop /tmp/image.iso /mnt/iso

And that is it! Very nice and easy. Now you can cd into the /mnt/iso directory and browse your disc image like a normal file system. Keep in mind that the filesystem remains read-only as that is the nature of an ISO.

In the UNIX world, NFS is the simplest means of handling file sharing between systems.  And working with NFS on Linux is incredibly easy too.  Details on exporting NFS files is handled by the aptly named /etc/exports file.  In this file we list the folder to export, the host(s) allowed to mount this exported share and any options on that share (like read-only and root squash restrictions.)

In our example here we will take the local folder, /var/data

/var/data garfield.mydomain.com(rw,root_squash)

In this example, /var/data on our local server is being shared out to the host named “garfield” with the options of “rw”, for read-write (use ro for read-only) and “root_squash.”  Root squashing requires a little explanation.  This is a standard security procedure for NFS as it stops foreign hosts from acting as the root and gaining unlimited control of your file share.  Basically anyone claiming to be root on the foreign system gets least privilege access, rather than most privilege access, to the share.  It is rare that you would want to not have this option in place.

To cause the NFS service to re-read the /ext/exports file and enact the changes there we run the following command:

# exportfs -a

At this point you have a working NFS export and you should be able to mount it from the host names “garfield” without any problem, we hope.

In this real world example post I am going to deal with the every day administration task of adding four new hard drives to an existing, and running, production server, configuring them into an array, adding them to LVM management, adding a file system and mounting that filesystem.  The server in question is an HP Proliant DL380 G6 with a SmartArray P410i RAID controller but these direction should apply to any SmartArray controller.  We will be using HP’s hpacucli utility to manage the array from the command line.  We will be doing this from Red Hat Enterprise Linux 5.6 Tikanga but, again, the commands are very generic and will apply across many Linux versions.  The SmartArray management utility, hpacucli, is needed and is not a standard component of any Linux distro so if you are missing it you will need to acquire it from HP in order to manage your hardware.

The hpacucli utility is generally used interactively.  Commands entered at the “=>” prompt are within the hpacucli utility rather than in our normal shell.  Once in the utility we will run “ctrl all show config” to get an overview of the status of our array.  In our example we have a server with eight available drive bays.  Four are previously populated and configured (this is an existing production server) and the remaining four have just had drives inserted into their hot swap bays live so we will need to verify here that their details are correct.

=> ctrl all show config

Smart Array P410i in Slot 0 (Embedded) (sn: 50123456789ABCDE)

  array A (SAS, Unused Space: 0 MB)

    logicaldrive 1 (136.7 GB, RAID 1+0, OK)

    physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 72 GB, OK)
    physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 72 GB, OK)
    physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 72 GB, OK)
    physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 72 GB, OK)

  unassigned

    physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 146 GB, OK)
    physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 146 GB, OK)
    physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 146 GB, OK)
    physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 146 GB, OK)

  SEP (Vendor ID PMCSIERA, Model SRC 8x6G) 250 (WWID: 50123456789ABCED)

As you can see here, we have, as expected, four configured physical drives in a RAID 10 array and four unconfigured drives which we will now need to assign to a second RAID 10 array.  Of course we could also make two RAID 1 arrays, one RAID 5 array or one RAID 6 array but we want RAID 10 for performance and reliability. Now we need to assign the four unassigned drives to our array. We do this as well with the hpacucli utility.

=>ctrl slot=0 create type=ld drives=2I:1:5,2I:1:6,2I:1:7,2I:1:8 raid=1+0

This command should silently create the array. We will need to rerun the config command to see if the results have changed.

=> ctrl all show config

Smart Array P410i in Slot 0 (Embedded)    (sn: 50123456789ABCDE)

  array A (SAS, Unused Space: 0 MB)

     logicaldrive 1 (136.7 GB, RAID 1+0, OK)

     physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 72 GB, OK)
     physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 72 GB, OK)
     physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 72 GB, OK)
     physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 72 GB, OK)

  array B (SAS, Unused Space: 0 MB)

     logicaldrive 2 (273.4 GB, RAID 1+0, OK)

     physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 146 GB, OK)
     physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 146 GB, OK)
     physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 146 GB, OK)
     physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 146 GB, OK)

  SEP (Vendor ID PMCSIERA, Model  SRC 8x6G) 250 (WWID: 50123456789ABCED)

Success. We can see that our four unassigned physical drives have turned into a single RAID 10 logical drive. Now are are done in the hpacucli utility.

Our next step is to add the newly created RAID array as physical volumes under LVM.

[root@snoopy ~]# pvcreate /dev/cciss/c0d1
  Physical volume "/dev/cciss/c0d1" successfully created

Now that we have a physical volume we can create our volume group. In my example I already have a first volume group name vg0 so my new one here will be named vg1.

[root@snoopy ~]# vgcreate vg1 /dev/cciss/c0d1
  Volume group "vg1" successfully created

And following the creation of our volume group we can now carve it up into the logical volumes that you want to use. In my example I just want one logical volume that is going to include all of the space within vg1. This is where commonly you might make several smaller logical volumes depending upon your goals.

[root@snoopy ~]# lvcreate -l 100%FREE -n lv_data vg1
  Logical volume "lv_data" created

Before we continue we will examine the status of the volume groups and logical volumes just to ensure that everything is as we expect it to be.

[root@snoopy ~]# vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               0
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               273.40 GB
  PE Size               4.00 MB
  Total PE              69991
  Alloc PE / Size       69991 / 273.40 GB
  Free  PE / Size       0 / 0
  VG UUID               Edt4KX-Cfdv-rdpj-KtgJ-69o7-Sdom-uiWeo5

  --- Volume group ---
  VG Name               vg0
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                2
  Open LV               2
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               136.56 GB
  PE Size               32.00 MB
  Total PE              4370
  Alloc PE / Size       4370 / 136.56 GB
  Free  PE / Size       0 / 0
  VG UUID               p2asMu-lkgf-3wYd-GGXX-4Cjc-vedk-z090AD

[root@snoopy ~]# lvdisplay
  --- Logical volume ---
  LV Name                /dev/vg1/lv_data
  VG Name                vg1
  LV UUID                D7flkf-KYzz-EdUA-B5FL-rBKo-Hv0v-xYzkZl
  LV Write Access        read/write
  LV Status              available
  # open                 0
  LV Size                273.40 GB
  Current LE             69991
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:2

  --- Logical volume ---
  LV Name                /dev/vg0/lv_root
  VG Name                vg0
  LV UUID                TjeUwx-kt0G-CBnl-Dp7b-VBWZ-oaXv-2VjB63
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                128.56 GB
  Current LE             4114
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

  --- Logical volume ---
  LV Name                /dev/vg0/lv_swap
  VG Name                vg0
  LV UUID                31GU2w-Dl4s-EfXx-OQLk-XeAe-CtPW-2DDba5
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                8.00 GB
  Current LE             256
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

Everything looks good. Our new logical volume of /dev/vg1/lv_data is the expected size and ready to be used. Now we simply need to create a filesystem, a mount point and mount it. As this is Red Hat 5 that I am using in this example we will use ext3 as an our example filesystem. I would likely use ext4 on RHEL 6. BtrFS would be a logical option on a Suse or Oracle system today and will only continue to be more and more popular.

[root@snoopy ~]# mkfs.ext3 /dev/vg1/lv_data
mke2fs 1.39 (29-May-2006)
Filesystem label= 
OS type: Linux 
Block size=4096 (log=2) 
Fragment size=4096 (log=2)
35848192 inodes, 71670784 blocks
3583539 blocks (5.00%) reserved for the super user 
First data block=0 Maximum filesystem blocks=4294967296
2188 block groups
32768 blocks per group, 32768 fragments per group
16384 inodes per group
Superblock backups stored on blocks:
 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
 4096000, 7962624, 11239424, 20480000, 23887872, 71663616

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Now to create our mount point and mount our new filesystem. We’ll create the somewhat obvious mountpoint named /data.

[root@snoopy ~]# mkdir -p /data
[root@snoopy ~]# mount /dev/vg1/lv_data /data

Now that we have mounted successfully we can use the df command to test that everything is working as expected. No surprises here.

[root@snoopy ~]# cd /data
[root@snoopy data]# df -h .
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/vg1-lv_data
                      270G  192M  256G   1% /data

As you can see, our filesystem is looking good and is already usable. At this point everything is good but when we reboot our filesystem will be unmounted again. Not ideal for normal business usage. So we just need to append a line to our /etc/fstab file to automatically mount this new filesystem. This is my entry that I added:

/dev/vg1/lv_data   /data   ext3   defaults   0 0

IPTables is, without a doubt, one of the more frustrating components of Linux administration.  It is pretty much ubiquitous in need but documentation is often lacking and the differences in de facto use between distributions can create a degree of complexity that should be wholly unnecessary for such a common system function.  Red Hat (and ergo CentOS) uses its own tools to alter IPTables which, if you are limited to very basic needs as can be address pretty easily.  The Red Hat tools are great for doing the every day tasks like opening a needed port.

However, it is not uncommon to need a lot more flexibility in IPTables and once that is necessary the Red Hat tools make the job for more cumbersome and less portable.  For my own firewall administration I have moved to creating my own configuration file and loading it manually into IPTables.

You can put your configuration file anywhere that you want.  In etc makes sense, or in var, perhaps.  This is not the final configuration file, just an interim, so it is acceptable to keep in the var filesystem.

In this IPTables configuration file, you can place standard IPTables commands in the following format:

-bash-3.2$ sudo head /var/iptables_primary
-A INPUT -s 1.0.0.0/255.0.0.0 -j DROP 
-A INPUT -s 2.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 3.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 4.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 5.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 6.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 7.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 9.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 11.0.0.0/255.0.0.0 -j DROP
-A INPUT -s 12.0.0.0/255.0.0.0 -j DROP

This makes it very easy to test and modify your IPTables settings because the commands that you use to modify IPTables on the fly are exactly the same commands that you put into this file.  Now to actually use this file, we simply need to read it in line by line.  If you want to be sure that IPTables is in a clean state, stop it first and then load this file.  Don’t forget to save when you are done.  I’ll use the built in Red Hat / CentOS service commands below for the example.

service iptables stop
while read line; do iptables $line; done < /var/iptables_primary
service iptables save

And with that, your new IPTables configuration should be up and running and easy to edit.