COAS: A Flexible Approach to System Administration Tools
COAS stands for Caldera Open Administration System. It will be incorporated as the main configuration tool in future versions of the OpenLinux distribution.
For those who have never used OpenLinux, the tool we have been using for quite a while is called LISA (Linux Installation and System Administration), which is basically one huge shell script using a modified version of the dialog tool to interact with the user. When we felt it was time to move on to something new, we of course looked at what was already available. The only viable option at that time seemed to be LinuxConf, which had quite a ways to go before it would become useful. Since that time it has become much better, but because we had already started work on COAS, we decided to stick with it. Of course, we believe our concept is better.
The source code to COAS is released under the GNU General Public License. We feel our work might be useful to the Linux community as a whole and we want to invite interested programmers, administrators and users to participate in its development by offering comments contributing patches or even modules.
The main idea behind COAS is not to provide just another administration tool, but an entire framework for writing one. From the start, we wanted it to be a modular application where assumptions about such things as system data representation, file locations and dependencies are separated as much as possible from user dialogs and vice versa. Ambitious as this goal may appear, our main interest was the ability to easily adapt the tool to changes in the underlying platform and in porting it to other Linux platforms.
I like to call this vertical modularity, because it breaks up the task of system administration into three layers. At the lowest level are native system data files, such as /etc/passwd, /etc/hosts or files that define the IP address for a particular network interface.
On top of that, COAS implements an internal representation as a kind of database. If this term made you jump in your seat and shout, “Oh no, Mr. Bill, not a Linux Registry!”, please be assured that this is definitely not what we want it to be. COAS is supposed to be vi-administrator friendly. We want users to be able to switch between COAS and vi (or Emacs) administration, because even though we hope COAS will be useful for everyday tasks, it cannot cover each and every feature of a system component. (Consider the configuration monster incarnate, sendmail--you can spend as much time writing configuration software for it as Eric Allman keeps churning out new features.)
The native system files will remain the primary source of information. The COAS data model is strictly a run-time representation of system data that attempts to hide the on-disk representation from the upper layers. For instance, an administration module for the BIND server should not have to bother about where DNS zone files are located and how they are to be parsed; all it needs is the list of DNS zones this server is a primary or secondary name server for and the records they contain.
Having an abstract data representation also allows for alternate data access mechanisms. For example, our database engine can store a change log of an administration session to a file, which could then be distributed to other machines, thus allowing for bulk updates. Also, there's the vague idea that COAS might one day support remote access via LDAP or SNMP.
The top-most layer is the user interaction code. This code drives the dialog with the user and controls what information is displayed to the user at what time. It uses a standard set of dialogs, provides on-line help, etc. We decided to use a scripting language, Python, at this layer in order to allow for rapid prototyping. In addition to this, wrapping all lower-level functionality in Python classes and functions provides an additional level of insulation that restricts the number of tricks a programmer can pull. This may seem like a disadvantage to the hackers among you, but it is truly a big plus when it comes to code maintenance.
You may have guessed from my choice of the term “vertical modularity” that there is also a horizontal one, and so there is. Consider the following scenario: a security problem or other misfeature requires you to update a component of your system, such as the BIND name server. Alas, the update is from version 4.9 to version 8.2, which uses an entirely different configuration file format. We could now ask you to install an all-new version of our administration tool in order to accommodate the new configuration file format. On one hand, that is costly in terms of bandwidth. On the other hand, making sure the tool operates properly with all possible combinations of updates applied or not applied would be rather time-consuming for us. The ideal solution would be to package the DNS server administration module alongside our BIND update.
We are attempting to accomplish the following: COAS lets you rip out an entire module, including the data model definition, Python code, message catalogs and so on, and replace it with a different version. We have nicknamed these CLAMs, which is short for Caldera Linux Administration Module (we invented the acronym first and then decided on its meaning, in case you were wondering).
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!
- Paranoid Penguin - Building a Secure Squid Web Proxy, Part IV
- SUSE LLC's SUSE Manager
- Google's SwiftShader Released
- Managing Linux Using Puppet
- My +1 Sword of Productivity
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- SourceClear Open
- SuperTuxKart 0.9.2 Released
- Parsing an RSS News Feed with a Bash Script
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