At the Forge - XOOPS
Over the last few months, we've been looking at content management software (CMS) that makes it easy to create Weblogs, personal journals that continue to grow in popularity and influence. There are no hard-and-fast rules as to what constitutes a Weblog (or blog), but most people probably would agree that the contents typically are short articles, with the newest ones displayed first.
But there is a larger, slightly different, class of Weblogs out there as well, which probably can be called Slashdot-style, for lack of a better term. These Weblogs are edited by a small group of people but have a large number of contributors. In many ways, these are closer to on-line forums or bulletin boards than to Weblogs. However, such software also provides Weblog capabilities for its individual members. That is, a visitor to the site can read the main discussion, create his or her own Weblog and read through other users' Weblogs as well.
Although some packages—most notably Slash, which powers Slashdot, use.perl.org and some other high-profile sites—were designed around the idea of public and private Weblogs, other packages have grown to incorporate this idea. One such package is XOOPS, which supposedly stands for Extended Object Oriented Portal System. XOOPS is an outgrowth of the PHPNuke and PostNuke family of portal servers.
This month, we look at XOOPS, paying particular attention at WeBLog (pronounced Wee-Bee-Log), a module designed to facilitate the creation and administration of public and private Weblogs. I have reservations about XOOPS, but it can be an excellent tool for a certain type of audience. In particular, the ease with which it can be installed and administered, and with which each user can be granted his or her own Weblog, is hard to beat.
XOOPS testifies to the power of the GNU General Public License, to the Open Source community and to the fact that not all forks or splits in an open-source project are bad. The XOOPS story begins with PHPNuke, a suite of programs written in PHP and using MySQL for its database back end. PHPNuke apparently was built on top of ThatWare, a now-abandoned Slash clone written in PHP.
What happened next is controversial, to say the least, and demonstrates what can happen when an open-source project gets ugly: a large number of PHPNuke contributors decided to fork the project and named their version PostNuke. Today, PHPNuke and PostNuke both exist, and little love is lost between the user and development communities. From what I can tell, and without examining the code in any depth, PHPNuke mainly continues to be developed by Francisco Burzi, with the main criticisms having to do with his management style, the hobbyist orientation of PHPNuke modules and issues having to do with security. Although PostNuke is quite popular and seems to have the edge on security, administration, commercial-oriented modules and database-independence, maintainers are accused of changing APIs too frequently and of designing PostNuke to be too resource-intensive. Meanwhile, some of the central PostNuke developers have left that project, forking it into software that originally was known as LostNuke and now goes by the name of Xaraya.
Finally, XOOPS seems (from what I can tell) to be an object-oriented rewrite of PHPNuke. The XOOPS maintainers believe that by rewriting the system to use objects, it is more secure and easier to develop and maintain.
The good news is that all of these systems are available under the GNU General Public License. That said, forks generally are seen as a last resort in the Open Source community—and the fact that so many have happened on this software probably testifies to the lack of strong management and leadership of these projects. Reviewing the history of these projects renewed my admiration for people like Linus Torvalds, Larry Wall and Guido von Rossum, all of whom have managed to keep their communities together, despite differences of opinion among the core developers.
XOOPS seems to have a smaller community than either PHPNuke or PostNuke. However, the number of built-in and third-party modules is quite large, and its object-oriented facilities mean it is fairly easy to build your own module. Indeed, although the number of modules has remained fairly modest, I was impressed by how easy it was to install. Does this mean you should use XOOPS over another one of the Nuke-alikes? That seems to depend as much on politics and your planned use as on the technology itself, although the fact that XOOPS uses objects does give it an edge, at least in theory, from my experience.
Now that we have reviewed the historical evolution of XOOPS and related pieces of software, let's set up our own XOOPS server. In order to run XOOPS, you need a MySQL server—I am running the admittedly old version of 3.23.58 on my workstation—and a copy of Apache (version 1 or 2) with PHP installed.
Installing XOOPS is one of the most impressive and painless software installs I have done in a long time. I downloaded the code from the XOOPS Web site (see the on-line Resources section) and opened up the .tar.gz file in a temporary directory. I then copied the entire HTML subdirectory into my Apache content root, as /usr/local/apache/html/xoops. Once I had done that, I was able to access the XOOPS installer at the URL /xoops on my system.
The installer is fully Web-based and walks you through the process slowly but surely. The most confusing part probably was the page on which you need to enter the user name and password of a MySQL user who is authorized to create a new database and tables. The installer also could be a bit more verbose in its error messages at this initial phase, given that many people installing XOOPS are unlikely to be experienced Web/database programmers.
That said, the installation was fairly simple and painless. I returned to the /xoops URL on my system and was greeted with a simple introductory screen that invited me to log in. I logged in as the site administrator, and although the main screen was relatively blank, I was able to move quickly to the Administration menu on the left side of the screen (Figure 1).
Administering XOOPS is fairly straightforward, once you understand that everything in XOOPS is a module. The first order of business for most XOOPS administrators then is to install additional modules. Go to the Administration menu and choose Modules. The top of the screen lists the modules already installed, and the bottom of the screen lists those available but uninistalled.
To install an available module, click on the appropriate icon next to the module's name. After you confirm your choice, you should see an indication of which tables are being created in the MySQL database, what access permissions have been added to the system and whether the module was installed correctly. Assuming that it was, you can return to the Module Administration page, where you should see the newly installed module at the top of the screen rather than at the bottom.
The default layout of a XOOPS site is rather empty. To include additional items on the home page, you must go to the Blocks administrative page, which lists the content features each module includes. The News module includes three blocks—bigstory, topics and top. The main Blocks Administration menu lets the site manager indicate which blocks are visible. But the real power happens in the Edit menu associated with each block, allowing you to indicate where on the screen the block should appear—on the side, in the center or somewhere else entirely.
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
- SourceClear Open
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