At the Forge - Slash
The popularity of Weblogs, also known as blogs, has been growing for several years and shows no signs of letting up. Although many Webloggers continue to record their thoughts using third-party services, such as LiveJournal and Blogger, running a Weblog on your own server is becoming easier to do. Over the last few months, we have looked at several different packages that provide this functionality, including COREBlog, a Zope product, and Blosxom, a set of CGI programs written in Perl.
Last month, we looked at a slightly different type of system for Weblogs when we examined XOOPS. XOOPS, like its cousins PHPNuke and PostNuke, allows users to create content management and on-line communities as well as administer users and groups. XOOPS makes it easy to give each user on a system his or her own personal Weblog.
As popular as XOOPS may be, the undisputed granddaddy of community software is Slash, which powers the popular Slashdot.org and use.perl.org Web sites. Slash primarily is used to disseminate news articles and comments, but it has a powerful Weblog feature that is available to every user on the system. Some would argue that Slashdot itself is a community-authored Weblog, an argument I also find somewhat convincing. Best of all, this Weblog feature is combined into other elements of the site. Thus, when you see a particularly insightful or insipid comment from another user, you immediately can view that user's journal to learn more.
This month, we look at the installation and configuration of a simple Slash site, with built-in support for users and Weblogs, or journals, as they are called in Slash lingo. Next month, we will take a closer look at the Weblog functionality available on Slash, as well as how to configure and change it to suit our particular needs.
The main distribution and discussion site for Slash is Slashcode. As I write this in early April 2004, the most recent posting is titled, “Making Slash Install Friendly”, in which the author asks if there are clear and simple directions for installing Slash. Unfortunately, the answer appears to be no. This is the case for several reasons:
The Slash documentation and instructions point most people to the officially released .tar.gz packages, and these packages are more than two years out of date.
The latest CVS version is freely available and up to date but potentially unstable, unless you know which tagged version to grab.
The installation is a fairly manual process, with room for error at several critical points.
The documentation for Slash is somewhat lacking in quality.
Even if you get a recent, working copy of the code installed, full Slash installation requires installing mod_perl, Template Toolkit, MySQL and a number of other Perl modules and standalone tools, each having its own slightly odd and nonstandard options.
If you are an expert with mod_perl, MySQL and Apache, installing Slash is a slightly annoying but doable process. If you are less than an expert, the results probably are worthwhile, but you should expect to learn quite a bit about each of these technologies along the way. You may find yourself turning to the IRC channel and Web site for support and ideas.
The first step in installing Slash is to install Apache, mod_perl and MySQL. Any modern version of MySQL works fine; the real problems are with Apache and mod_perl, which can be tricky for first-timers to install. Luckily, this part of the installation process has not changed significantly over the years, meaning that you can follow the MySQL, Apache and mod_perl installation instructions at the InstallSlash site (see the on-line Resources section). If neither Perl nor expat are installed on your system, you should follow the InstallSlash instructions for those as well. Remember that on Red Hat and Fedora systems, you need to install not only the expat RPM but the expat-devel RPM too. You also need to define a MySQL database into which site information can be stored; by default, this is called slashdb.
A major source of trouble when compiling Apache and mod_perl is the need to define EVERYTHING=1. This activates all of mod_perl's hooks, allowing mod_perl to override all of Apache's default behavior, including authentication, authorization, URL rewriting and logging. Without defining EVERYTHING=1, mod_perl can generate only content. If your system came with mod_perl installed, it probably was not compiled with EVERYTHING=1 defined, meaning that you need to compile it again by yourself.
The Slash instructions also advise system administrators to set PERL_MARK_WHERE=1 when compiling, although the mod_perl code and documentation indicate this directive removes most undefined value warnings from the error log. I ignored this suggestion and used Slash on my existing mod_perl installation, and I did not notice any ill effects.
Finally, you should install the Bundle::Slash package from CPAN (a worldwide network of servers containing freely available Perl modules and documentation) on your system, using the automatic CPAN tools. Actually, Bundle::Slash does not contain any code; it lists the modules you need in order to run Slash. In this way, it saves you from having to remember (and type in) all of the Slash-related modules that must be installed. You can install these modules while logged in as root by typing:
# perl -MCPAN -e 'install Bundle::Slash'
If you never have used CPAN before, you will be asked to define a number of CPAN-related parameters, including the closest CPAN archive from which you can retrieve modules. This can be a bit tricky the first time, although you probably can accept the defaults without suffering any consequences.
One complicated part about installing these CPAN modules is DBIx::Password, which asks for some site-specific information when it is installed. The InstallSlash directions indicate what you should type in response to the prompts. If you decide to change values for reasons of security or personal taste, be sure to remember what names you used.
The most difficult part of the Bundle::Slash download is the Template Toolkit installation. Template Toolkit is a popular and powerful templating system for mod_perl, and it is used to display the various pages within a Slash site in a consistent and efficient manner.
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!
- Stunnel Security for Oracle
- SourceClear Open
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Google's SwiftShader Released
- Non-Linux FOSS: Caffeine!
- Parsing an RSS News Feed with a Bash Script
- Doing for User Space What We Did for Kernel Space
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