Managing Multiple Cooks
Now, onto the Perl side of things. In order to make programming database access easier with Perl, the DBI modules were developed. DBI stands for Database Interface and consists of a collection of routines that offer standard hooks into an SQL database. DBD is an application program interface (API) for Perl 5 to interface with database systems. The idea is to provide a consistent set of modules and calls so that database access code is portable without too much fuss.
Now, since there are a number of database formats out there (PostgreSQL, MySQL, Sybase, Oracle, etc.), there will be some variance in accessing and talking to those various databases. This is where the DBD modules come into play. DBD are the Database Dependent modules. They are identified by the database they support by a simple suffix. For instance, DBD-Pg is the DBD module for PostgreSQL. Meanwhile, DBD-Informix is the DBD module for the Informix database.
Essentially, the DBI module is common to all the various databases, but the DBD module must be (and is) database-specific.
Both the DBD and DBI module can be found at the CPAN FTP site, a huge Perl resource on the Web. Because the two modules are in slightly different directories, I will give you both starting with the DBI module. See ftp://ftp.cpan.org/CPAN/modules/by-module/DBI/.
The DBD module can be found at the CPAN site at ftp://ftp.cpan.org/CPAN/modules/by-module/DBD/. At the time of this writing, the latest and greatest DBI version was DBI-1.14, whereas the DBD release number was DBD-Pg-0.95. It probably makes sense to get the latest and greatest when it comes to these modules, particularly if you are using the latest PostgreSQL. The reason for this is that the modules grow and develop with the databases they reference. The most recent PostgreSQL database is best served by the most recent DBD-Pg.
Install the DBI module first by unpacking the distributions into some temporary directory and following these steps:
cd /usr/local/temp_dir tar -xzvf DBI-1.14.tar.gz cd DBI-1.14 perl Makefile.PL make make test make install
To install the DBD module, the process is similar. Please note that more recent versions of the DBD module now require you to set a couple of environment variables before the install can occur. These are POSTGRES_LIB and POSTGRES_INCLUDE:
export POSTGRES_LIB=/usr/local/pgsql/lib export POSTGRES_INCLUDE=/usr/local/pgsql/includeNow, you can run the install:
cd /usr/local/temp_dir tar -xzvf DBD-Pg-0.95.tar.gz cd DBD-Pg-0.95 perl Makefile.PL make make test make install
Ah, la pièce de résistance. Start by downloading the latest release from the Salmar web site at http://www.salmar.com/gss/. Then, extract it into a temporary directory. Once again, it comes with a lovely little README file that you may want to indulge in. For the impatient, this is all you do:
tar -xzvf sciintra.tar.gz cd installintra
Before we begin the actual install, we must pause and modify one little configuration script. This is a small text file called sciintra_conf.pl, and you can edit it with your favorite text editor. Here is what you will find in the file.
The first thing to do is make sure that the path to your Perl executable is correct. It will either be /usr/bin/perl or /usr/local/bin/perl. Now, go down to the last three lines and fill in the path to your Apache server's document root and cgi-bin directory. What you see above is the file's default configuration. If this fits your own system configuration, then you don't have to change anything.
Now, it is time to finish our install:
Right away, the script does a couple of sanity checks, specifically to make sure that you have PostgreSQL running and Perl installed. Once satisfied, it will ask you an interesting little question:
Do you also wish to install the phonebook (Y/N) ?A call for you, perhaps? Can you hear the music, mes amis? Ah, memories. Think back to the June 2000 issue of Linux Journal. Chez Marcel's little kitchen turned up an intranet telephone book for the “Who's Who in Linux?” issue. Well, if you have our little phonebook installed, then you can reply with an “N” for no, otherwise, why not install this wonderful little phonebook? It will then be available from the Grand Salmar Station Intranet menu, and it will be wonderful, like this lovely little Syrah. Pardonner moi while I have a little sip. Ah, wonderful.
Next, you will be asked whether you wish to install the intranet. Well, mes amis. That is why we are here, non? Just respond with a “Y”. The install then calls a Perl script to do the rest of the installation. You are almost done, mes amis. One more thing.
As I mentioned in the introduction, Grand Salmar Station can automatically clean up after itself. If you decide to post a date-sensitive item, the software can automatically remove this item from the intranet after a specific date. To activate this feature, add the following command to run with cron:
You may, if you wish, copy it to some other location. We will discuss the security aspects of the administrator shortly.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
- Parsing an RSS News Feed with a Bash Script
- Rogue Wave Software's Zend Server
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide