Linux in the Real World
SSC's Web server is an AMD 486DX4/100 machine running Linux and the Apache server software. The server contains SSC's catalog and product information, as well as information on Linux Journal, including covers and tables of contents from all issues, selected articles from some issues, and advertiser indices. We also offer space for sale to Linux Journal and WEBsmith advertisers if they need a home for their Web pages.
One of the big advantages of Apache is that it can appear to be different servers with different domain names and IP addresses—that is, it is “multi-homed”. This makes it possible for our single computer running one Web server to serve as the Web server for Zebu Systems, L.L.C. (http://www.zebu.com/) and Cucumber Information Systems (http://www.cucumber.com/) as well.
The server has been in operation since May and accesses continue to increase. We are currently receiving around 35,000 hits per day. Apache is very efficient and reliable. Even with only 16MB of RAM on the machine, we seldom see a load average of over 0.2. This means there is an average of one process waiting to run 20% of the time, and the rest of the time the machine is idle.
Keeping the Web server outside of the Orion Firewall System keeps the internal network safe in the event the Web server is compromised. The Web server is mirrored from the internal network so that if it is compromised, it can be restored easily.
Most of the printing we do at SSC is done using PostScript:
PostScript is a Page Description Language (PDL) developed by Adobe Systems, Inc. PostScript tells any printer which has PostScript built in, how to print a page that consists of text and/or graphics. The page must be generated by software that includes a driver which converts the page into PostScript code; the code, in turn, is translated by the printer. PostScript is the de facto PDL standard for high-end desktop publishing because, among other reasons, it can operate across a range of platforms, is very precise, and has color capabilities. Holt and Morgan—UNIX: An Open Systems Dictionary.
Text files, such as invoices, that we need to print out are done in ASCII. They are sent to one of the dot matrix printers, or the one laser printer reserved for printing plain text.
We have seven printers on the network, shared via lpd. Users can select their default printer by setting their PRINTER environment variable.
Many of the printers are selected based on their location relative to the person using them. Others may be selected because of their speed. One special printer, a Tektronix Phaser III PXi is a wax-transfer color PostScript printer. This is used for producing color proofs of SSC products, magazine covers and pages, and other graphics such as Web pages.
The database we use, Progress, isn't available for Linux. Therefore, the database is run on a Unix System V, release 4.2 system. Progress is run in character mode, and users access the database via rlogin or telnet from their Linux workstations.
This database is used to store all customer and vendor-related information. This includes customer contacts, subscription information, sales transactions, reader service leads, the Linux consultants directory and a whole lot more. We are in the process of moving advertising booking to this database as well. Other small databases (article tracking, for example) are written in Perl and run on Linux systems.
We have used Progress for years. (We used to run the whole office on a Xenix system.) If we had it to do all over again, we would select a database methodology that would make it possible to run everything on Linux and not have a foreign Unix system in the network. While it is not a reliability problem, it does mean we have to support another operating system.
When I tell people I work for a publishing company, many ask, “Are you using a Macintosh for your layout?” The answer is “no”. We use Quark Express and Corel Draw! on Windows for Workgroups and tie the process directly into our Linux network. In order to explain this, let's examine the magazine production process from start to finish.
First, Michael K. Johnson, the editor, finds people to write articles for Linux Journal on various topics. Note that Michael is located in North Carolina, while the remainder of SSC's staff is located in Seattle. This means that Michael uses his local Linux systems to do much of his work and uses his Internet connection to access machines in Seattle. When the articles are sent in (via e-mail), Michael edits them and sends them to our production editor in Seattle. At this point the articles that he sends are in Quark Tag Format—ASCII text with various escape sequences added to them to indicate paragraph types, font changes, and other formatting. We are currently developing a new language closely related to HTML (HyperText Markup Language), the language of the World Wide Web. Once this language is complete, we will be able to automatically translate articles into Quark Tag Format for layout and into HTML for addition to our Web site.
The production editor files the articles, runs some basic checks [like spelling; yours truly can't be trusted to spell anything right—ED] and prints them out in preparation for our copy editors. The print process is done using a shell script that uses sed and awk to translate the Quark tagged file into troff source and pipes the result through groff to produce a reasonable approximation of what the article will look like when it is imported into Quark and printed.
Articles returned from copy editors are then reviewed by the production editor and changes are made as needed. This step sometimes involves contacting the author for clarification—a step that is generally carried out via e-mail.
The final version of the articles are slightly modified by another shell script which like the first, uses sed and awk to do its work. This is necessary because Quark requires that paragraphs be one continuous line. Also there are some particularly awful Quark escape sequences that we have aliased to simpler escape sequences which need to be converted to the real sequences in order to be interpreted correctly by Quark. These modified files are written to a location on the Linux filesystem that can be accessed directly by the WfW system.
Our layout is done using Quark Express on our WfW system. Once the ads are placed, the articles are put in. The result of the first layout process is a semi-complete magazine. A copy is printed locally on the Tektronix printer for review, and a PostScript image is written to a Linux filesystem so Michael can download it and print it in North Carolina. The locally-printed copy is printed from the WfW machine on a Linux-connected printer; this is much faster than directly connecting the printer to the WfW system, as was originally done.
The production editor merges the changes from Michael and the other reviewers and sends them back to layout for final changes. If the changes are extensive, the article may be re-edited as text using vi or emacs on a Linux system and re-submitted to layout.
After the second layout step, a paper copy of the magazine is printed for review by our proofreader. Changes from this cycle are made, and the layout system outputs a PostScript image of the magazine (in 2 to 8-page chunks) to a Linux filesystem connected to the imagesetter.
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!
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Non-Linux FOSS: Caffeine!
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Google's SwiftShader Released
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