May 2010 Archives

Perl Module WebService::Viddler on CPAN

| | | |

Back in March I outlined an idea for a Perl module for accessing the video service Viddler. As I noted, at the time, while there was plenty of support for the Viddler Application Programming Interface via PHP, the support for Perl was quite anemic.

To help rectify the situation, in my "copious" free time I've been working on an Perl module that wraps around Viddler's API. The goal being to provide a quick method for integrating Perl-based applications with Viddler.

Today, I'm happy to announce the first working release of my effort, WebService::Viddler, which can be found at CPAN (Comprehensive Perl Archive Network).

As I mentioned, at the heart of things, WebService::Viddler is an object-oriented encapsulation of the Viddler video platform providing a Perl specific focus for access via their public API, which itself is documented at:

Currently this module is, at best, beta quality code and only supports version 1 of the Viddler API. Moreover, while it handles most of the v1 API methods, it currently lacks support for the two commenting related methods, videos-comments-add and videos-comments-remove (a more complete To Do list can be found in the provided README file.

Of course the advantage of the module is that it makes including Viddler in a Perl-based application, dead simple:

#!/usr/bin/perl -T

use strict;
use warnings;

use WebService::Viddler;
use Data::Dumper;

# Create our object and establish a session
my $videos = new WebService::Viddler( 
                         apiKey => '123456ABCDEF',
                         username => $username,
                         password => $password,

# Get and print the API version is use
print "API Version: " .$videos->api_getInfo(). "\n";

# Upload a video providing required information such as the 
# title, tag and description
                         "A little video clip of...", 

# Get the details of the given video and
# use Data::Dumper help print out the values in the list results
print Dumper( $videos->videos_getDetailsByUrl( 
              "" ));

# Get a list of videos by the given tag and
# use Dumper to help print out the values in the list results
print Dumper( $videos->videos_getByTag( "moon" ));

Questions, bugs and code suggestions are of course welcomed!

A Step Beyond a Red Hat Enterprise Linux, Apache, MySQL and PHP How To

| 1 Comment
| | | |
Server Room

Image by pdweinstein via Flickr

It seems quite a bit of my time has been taken up with system administration related tasks these days. If I'm not contemplating system monitoring solutions for one client, I must be busy migrating a mail service from one server location to another.

Naturally, I was hardly surprised when I got an email from an old high school friend recently asking for assistance in setting up a Linux, Apache, MySQL and PHP (LAMP) server on Red Hat Enterprise Linux (RHEL).

Now said friend is hardly a technical novice and Google is happy to provide one with plenty of step-by-step how to's on the subject. So instead of running down the usual I figured, since he understands the technical side, but is probably more at home with Microsoft-based solutions, that I would give him some tips to orient himself.

Thus here is a quick and dirty "what's happening" (instead of the more common how to) on installing LAMP on a RHEL based system.

Helpful Tools

Since most, if not all, of these commands deal with system-wide alterations first and foremost one will need to have "superuser" access. That can be accomplished in one of two ways:

  • root user: root is the conventional name of the user who has rights to all files and programs on a Unix-based system such as Red Hat Enterprise Linux. In other words root is the main administrator for the system and can do anything at anytime.

  • sudo: sudo is a command that allows users to run programs with the security privileges of another user (normally the superuser, root). sudo usage needs to be granted to a user before it can be used and can be limited to a subset of privileges if needed.

There are plenty of commands that one can execute at the command line. Just remembering them all can be hard, let alone remembering how exactly each command works, in what context and with what arguments. For that alone one should always remember that help is always one command away:

  • man: man is a command (and format) for displaying the on-line manual pages. The man command followed by the name of the command who's documentation you wish to view will provide an display of that documentation.

For example to view the manual pages in regards to the man command itself:

$ man man

A key characteristic of Unix-centric systems is the use of plain text for data storage. This means that the focus of data manipulation is based on the fundamentals of text processing. It also means that data can be "piped" from one command-line tool to another for performing a task that might be more complicated for just one tool to complete.

While text processing isn't necessary for setting up a LAMP server what is necessary to know and have ready to use is at least one general, text-based tool; a text editor.

  • vi: vi, vim, emacs or pico each is a command line text editor and while I try to be agnostic in the eternal debate about which is better, I will mention that for as long as I've been a Unix user/admin (some 15 years now) no matter what system I am on, be it a Red Hat distribution of Linux or a proprietary system chances are vi or vim has been installed and is available.1

Installing Software

Red Hat Enterprise Linux uses a software package format called rpm. Each software package consists of an archive of files along with information about the package like its version and a description of the software within.

As a general practice packages are broken up into two separate packages; One contains the compiled executable, while a second one contains the source files for building the software from scratch2. The source code packages will usual have a "-devel" appended to their name field.3

However, back in the early days of rpm it was discovered that managing individual rpm packages is a pain and time consuming4. As such, a number of rpm-based Linux distributions have adopted tools such as yum. yum assists in managing the identification of dependencies for a given software package as well as installing said packages, tracking updates for a given package from a specified repository and removing installed software from the system as desired.


Using yum with the list argument will provide information about a given package's availability. For example to check on the Apache Web Server, which is officially known as the Apache HTTP Server:

$ yum list httpd
Loaded plugins: fastestmirror
Installed Packages
httpd.i386     2.2.3-31.el5.centos.2     installed
Available Packages
httpd.i386     2.2.3-31.el5.centos.4     updates  

As you can see httpd is not only available, but is also already installed5.


If, however, the Apache HTTP Server wasn't the install argument for yum would do the trick.

$ yum install httpd
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * addons:
 * base:
 * extras:
 * updates:
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package httpd.i386 0:2.2.3-31.el5.centos.4 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

 Package     Arch     Version               Repository       Size
 httpd       i386     2.2.3-31.el5.centos.4 updates         1.2 M

Transaction Summary
Install      1 Package(s)        
Update       0 Package(s)        
Remove       0 Package(s)        

Total download size: 1.2 M
Is this ok [y/N]:

Now it so happens that installing of Apache HTTP Server on the example system at the given time, didn't require any additional software packages to for the installation. This might not always be the case and as such, yum will identify and list any packages it determines are missing from the system to be installed at the same time, for the Apache Software Foundation's web server to be useful.


One of the key advantages of a package management system such as yum in the ability to easily track updates. The update feature can be used in two distinct manners. If used without explicitly naming a given packages, update will check for and then update every currently installed package that has a newer package available from the repository.

If, on the other hand, one or more packages are specified, yum will only update the listed package. As with installing the initial package, while updating, yum will ensure that all dependencies are installed.


Of course if yum can install and update software, it only makes sense that it can also remove the installed software from a given system. The remove argument is used to remove a specified package from the system as well as removing any packages which depend on the package being removed.

Note that this is basically the exact opposite of the install option. Install will add any software the package requires to run and the requested software itself. Remove, however, removes the requested software and any software that depends on it.

Configuring Software

Once each component is installed, it's time to go about configuring each one. The general convention for Unix-based systems such as Red Hat's Enterprise Linux is to place system-wide configuration files in the /etc directory. If fact, while the specifics can vary, the directory structure from Unix system to Unix system will general follow the same over all pattern.

Again staying with our web server example, the main Apache HTTP Server configuration file can be found at /etc/httpd/conf/httpd.conf on a Red Hat Enterprise Linux system. To open the configuration file for review and possible modification using the vi text editor is as simple as:

$ vi /etc/httpd/conf/httpd.conf

Another common directory convention is /var for variable files. Here are files whose content is expected to continually change during normal operation of the system. This is of note in regards to Apache and MySQL since /var is where database (/var/db) or website file hierarchies reside (/var/www).

Executing a Service

Last, but not least is starting these various services. For that there is the service command which runs a standardized script created for controlling the operation of the software in question. Thus to start the httpd web service the command would be"

$ service httpd start
Starting httpd:                                            [  OK  ]

Of course starting a service manually and having it automatically start when the system boots are two different realities. The chkconfig command provides a simple command-line tool for denoting if a service is to start at boot time or not. To turn on the Apache httpd service at boot:

$ chkconfig --add httpd
$ chkconfig httpd on

As noted in its man page, chkconfig has five distinct functions: adding new services for management, removing services from management, listing the current startup information for services, changing the startup information for services, and checking the startup state of a particular service.

Thus if service is akin to rpm form manually controlling a specific service via its control script, than chkconfig is akin to yum for managing a group of services, controlling the when and how of availability.

The --add argument for chkconfig adds a new service for management. Equally, the --del will remove a service from management and the --list will list all of the services which chkconfig knows about or, if a name is specified, information only about the named service.

One of the key concepts in regards to services, such as a web or database service on a Unix-centric system, is the concept of a runlevel. In standard practice, runlevel relates to the state the system is in and what is enabled for execution. Runlevel zero, for example, halts all execution of any running service, an denotes a halted, off, system.

Runlevels 1 to 5 differ in terms of which drives are mounted and which services, such as a web server are started. Default runlevels are typically 3, 4, or 5. Lower run levels (1) are useful for maintenance or emergency repairs, since they usually don't offer any network services and can help in eliminating sources of trouble.

This is important to note since in managing a service, chkconfig needs to know at which runlevels a service should run. Moreover, it is important to note what runlevels other depended services are enabled for. That is, if runlevel 1, which is single-user state akin to a "safe mode" is configured to not run any networking service, it makes little sense to enable the Apache HTTP server to execute at this runlevel.

More Resources

Just as other how-tos are entry points into getting going, this little what's happening is a quick "step beyond" the how to's last step, moving one towards understand what is going on "behind the scenes." Hopefully this next step provides a helpful point of moving into a greater understanding and into the grand world of system administration.

To that end here is a quick list of books on subject of system administration for Unix systems such as Red Hat Enterprise Linux:

2 Remember one of the major tenets at the heart of GNU/Linux is the ability to have access to view and modify the source materials.

3 More about the rpm naming convention can be found here:

4 Often refereed to as RPM Hell

5 A trained eye will note that this command was actually executed on a CentOS system. CentOS, as noted on their site, is a "CentOS is an Enterprise-class Linux Distribution derived from sources freely provided to the public by a prominent North American Enterprise Linux vendor." Can you guess which one?

About the Author

Paul is a technologist and all around nice guy for technology oriented organizations and parties. Besides maintaining this blog and website you can follow Paul's particular pontifications on the Life Universe and Everything on Twitter.


Add to Google Reader or Homepage
Add to My AOL

Add to netvibes
Subscribe in Bloglines
Add to Technorati Favorites

Movable Type Pro