Ensuring Streaming Capability

The first step is to ensure that we have the appropriate application for playing our music on hold stream. Because we will be using an MP3 stream, we will want to use mpg123. Unfortunately, the mpg123 application is not included in the Elastix distribution, so, let’s install it. We will also need to install other components/applications associated with mpg123:

Let’s start by downloading the RPM package for mpg123:

[root@server /]# cd /usr/src
[root@server /usr/src]# wget “ftp://ftp.sunet.se/pub/os/Linux/RPMForge/dag/redhat/el3/en/i386/RPMS.dag/mpg123-1.6.2-1.el3.rf.i386.rpm”

Next, well install the required applications to make mpg123 work (if you don’t want to explicitly run these, skip to installing the rpm and install the required application as you are requested):

[root@server /usr/src]# yum install audiofile
[root@server /usr/src]# yum install glibc
[root@server /usr/src]# yum install libtool-ltdl
[root@server /usr/src]# yum install esound

Finally, lets install mpg123:

[root@server /usr/src]# rpm -ivh mpg123-1.6.2-1.el3.rf.i386.rpm

Acquiring a Stream

The second step in configuring streaming music on hold is finding the stream you want to use. For this example, I will use a Digitally Imported stream named Chillout Dreams.

Because of the way that Firefox handles downloads, I’m going to demonstrate accessing the stream file using Firefox:

1. Open Firefox and browse to www.di.fm
2. Using the mouse, hover over the DI menu “Listen Now!”, then hover over “Chillout Dreams”, then hover over “MP3 Streams”, and finally click on “96k Cable/DSL”.
   
3. Once the download has completed, right click on listen.pls and then click on “Open Containing Folder”.
   
4. Using your favorite text editor, mine is UltraEdit, open listen.pls and select the http:// stream for file1 and copy to your clipboard.
   

Configuring Elastix

Now that you have a stream URL ready for use, open your Elastix web interface and click on the PBX tab.

1. Under PBX configuration, on the left side of the screen, click on the “Music on Hold” link from the Internal Options & Configuration section.
2. Now click on the “Add Streaming Category” on the right side of the screen.
3. In the Category Name field, enter whatever you wish, “DI-Chillout-Dreams”?
4. In the Application field, enter the following, then paste the stream URL at the end of the application string (replacing [streamURL] of course):

/usr/bin/mpg123 -q -s –mono -r 8000 -f 8192 -b 0 [streamURL]

Now that you have the Music on Hold defined, we need to configure your inbound and outbound routes to use the music on hold:

1. Click on the “Outbound Routes” and then click on your route(s), then in the drop down list for “Music on Hold?”, choose your new music on hold category.
2. Click on the “Inbound Routes” and then click on your route(s), then in the drop down list for “Music on Hold?”, choose your new music on hold category.

On the Back End

When  you created the music on hold category/application, the Asterisk file modified is /etc/asterisk/musiconhold_additional.conf, which is included in the base music on hold file /etc/asterisk/musiconhold.conf.

If you open the conf file in a text editor, you’ll notice the category/application that you added earlier.

-Aaron

As you may know, to make a Linux server replace a Windows file server you’ll need a common file sharing protocol between both server and client. Well, SAMBA is the answer. In reality I think that SAMBA is the only answer.

Installing SAMBA

To be honest, I just rebuilt my Linux machine this month and have already forgotten whether SAMBA came preinstalled on Ubuntu Server 9.10 or not. Even if it is already install, it doesn’t hurt to try installing it again:

aaron@server:/# sudo apt-get install samba

Among other files, the three files you will use the most in configuring SAMBA are the config file, /etc/samba/smb.conf, and the init script for the daemon, /etc/init.d/samba, and the SAMBA password tool, /usr/bin/smbpasswd.

Configuring Users and Groups for SAMBA

The first step is creating the users and groups that will be accessing the SAMBA share. In this example, we will use local Linux accounts and groups, then activate the user account in SAMBA. The group will be used to assign permissions to the directory in the Linux file system.

Because my set up is small, I have only a few accounts and one group that I use for SAMBA shares. The group has all SAMBA users in it and is named “dtusers”. Let’s work with my configuration as the example.

First, if you dare, switch to the root account (or best practice is to use sudo for every command):

root@server:/# sudo su

To create a new system group, use the following:

root@server:/# groupadd -r dtusers

Now that we have the group created, we should create some users as well. As we create the users, we will assign the group we just created as a supplemental group.

root@server:/# useradd -G dtusers -p P@ssW0rd aaron

Use the above command as many times as needed for your users. “aaron” is the username, by the way. Additional thought, “P@ssW0rd” is not a secure password, and even though SAMBA is configured to synchronize passwords (see “unix password sync” setting in the smb.conf file), we want to ensure a password is set prior to SAMBA configuration.

Finally, we need to enable these accounts using the SAMBA smbpasswd password tool.

root@server:/# smbpasswd -a aaron

When you are prompted for a password, use the same password as you did when you created the user. Use the above command as many times as needed for your users.

Configuring Directories for SAMBA Sharing

The next step is figuring out which directories you want to share through SAMBA. In my case, I created all of my shares under /datastore/. For the example, lets copy my configuration.

Create the /datastore/ root directory. Then create a directory named aaron, a directory named music, a directory named pictures and a directory named downloads.

root@server:/# mkdir /datastore
root@server:/# cd /datastore
root@server:/datastore# mkdir aaron
root@server:/datastore# mkdir music
root@server:/datastore# mkdir pictures
root@server:/datastore# mkdir downloads

Now that we have our directories created, we need to ensure owners and  permissions are set correctly for each of the directories.

First, we need to change the user and group owners. I recommend root as the main user for any “shared” directories:

root@server:/datastore# chown aaron:dtusers aaron
root@server:/datastore# chown root:dtusers music
root@server:/datastore# chown root:dtusers pictures
root@server:/datastore# chown root:dtusers downloads

Last, we need to change the permissions. I recommend 775 (see Unix Permissions at the bottom of this article for more info on 775) for any of the “shared” directories and 750 or 700 for the user specific directories.

root@server:/datastore# chmod 700 aaron
root@server:/datastore# chmod 775 music
root@server:/datastore# chmod 775 pictures
root@server:/datastore# chmod 775 downloads

Now, have a look at your directories to make sure they have the appropriate permissions:

Configuring SAMBA

The final step in configuring SAMBA is, well, configuring SAMBA. The SAMBA configuration file, smb.conf, that comes with the SAMBA install is rather large. We’ll go through it and change only some of the settings and add some of our own.

Using your favorite text editor (mine is actually vi, but if you are new to Linux, you’ll like nano better) and open the SAMBA configuration file:

root@server:/# vi /etc/samba/smb.conf

Scroll through the configuration file and review the various options. Once you have looked around, start changing variables. First if you have a DNS domain defined, I would change the following:

workgroup = dt.local

Next, scroll to the bottom of the configuration file and add your SAMBA share definitions. In this example, I have also configured a “create mask” which forces certain permission types for all new files, “directory mask” which forces certain permission types for all new directories, and “force group” to ensure the group is always my dtusers group:

[aaron]
path = /datastore/aaron
valid users = aaron
writable = yes
browseable = yes
read only = no
create mask = 0700
directory mask = 0700
guest ok = no
force group = dtusers

[music]
path = /datastore/music
valid users = @dtusers
writable = yes
browseable = yes
read only = no
create mask = 0775
directory mask = 0775
guest ok = no
force group = dtusers

[pictures]
path = /datastore/pictures
valid users = @dtusers
writable = yes
browseable = yes
read only = no
create mask = 0775
directory mask = 0775
guest ok = no
force group = dtusers

[downloads]
path = /datastore/downloads
valid users = @dtusers
writable = yes
browseable = yes
read only = no
create mask = 0775
directory mask = 0775
guest ok = no
force group = dtusers

You’ll notice that the [aaron] share contains “valid users” of only aaron, while the other “shared” shares contain “valid users” of @dtusers. The @ sign defines a group. If you have more than one group or users, separate them with a space.

Save the configuration file and then restart the SAMBA service:

root@server:/# /etc/init.d/samba restart

Using SAMBA

Now that you have SAMBA configured with some shares, give it a whirl from your Windows machine. If the user that you sign into on your Windows machine is the same, with the same password, as the Linux/SAMBA user you will not be prompted to authenticate.

Click Start > Run and then type in the UNC path to your Linux server. If you have a DNS host (A) record for your server it could be \\server\share_name, otherwise just use the IP address, \\192.168.0.1\share_name.

That’s it. Enjoy Linux!

Unix Permissions

764 defines the permissions for User (the 7)/Group (the 6)/Everyone (the 4). As another example, if you wanted only the User to have full permissions, assign 700, which is User (the 7)/Group (the 0)/Everyone (the 0).

The number represents the collective of permission types: 4 is Read, 2 is Write, 1 is Execute. So a 7 would be 4 + 2 + 1, which means that when assigned to the User, it will have all three permission types, or full control. A zero means no permission types, and therefore no permissions.

Links

http://www.samba.org/
http://support.quickbooks.intuit.com/support/Articles/HOW12300

-Aaron

http://linuxbites.wordpress.com/2010/03/26/configure-iscsi-in-centos-45-rehl-45/

-Aaron

This article is not to argument security threats, but instead to show you how to configure an NTP server on Ubuntu Server 9.10. Once you have the NTP Server functioning, you may configure devices that understand NTP to get time from your new NTP Server. Let’s get started.

Install NTP Server

Remember that installing packages in Linux will require elevated privileges, so make sure you sudo first.

1. root@server:/# apt-get install ntp

Configure the NTP Server

Next we will configure the NTP server to use a NTP pool and to allow access for your network to do NTP queries to this server.

1. root@server:/# vi /etc/ntp.conf

Locate the following section in the conf file:

# You do need to talk to an NTP server or two (or three).
server ntp.ubuntu.com

Change that to be this instead (servers from pool.ntp.org):

# You do need to talk to an NTP server or two (or three).
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server 3.pool.ntp.org

Next locate the “restrict” statements and add the following new line (replace with your subnet):

restrict 192.168.0.0 mask 255.255.255.0 nomodify notrap

Set Time on Server

This is an important step, as you will not be able to synchronize your NTP Server with the NTP pool time if the time is off by too many minutes.

Make sure the NTP Server is stopped, as the following command will require the same port:

1. root@server:/# /etc/init.d/ntp stop

Set the system time:

2. root@server:/# ntpdate pool.ntp.org

Start the NTP Server.

3. root@server:/# /etc/init.d/ntp start

Check the NTP Server Status

In order for your clients to be able to successfully query time from your new NTP Server, your NTP Server must be synchronized with the specified Internet NTP servers. After you have started the NTP Server, this may take 10 minutes for synchronization.

To check the status, use:

1. root@server:/# ntpq -pn

If you server is not synchronized yet, and assuming your configured the servers as explained above, you should see something similar to the following:

Once it is synchronized, it will display something similar to the following:

Notice the * and + symbols next to the IP addresses, the one with the * is the server that your computer is synchronized with.

Note: If you try to synchronize a Windows device with the NTP Server before it is synchronized with the Internet, you will probably receive an error similar to: “An error occurred while Windows was synchronizing with 192.168.0.10. The time sample was rejected because: The peer’s stratum is less than the host’s stratum.”

For this example we will use atftp daemon, which is apparently the best solution for Linux at the time of this article.

Install atftpd

Obviously the installation requires root access, so make sure that you sudo.

1. root@server:/# apt-get install atftpd

Configure atftpd

1. root@server:/# vi /etc/default/atftpd

We are going to change USE_INETD to false and then if you feel like it, remove some of the options. Be sure to add the option “–daemon”, as shown below:

USE_INETD=false
OPTIONS=”–tftpd-timeout 300 –retry-timeout 5 –maxthread 100 –verbose=5 –daemon /var/lib/tftpboot/”

If you do not add the –daemon option, then atftpd daemon will not start when you restart with /etc/init.d/atftpd restart. Instead it will display the atftpd options, as though you ran the binary file from /usr/sbin/atftpd.

If you are interested in learning about the options, be sure to read the atftpd man page.

2. root@server:/# /etc/init.d/atftpd restart

This command will restart the deamon with the new settings.

Testing the TFTP Server

The final step, unless you think you are totally awesome or trust my articles, is to test the TFTP server to make sure that it works. You can accomplish this from a Windows machine by running a command similar to (the -i means binary trasnfer):

1. C:\tftp -i server_address put picture.gif

From a Linux machine, you can install tftp (apt-get install tftp).

Other Notes

I didn’t like the default location of /var/lib/tftpboot/ for the files to be stored. I have a directory called /datastore/ that I put all of my files into for backup purposes.

After attempting to configure atftpd to use a different location, such as changing the path specified in /etc/default/atftpd, I was unable to change to a new location. With that stated, I made a symbolic link in /datastore/ to point to /var/lib/tftpboot/, which is good enough for me.

1. root@server:/datastore# ln -s /var/lib/tftpboot/ ./tftproot

Recently I migrated core functionality from my home Windows 2000 Server to a new host running ESXi 4.0 with three Ubuntu Server 9.10 VMs. If you want to see a simple diagram on my set up, view my article on Linux Backup Shell Script. One of the core functionality that I migrated was my internal DNS services. Hence the title of this article, DNS Server with Bind9.

bind9

I am impressed, once again, with Linux and the services residing within this amazing operating system. The most amazing part about Linux services is that many of them have been around as long as I have — where have I been?

Before I begin rambling too much, let’s get started on creating DNS forward and reverse zones for your local network …

First ensure you have bind9 installed by running the following command:

whereis bind

If the results is blank, such as just “bind: “, then you will need to install bind9. On Ubuntu, I would imagine the command would look like this:

sudo apt-get install bind9

Forward Zones

We need to configure your DNS forward zones, which will provide name to address resolution in your internal network. As we progress the configuration, keep in mind that your specific configuration will be slightly different than mine; adapt as needed.

For simple networks, such as mine at home, there are only a few changes that you will need to make for Forward lookup zones. The first file is /etc/bind/db.local.

/etc/bind/db.local

The changes are fairly easy because we going to use most of what is provided in the original file. Change the Start of Authority (SOA) to be the domain environment for your network. My domain is dt.local and my primary DNS server is dtsfile.dt.local. Change the SOA to reflect your choices and also change the nameserver (NS) line to be your primary DNS server.

Also, you will want to add A records for your various servers/computers on the network. For this example, I added my Asterisk server:

dtsvoip.dt.local.	IN	A	192.168.0.11

The next file to change, which we will also make changes for reverse DNS at the same time, is the /etc/bind/named.conf.default-zones file.

/etc/bind/named.conf.default-zones

The line for the primary zone, which references the /etc/bind/db.local file must state your local domain in the quotes following the zone directive:

zone “dt.local” {
  type master;
  file “/etc/bind/db.local”;
};

As we have more changes in this file, leave it open and continue to the next section.

Reverse Lookup Zones

As you probably know, a reverse lookup provides a name to an IP address. In Windows you would find the name of 192.168.0.10 by typing “nslookup 192.168.0.10” from a command prompt. If you have configured reverse DNS properly, you will see output similar to this:

C:\>nslookup 192.168.0.10
Server:  dtsfile.dt.local
Address:  192.168.0.10

Name:    dtsfile.dt.local
Address:  192.168.0.10

You may be wondering why the entry appears twice. This is because the Server and the name that I am looking up is the same server. If I were to locate my Asterisk server, it would look like this:

C:\>nslookup 192.168.0.11
Server:  dtsfile.dt.local
Address:  192.168.0.10

Name:    dtsvoip.dt.local
Address:  192.168.0.11

On with the configuration…

/etc/bind/named.conf.default-zones

If you were paying attention in the previous section you would still have that file open. Regardless, let’s add another zone to the file that represents our reverse lookup for the IP subnet in your network. In my network I use 192.168.0.0/24 which is the same as saying 192.168.0.0 with a subnet of 255.255.255.0 (192.168.0.0 to 192.168.0.255).

Immediately after the zone directive for your domain, add the following text for your reverse lookup:

zone “0.168.192.in-addr.arpa” {
  type master;
  file “/etc/bind/db.0.168.192”;
};

If you’re sharp, you’ll immediately know that the file db.0.168.192 doesn’t exist. We’ll create it next. And yes, it’s backwards; in reverse DNS lookups the IP address is reversed as part of the requirements set in the RFC and obviously for functionality pointing back to the host name of the IP. Read more: http://en.wikipedia.org/wiki/Reverse_DNS_lookup

Save changes to named.conf.default-zones.

/etc/bind/db.0.168.192

Next we’ll create a new zone db file for our newly created reverse lookup. Start by copying db.0 into a new file named db.0.168.192 (or whatever your local subnet IP address is).

cp /etc/bind/db.0 /etc/bind/db.0.168.192

Just like in your db.local file, let’s change the SOA to reflect your domain and nameserver. This includes the NS line that should already exist in the file. Now let’s add pointer (PTR) records for your servers/computers on the network. I’ll use mine for examples:

10	IN	PTR	dtsfile.dt.local
11	IN	PTR	dtsvoip.dt.local

Save changes to db.0.168.192.

Forwarders

The last section, assuming you want to use this DNS server as your primary DNS on all computers, is to set up a forwarder for all names that are not a part of your network. You will need to edit /etc/bind/named.conf.options.

/etc/bind/named.conf.options

The change is really simple, uncomment the forwarders directive and modify the IP address within to be your local router or your ISP DNS servers. Mine is similar to the following:

forwarders {
  192.168.0.1;
};

Local Name Resolution

The final step is to change your /etc/resolv.conf file to point your DNS server and to set the domain and search realm. This is what mine looks like:

domain dt.local
search dt.local
nameserver 192.168.0.1

Restart the bind9 daemon

After making all of these changes, the final is to restart the bind9 daemon. Oh, one other step is to change your computers to use this DNS server as the primary.

Configuration Files Examples

/etc/bind directory listing

/etc/bind# ls -la
drwxr-sr-x   2 root bind  4096 2010-08-01 17:52 .
drwxr-xr-x 141 root root 12288 2010-08-01 17:54 ..
-rw-r--r--   1 root root   237 2009-08-19 15:00 db.0
-rw-r--r--   1 root root   271 2009-08-19 15:00 db.127
-rw-r--r--   1 root bind   295 2010-08-01 17:22 db.0.168.192
-rw-r--r--   1 root root   237 2009-08-19 15:00 db.255
-rw-r--r--   1 root root   353 2009-08-19 15:00 db.empty
-rw-r--r--   1 root root   316 2010-08-01 17:14 db.local
-rw-r--r--   1 root root  2940 2009-08-19 15:00 db.root
-rw-r--r--   1 root bind   463 2009-08-19 15:00 named.conf
-rw-r--r--   1 root bind   573 2010-08-01 16:50 named.conf.default-zones
-rw-r--r--   1 root bind   165 2009-08-19 15:00 named.conf.local
-rw-r--r--   1 root bind   570 2010-07-16 11:58 named.conf.options
-rw-r-----   1 bind bind    77 2010-01-30 11:50 rndc.key
-rw-r--r--   1 root root  1317 2009-08-19 15:00 zones.rfc1918

./db.0.168.192

;
; BIND reverse data file for broadcast zone
;
$TTL    604800
@       IN      SOA     dt.local. dtsfile.dt.local. (
        1         ; Serial
   604800         ; Refresh
    86400         ; Retry
  2419200         ; Expire
   604800 )       ; Negative Cache TTL
;
@       IN      NS      dt.local.
10     IN      PTR     dtsfile.dt.local.
11     IN      PTR     dtsvoip.dt.local.

./db.local

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     dt.local. dtsfile.dt.local. (
        2         ; Serial
   604800         ; Refresh
    86400         ; Retry
  2419200         ; Expire
   604800 )       ; Negative Cache TTL
;
@       IN      NS      dtsfile.dt.local.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1
dtsvoip.dt.local.       IN      A       192.168.0.11

./named.conf.default-zones

// prime the server with knowledge of the root servers
zone "." {
  type hint;
  file "/etc/bind/db.root";
};

// be authoritative for the localhost forward and reverse zones, and for
// broadcast zones as per RFC 1912

zone "dt.local" {
  type master;
  file "/etc/bind/db.local";
};

zone "0.168.192.in-addr.arpa" {
  type master;
  file "/etc/bind/db.0.168.192";
};

zone "127.in-addr.arpa" {
  type master;
  file "/etc/bind/db.127";
};

zone "0.in-addr.arpa" {
  type master;
  file "/etc/bind/db.0";
};

zone "255.in-addr.arpa" {
  type master;
  file "/etc/bind/db.255";
};

./named.conf.options

options {
directory "/var/cache/bind";

// If there is a firewall between you and nameservers you want
// to talk to, you may need to fix the firewall to allow multiple
// ports to talk.  See http://www.kb.cert.org/vuls/id/800113

// If your ISP provided one or more IP addresses for stable
// nameservers, you probably want to use them as forwarders.
// Uncomment the following block, and insert the addresses replacing
// the all-0's placeholder.

forwarders {
  192.168.0.1;
};

auth-nxdomain no;    # conform to RFC1035
  listen-on-v6 { any; };
};

/etc/resolv.conf

domain dt.local
search dt.local
nameserver 192.168.0.1

Onward and upward, today I will share a script I use for backing files on my Ubuntu Server. To start off and to help explain what the script does, let me first explain my configuration. I have an ESXi 4.0 server with 3 VMs, all Ubuntu Server instances for Core services (DNS, DHCP, Directory services), Email (Yahoo’s Zimbra), and File (SAMBA shares, LAMP). All of the servers have 30GB primary partitions, provisioned through VMware and located on an internal 500GB SATA. The File server has a additional partition on the 500GB drive for all SAMBA shares and a partition located on an internal 1TB SATA drive that is used for backup.

The script provides backup functionality for my music, pictures, user’s folders, et cetera to the backup drive. The secondary partition on the 500GB drive is mounted to /datashare/ and the tertiary partition on the 1TB drive is mounted to /databackup/.

The Script

#!/bin/sh
#####
#  backup files script, version 1.
#
#  this script keeps one tar file per month for 12 months and rsyncs the entire contents
#  to $destination/daily_replica.
#  the idea is to run this script at least once per day to ensure proper sync and monthly tar.
#
#  created by Aaron @ www.devtrends.com
#####

# location of backup files (recursive sub-folders).
backup_files="/datastore/share"

# location to place tar files and /daily_replica/ directory.
destination="/databackup/share"

#### no editing beyong this line is required!
#### function for TARing
funcTar()
{
 options="--create --file="
 echo " -- tar'ing up $1 to $2/$3"
 echo "   \ creating new archive file: $3"
 tar $options$2/$3 $1
 echo "   \ tar backup completed."
}
#### end funcion

#### CREATE MONTHLY TAR FILE
# Create new archive filename.
month=$(date +%m)
year=$(date +%Y)
archive_file="backup-$month.tar"
full_path_archive_file="$destination/$archive_file"

# do I need to create a new monthly archive file?
# check if the file exists
if [ -f $full_path_archive_file ]; then

 # get file date
 filedate=$(stat -c %y $full_path_archive_file)
 # extract only the year of the file
 filedate=${filedate:0:4}

 # check if the file year is not the current year
 if [ ! $filedate == $year ]; then

 # remove old file
 rm $full_path_archive_file
 # create new tar
 funcTar $backup_files $destination $archive_file

 else

 echo " -- no tar'ing required today."

 fi

else

 # create new tar
 funcTar $backup_files $destination $archive_file

fi
#### DONE WITH TAR

#### rsync time...
echo " -- rsync $backup_files to $destination/daily_replica"
rsync -a $backup_files $destination/daily_replica
echo "   \ rsync completed."
####

If you hate copy and paste, you may download the script here.

Explanation

For those that care, let me explain the script. The first two variables, $backup_files and $destination, should be the only variables you will need to change if you wish to use the script as I do.

# location of backup files (recursive sub-folders).
backup_files="/datastore/share"

# location to place tar files and /daily_replica/ directory.
destination="/databackup/share"

The next block of code is the function used to create the tar file. The reason I made it into a function is because I use the same block of code twice in the main section of the script. No reason to duplicate code. However, the way I implemented the function may cause a problem if your $backup_files or $destination variables contain spaces. If anyone would like to revised, please share. The $1, $2, et cetera, are the argument variables as passed by the calling statement.

funcTar()
{
 options="--create --file="
 echo " -- tar'ing up $1 to $2/$3"
 echo "   \ creating new archive file: $3"
 tar $options$2/$3 $1
 echo "   \ tar backup completed."
}

Next I define some variables that I will use throughout the script. The first two are date strings that contain the month (e.g. 11) and the year (e.g. 2009). The third and fourth variables hold the location of the tar file. The tar file name is comprised of the word “backup-” and then the variable of the month.

month=$(date +%m)
year=$(date +%Y)
archive_file="backup-$month.tar"
full_path_archive_file="$destination/$archive_file"

The main section of code is next and consists of a nested if statement. The first if statement checks if a current backup tar file exists, if not, then it will create one, otherwise it will check the status of the current backup tar file. If the current tar file modified date is not in the current year, then it removes that tar file and recreates it, otherwise there is no need to tar anything. The most interesting piece is the substring command, ${filedate:0:4} which only returns characters 0,1,2,3 from the variable $filedate. You will also notice the use of stat, which, depending on your distribution of Linux, you may need to manually acquire.

# do I need to create a new monthly archive file?
# check if the file exists
if [ -f $full_path_archive_file ]; then
 # get file date
 filedate=$(stat -c %y $full_path_archive_file)
 # extract only the year of the file
 filedate=${filedate:0:4}

 # check if the file year is not the current year
 if [ ! $filedate == $year ]; then
  # remove old file
  rm $full_path_archive_file
  # create new tar
  funcTar $backup_files $destination $archive_file
 else
  echo " -- no tar'ing required today."
 fi

else
 # create new tar
 funcTar $backup_files $destination $archive_file
fi

The last statement is the rsync command which synchronizes the entire content of the $backup_files location to the $destination/daily_replica/ location.

echo " -- rsync $backup_files to $destination/daily_replica"
rsync -a $backup_files $destination/daily_replica
echo "   \ rsync completed."

Use this script at your own risk. If it turns out it didn’t back up your stuff, that is entirely your problem, not mine.

-Aaron Gilbert

VGA Mode

For those DOS’ers, do you remember “mode 80″ or “mode 40″? If you know of a quick command for Linux consoles let me know … otherwise, you can use the tip below to modify your screen resolution.

/boot/grub/menu.lst

The key to changing the screen mode / screen resolution is to modify the menu.lst file and add the vga=[mode #] some where in the kernel call line – or at the end of it. After searching the Internet for some time, I compiled a list here of many of the vga modes available:

VGA MODE          MODE#
80x25              3840
80x50              3841
80x43              3842
80x28              3843
80x30              3845
80x34              3846
80x60              3847
320x200x8bit        816
320x200x16bit       782
320x200x32bit       783
320x240x8bit        820
320x240x16bit       821
320x240x32bit       822
640x480x8bit        769
640x480x16bit       785
640x480x32bit       786
800x600x8bit        771
800x600x16bit       788
800x600x32bit       789
1024x768x8bit       773
1024x768x16bit      791
1024x768x32bit      792
1280x800x8bit       864
1280x800x32bit      865
1440x900x8bit       868
1440x900x32bit      869

On my Ubuntu Server, the kernel line was:

kernel         /vmlinuz-2.6.28-11-server root=/dev/mapper/ubuntuserver-root ro quiet splash

and I added vga=792 to the end of it:

kernel         /vmlinuz-2.6.28-11-server root=/dev/mapper/ubuntuserver-root ro quiet splash vga=792

I’m out…

SUN iSCSI Initiator

Obviously you need to have your network configured properly prior to working with the iSCSI initiator or targets. In this example, I was working with the iSCSI initiator and target in a lab environment, with the host (target) being 192.168.0.18 and the client (initiator) being 192.168.0.19. Secondly, you will need the iSCSI initiator software to be installed from Package Manager – easiest way is to search for iscsi and ensure all four of those packages are installed.

For this example we will use Send Targets for discovering iSCSI targets/paths:

iscsiadm add discovery-address 192.168.0.18:3260
iscsiadm modify discovery --sendtargets enable

Now that you have added the discovery address of the iSCSI target and enabled the discovery “Send Targets”, check to see if your target was discovered:

iscsiadm list target

If you saw the targets you were expecting, the next step is to create the device links between iSCSI and your system – so you can see the iSCSI LUN as a disk on your system.

devfsadm -i iscsi

Check the available disks on your system using the format command. After running the format command, hit CTRL-C to bounce back to the terminal prompt.

Using / Mounting the iSCSI LUN

Now that you have the iSCSI initiator working properly and the iSCSI targets discovered, lets actually use the new iSCSI disk with ZFS.

First we need to create the ZFS pool using the new disk. If you forgot the name of the new disk, you can learn it using the format command. If it is anything like the one on my OpenSolaris box, the name is rather large, (c0t600144F0F9A00C0000004AA9510A0001d0):

zpool create diskpool c0t600144F0F9A00C0000004AA9510A0001d0

To verify the pool was created, use:

zpool list

Now we can create a ZFS file system on top of that pool:

zfs create diskpool/test

Check your new ZFS filesystem was created:

zfs list

And now you can create files within the mount point:

root@opensolaris:/diskpool/test/#

Everything you write to that mount point will be written to the iSCSI target, as one would hope.

Good luck with your performance!

Credits

http://wikis.sun.com/display/OpenSolarisInfo/How+to+Configure+an+iSCSI+Initiator

I owe some of my new-found knowledge to my friend Chuck Hechler and the remaining to Mike La Spina (http://blog.laspina.ca/). I don’t pretend to be anywhere as knowledgeable about OpenSolaris, ZFS, iSCSI, SANs, or storage in general as Mike or Chuck, however, I can create SharePoint workflow actions in VisualStudio, can they? =)

The Equipment

If you read my other posts on the IET and RedHat implementation, you would know that I created a custom server housed in a SuperMicro case. During the testing phase of that project, I learned that the IET product does not work well with the LSI MegaRAID 84016 controller, specifically when using RAID5. Unsure why, however, in OpenSolaris, I had an issue with our Adaptec 31605 controller and ended up using the LSI MegaRAID 84016E controller. Works like a charm. I mention this as you will need to verify that the equipment you are going to use with OpenSolaris should be supported by OpenSolaris (http://www.sun.com/bigadmin/hcl/).

If you want more information on the hardware specifications for the system I used, please review my Custom Server Case article.

OpenSolaris Configuration

Using OpenSolaris to serve as an iSCSI target is surprisingly easy to configure. I say surprisingly because the same implementation in RedHat was thoroughly difficult, both due to a learning curve and due to many complications with functionality. On to OpenSolaris!

As I designed this system, I was focused on using ZFS as the sole solution for disk management and the file system. In other words, for my boot disks, I created a ZFS mirror and for the iSCSI LUN disks I created a ZFS raidz2.

Installation

For the most part, the default installation settings were used. Too be honest, the options during installation of OpenSolaris are limited. If you do not want the graphical interface, see my short article, Disable GUI, for disabling it after installation.

ZFS

Boot pool – mirror

Mirroring the boot partition is about as difficult as it gets with this article. I did not figure out how to mirror the boot disk on my own. Using the steps in the following blog post, I managed to mirror my ZFS boot partition, rpool.

http://darkstar-solaris.blogspot.com/2008/09/zfs-root-mirror.html
If you do not know the devices names of your drives, you can use “# format” to list the drives/devices on your system.

After the mirroring has been completed, display the status of the pool using the command and output below:

# zpool status
  pool: rpool
 state: ONLINE
 scrub: none requested
config:

 NAME        STATE     READ WRITE CKSUM
 rpool       ONLINE       0     0     0
   mirror    ONLINE       0     0     0
     c8d0s0  ONLINE       0     0     0
     c9d0s0  ONLINE       0     0     0

errors: No known data errors

iSCSI pool – raidz2

After reading quite a few posts on best practices for ZFS pools, I propose that you use a raidz set per controller. In my instance, I had a 16 port controller and all 16 drives for the iSCSI pool were connected to this controller. Using the following commands I created a raidz2 pool with 2 spares:

# zpool create diskpool raidz2 c7t0d0 c7t1d0 c7t2d0 c7t3d0 c7t4d0 c7t5d0 c7t6d0 c7t7d0 c7t8d0 c7t9d0 c7t10d0 c7t11d0 c7t12d0 c7t13d0
# zpool add diskpool spare c7t14d0 c7t15d0

That is it; we just created a large disk pool of 16 disks, 14 in a dual-parity set for volumes and 2 for spares. Easy? Yes.

Volumes

Best practice for creating ZFS volumes depends on your perspective. In my case, the iSCSI target will be used with VMware and I will create a new ZFS volume and iSCSI view for each VMware machine (not host). Follow the command below to create the base mountpoint in the ZFS pool:

# zfs create diskpool/iscsi

Next we will create a volume for sharing as an iSCSI target. As I stated above, I create one volume per VM. Also, notice the “-b 64K”, which helps with partition alignment in VMware. The command “-V 40G” creates a volume with a maximum size of 40 gigabyes – keep in mind that ZFS will thin provision the file system.

# zfs create -s -b 64K -V 40G diskpool/iscsi/lun0_vm

Display the pool and the ZFS volumes as shown below:

# zpool status
  pool: diskpool
 state: ONLINE
 scrub: resilver completed after 0h32m with 0 errors on Wed Sep  2 10:52:54 2009
config:

 NAME           STATE     READ WRITE CKSUM
 diskpool       ONLINE       0     0     0
   raidz2       ONLINE       0     0     0
     c7t0d0     ONLINE       0     0     0
     c7t1d0     ONLINE       0     0     0
     c7t2d0     ONLINE       0     0     0
     c7t3d0     ONLINE       0     0     0
     c7t4d0     ONLINE       0     0     0
     c7t5d0     ONLINE       0     0     0�
     c7t6d0     ONLINE       0     0     0
     c7t7d0     ONLINE       0     0     0
     c7t8d0     ONLINE       0     0     0
     c7t9d0     ONLINE       0     0     0�
     c7t10d0    ONLINE       0     0     0
     c7t11d0    ONLINE       0     0     0�
     c7t12d0    ONLINE       0     0     0
     c7t13d0    ONLINE       0     0     0�
 spares
   c7t14d0      AVAIL
   c7t15d0      AVAIL

errors: No known data errors

  pool: rpool
 state: ONLINE
 scrub: none requested
config:

 NAME        STATE     READ WRITE CKSUM
 rpool       ONLINE       0     0     0
   mirror    ONLINE       0     0     0
     c8d0s0  ONLINE       0     0     0
     c9d0s0  ONLINE       0     0     0

errors: No known data errors

# zfs list
NAME                             USED  AVAIL  REFER  MOUNTPOINT
diskpool                         9.9G  6.76T  51.1K  /diskpool
diskpool/iscsi                   9.9G  6.76T  48.5K  /diskpool/iscsi
diskpool/iscsi/lun0_vm     9.9G  6.76T   9.9G  -
rpool                           10.8G  62.1G  77.5K  /rpool
rpool/ROOT                      3.18G  62.1G    19K  legacy
rpool/ROOT/opensolaris          3.18G  62.1G  3.04G  /
rpool/dump                      3.75G  62.1G  3.75G  -
rpool/export                     114M  62.1G    21K  /export
rpool/export/home                114M  62.1G    21K  /export/home
rpool/export/home/vcssan         114M  62.1G   114M  /export/home/vcssan
rpool/swap                      3.75G  65.7G   101M  -

Network

There are a few approaches to spreading the load across multiple links, my favorite is LACP, which is what I used – see my article on LACPBONDING. The other option that may arise in the planning phase is IPMP. However, I was unable to overcome the issue of having more than one inbound interface. If you are knowledgeable with source addressing, you will have better luck than I did.

I aggregated 4 gigabit links together using LACP and a Dell PowerConnect 5448 switch.

iSCSI

During the design phase, I tested both of SUN’s iSCSI targets, the standard iscsitadm and COMSTAR iSCSI. At this point, you can choose one based on word of mouth, or you can try both and use the one that works the best for you. I ended up using COMSTAR.

iscsitadm

The first configuration change we will make defines which interfaces the iSCSI target software will use. We accomplish this by creating a target group:

# iscsitadm create tpgt 1
# iscsitadm modify tpgt –i 192.168.0.101 1

Because I am using link aggregation there is only one IP address to add to the group. If you decide to use multi-pathing as provided by VMware, you will need to add all of those IP addresses to the group.

Are you ready for the next statement, it is very complex…well, maybe not.

# zfs set shareiscsi=on diskpool/iscsi/lun0_vm

That’s it; the ZFS volume is now served through the iSCSI target.

COMSTAR

On a default installation of OpenSolaris, you will need to install the COMSTAR iSCSI software package. Open the Package Manager and search for iSCSI, choose to install all of them, specifically the SUNWiscsit package.

After you have installed the software package, you will need to enable the COMSTAR iSCSI service:

# svcadm enable -r svc:/network/iscsi/target:default

I am having a vague recollection that you may need to restart OpenSolaris before continuing…

The next configuration we will make defines which interfaces the iSCSI target software will use. We accomplish this by creating a target group and target:

# itadm create-tpg iscsi0 192.168.0.101
# itadm create-target –t iscsi0

Now, we will share the ZFS volume through the COMSTAR iSCSI target – this is a two step process:

# sbdadm create-lu /dev/zvol/rdsk/diskpool/iscsi/lun0_vm

Now let’s check for the new logical unit and remember the GUID… as we will use it in the next command:

# sbdadm list-lu

Found 1 LU(s)

       GUID                    DATA SIZE           SOURCE
--------------------------------  -------------------  ----------------
600144f08e6c0f0000004a8331d70002      42949607424      /dev/zvol/rdsk/diskpool/iscsi/lun0_vm

Now we will add the view to share the ZFS volume through iSCSI:

# stmfadm add-view 600144f08e6c0f0000004a8331d70002

That’s it!

I’m out….