The Helix Setup ToolsCopyright © 2000 by Helix Code, Inc The Helix Setup Tools is a set of tools aimed at making system administration of desktop Unix systems simple. Currently configuring a Unix system requires a lot of Unix knowledge, the Helix Setup Tools lower the barrier to setting up Unix systems, and address this in a consistent way across Unix systems 1. Features of the Helix Setup Tools
2. HistoryThe GNOME project wants to provide a complete suite of applications, tools, components and libraries to allow free Unix systems to compete on the desktop space with systems like Windows and the MacOS. When the GNOME project started, we decided that we would not tackle the problem of writing system administration tools, as we expected the Unix vendor to know more about their system and expected them to provide the right set of tools for configuring and setting up their system. So GNOME would provide the same desktop experience across operating systems and we would expect the vendor tools to be integrated into GNOME in some way or another. As time passed a number of problems with the above approach arised, and they were not helping the GNOME project achieve its goal:
3. Helix Code's Setup ToolsAs part of Helix Code's strategy to improve the GNOME desktop we wanted to address the problem above, to drive GNOME into a position where it can be successfully used by non-Unix experts. While we decided to start work on the Helix Setup Tools, we came up with a design that would satisfiy the needs of end users, and at the same time would be a good tool for seasoned system administrators to use. Some of the constrains set on the Helix Setup Tools are:
Given that the state of the system can be at any point can be snapshotted and turned into an XML description of the system, a number of possibilities are open by layering new tools on top of the core infrastructure, we will get back to this later. 4. The Helix Setup Tools structure.Helix Setup Tools is a component-based architecture. New components can be added to the system when new features are added to the system. At the time of this writing the Helix Setup Tools have the following modules: file system, memory management, name resolution, network configuration, exported shares management, time and date and user management. Each Setup Tool consists of two parts: a GNOME-based front-end, and a back-end. The backend is typically written in Perl, or C. Each backend program has a number of well defined parts.
That looks more complex than it actually is. The bottom line is that every Setup Tool can be invoked with the --get flag and you would get an XML-based snapshot of the system for the domain that the Setup Tool administers. Or you can feed a new system configuration by passing the --set argument to a Setup Tool. For example: Example 1. Sample output of a backend setup tool bash$ nameresolution-conf --get
<?xml version='1.0' encoding='ISO-8859-1' standalone='yes'?>
<!DOCTYPE nameresolution []>
<nameresolution>
<!-- Configuration starts here -->
<hostname>erandi.helixcode.com</hostname>
<workgroup>MYGROUP</workgroup>
<description>Samba Server</description>
<searchdomain>helixcode.com</searchdomain>
<nameserver>140.239.238.2</nameserver>
<nameserver>132.248.10.2</nameserver>
<statichost>
<ip>127.0.0.1</ip>
<alias>erandi.helixcode.com</alias>
<alias>erandi</alias>
<alias>localhost.localdomain</alias>
<alias>localhost</alias>
</statichost>
<!-- You shouldn't have to modify anything below this line -->
<order><hosts/><bind/></order>
<hostmatch return='all'/>
<!-- You cannot modify anything below this line -->
<!-- End of configuration -->
</nameresolution>
bash$
The backend and the front-end communicate by exchanging these XML-based representations. The front-end would provide the best user interface possible to edit the above configuration, and then when the user is ready to accept the changes, invoke the backend with a new XML representation and pass the --set argument to it. The front-end does not need to know anything about the underlying OS, unless a feature would be present or hidden, but besides these things, the front-end is a generic tool: it does not matter what is running on the backend. 5. The root-manager.The root-manager is a program that will authenticate a regular user to have administration privileges and run applications on his behalf as root. The setup tools are integrated with the GNOME control center, and blend with the rest of the configuration tools for the user's desktop. The first time the user tries to launch an application that requires root privileges, the root manager will be invoked, and will stay around to launch any other Setup Tools that the user activates without asking for the root password a second time. 6. The upper layersThe fact that the Helix Setup Tools can create snapshots of the system at any point, and can change the system to match an XML-based definition of the system is the foundation for two extra features: Location management and time travel. Neither of them have been finalized. They are both works in progress, an we hope to release these tools integrated with the rest of the GNOME desktop in the near future. Snapshots of these are available on demand (FIXME: we should put these tarballs in ftp.gnome.org and ftp.helixcode.com). 7. Location managementLocation management is an application of the Helix Setup Tools that is of most interest to Laptop users. For example, here is a typical setup, the one I am faced with:
We will either present the user with a panel applet or integrate into the panel a button that allows users to switch their location configuration by just selecting it from a list. The location manager should allow the user to choose which settings change and which settings do not change. The location manager allows the user to choose which settings vary between the locations. When creating a new location profile, the user specifies a source location from which to derive its settings. Settings on the new location then override settings on the parent location. Information will store the differences between two configuration through a system like XPath (only the flat nodes are recorded for simplicity now, for non flat nodes. The system will just consider its parent to be the last root node that can be handled.) 8. Time Travel and Undo.Each time a change is made to the system configuration, a filter sits between the front-end and the back-end and archives all the changes. Consider the case where an end user has a working system configuration. One day the power user niece comes home, plays with the computer, and figures he can `improve' the setup in the machine. By the time the niece is gone, the machine is no longer working, and your mum is lost. She has no idea what happened, but the machine has stopped working. Time travel allows the user to restore the configuration to the state it was on a given date. The archiving system can be asked to retrieve the configuration that was in effect at any time in the past since the installation of the Helix Setup Tools and restore that configuration. The Undo system is layered on top of this, given that the system had entire snapshots of the changes that were done to the system, it can move back and forth between the various changes made on the system. 9. ClusteringWe are looking at clustering from the point of view of managing a set of computers: performing the same kind of configuration and tuning that would be done in a machine-per-machine basis. Consider the case where a network administrator is managing a computer lab with several dozen workstations and needs a configuration change made to each one. The Helix Setup Tools will allow you to create groups of computers and allow you to apply changes to sets of computers or sets of sets. For example: changing the DNS server for all computers in the company; Or changing the print server for the engineering department; Or changing the NFS server for both marketing and engineering; Or changing the network configuration for the entire company to use DHCP. Clustering support is an ongoing development at Helix. The current plan is to allow the user to define a "login" method in a per-computer, or in a per-group basis. Currently the plan is to use an OpenSSH-based login system. Then the central manager would be able to fetch the information for all the cluster, allow the administrator to make changes, and have those changes be applied to all the machines on the network. This is done regardless of the kind of operating system being run, remember that the Helix Setup Tools do not care about the underlying operating system. 10. Implementation details.
11. The current componentsFIXME: list the features in each one of these. memory: networking: time: disks: nameresolution: shares: users: 12. The components planned:Mail configuration. Web server configuration. Printer configuration/Printer spooler. 13. CORBA system services.The following text was taken from my `How to fix Unix' paper: 13.1. BackgroundConfiguring a Unix system traditionally has involved editing a system file, typically on /etc and saving the file. Then either the various programs and processes on the system pick up the changes, or you have to notify the daemons that require to be informed of this change. This is not really an ideal situation, because those files are easily corrupted by human error. And depending on the tool, you need a different way of editing the file. For example, consider /etc/passwd, to edit this file you need to use the vipw command, which will do some basic checking on the integrity of the file before you save it (as well as locking), but there are no equivalent commands to "lock", edit, and verify other system files. So depending on each tool, a user/administrator needs to:
For the system logs case, examine /etc/syslog.conf to locate the place where error messages are logged. Then make sure you tail -f the file, restart the service, scan for errors. Hopefully you do not have a busy web server, or the error is going to be lost in the noise (or hopefully you edited /etc/syslog.conf, restarted syslog) 13.2. What we want to doAlthough the above `Background' description was aimed towards moving applications into providing CORBA interfaces to their functionality, and making new applications have a CORBA-based control facility, this does not solve the problem of fixing the current Unix. Although existing tools could be modified, a stop gap measure would be to reuse the Helix Setup Tools. Given that the Helix Setup Tools have already gone trough a great length to isolate the differences across Unix systems, and given that they can analize and modify existing system settings, we think that the backends are perfect for encapsulating the configuration issues of a Unix system. Each one of the Setup Tool backends will also be installed as a system service (only while running as root) that would be activated on demand to expose the system management functions trough CORBA interfaces. So the objective here is to add a few changes to the existing backends (this will be done by Helix CORBA::Perl team) to expose the CORBA interfaces for querying and making changes to the system, using the functions that are already defined in the code. A programmer could write code like this in Perl: Example 2. Sample Perl usage of the Helix Setup Tools CORBA interface use Bonobo::bonobo;
$interfaces = BONOBO::bonobo::resolveReference ("contexts");
$name_resolution = $interfaces.getObject ("sysconf:NameResolution");
print "Hostname is: ", $name_resolution->getHostname (), "\n";
print "Changing hostname to JollyJumper\n";
$name_resolution->setHostname ("JollyJumper");
A programmer could write a file manager for Unix that can `export' shares easily in a completely compliant fashion. This example uses C: Example 3. Sample C usage of the Helix Setup Tools CORBA interface void export_mount_point (char *mount_point)
{
CORBA_Object share_manager;
share_manager = bonobo_get_object ("sysconf:ShareManager");
Helix_ShareManager_export (share_manager, mount_point, "smb",
&Sure
ev);
}
14. The FutureIt is possible to write other front-ends to the Helix Setup Tools. A web-based front-end is possible, as well as a text-based front end. We would like to see those happen at some point. Helix Code has also been working on Red Carpet, a cross-platform package management tool, and update tool that will bring the same uniformity to all systems. Red Carpet works currently on RPM-based systems and Debian-based systems. We will be extending it to support the Solaris, IRIX and HP-UX native package formats as well in the future. Package management is essential to maintain a system up to date, and to allow people to easily install software. Red Carpet and the Helix Setup Tools will also be integrated to deliver a complete, perfectly blended set of services. The tricky part is using Red Carpet for doing cluster management. 15. The HackersThe Helix Setup Tools were implmented by Hans Peter Jansson, Arturo Espinosa, Bradford Hovinen and Tambet Ingo. I am their project manager. |