16.4 Tools policies

The tools for the system administrator tasks are unique in some aspects. Thus, you might want to create policies for these tools that are different from the policies you apply to other disciplines.

16.4.1 Tools strategy

In an environment with a large number of images to be managed, disciplines such as data management or availability management are hardly conceivable without tooling. Where many administrators are frequently impacted, you can easily calculate the cost benefits of using tools, and a budget for buying tools is easily justifiable.

Tools for the system administrator are used by fewer people and the tools' impact is sometimes much harder to assess. In days of economic constraints, system administrator tools can easily become the target for cuts. Yet these tools can help to avoid costs (for example, of downtime). If there is no explicit agreement for tools, the unspoken assumption by the system administrator is likely to be that there is no tools budget.

Why would you want to buy tools for these tasks? A purchased tool can to some extent limit the freedom of your administrator. An administrator who develops a tool actively defines its scope and procedure. The decision in favor of purchased tools versus in-house developed tools, therefore, is also a decision on how decisive a role the administrator is to play in establishing and enforcing procedures. Be aware that a vendor-supplied tool limits the degree of change that you can apply to the corresponding procedures in the future, even if it matches your needs at a particular moment in time.

Also, a tool is never for free. If you do not pay for purchasing it, you pay with the time of the administrator who develops it. While developing a tool can help to keep up the administrator's programming skills and Open Source contacts, you might not want to afford the time spent away from tasks more directly related to running your installation.

16.4.2 Corporate standards

To the extent that tools implement procedures, they are an embodiment of policies. For example, installing a particular antivirus program on the workstations of a company's employees implements a security policy.

Within your enterprise, Linux on the mainframe is unlikely to operate in isolation. To prevent your administration of Linux on the mainframe from diverging from the rest of your infrastructure in an uncontrolled manner, it is useful to define the boundaries with suitable policies. An important aspect for choosing your Linux-on-the-mainframe tooling is whether it supports your corporate standards and conventions, in other words, whether it operates within the boundaries of your policies.

You might have a corporate security database, for example, an LDAP (Lightweight Directory Access Protocol) directory, for your entire enterprise. A possible requirement for your tools could be that all security-related aspects of the tool are based on the corporate security database.

Another standard could be a corporate data model, for example, an object-oriented model. Requirements for your tools could be that they use an object-oriented approach and that the objects they work with can be integrated into the corporate data model.

When it comes to the system administrator's tools, you might want to relax your rules. If your Linux administrator suggests a tool for an administration task and the tool is not compatible with your policies, this could mean one of two things: either the administrator does not appreciate the existing policies and the tool is really not suitable in the context of your enterprise, or it is an indication that your policies are too tight or undifferentiated.

This is not to suggest that the Linux administrator should be allowed to violate policies at will. Rather, the Linux administrator should be in a position to negotiate the policies. This is especially true where Linux is used to induce change. The relative isolation of the system administrator tasks is a good environment for experimentation with standards. It is a chance to discover new standards that you can later extend to other segments of your enterprise.

16.4.3 Sources for tools

You are not alone. Even if an administration problem is not frequent enough to have sparked a commercially available tool on the marketplace, similar problems are likely to occur in other locations. There are numerous specialist Web sites where Linux programmers exchange ideas, tools, experience, and advice. A good system administrator uses the entire spectrum of these sites.

http://freshmeat.net/ is a popular site for information on newly available tools. The actual tool projects are available from other sites, for example http://sourceforge.net/ is a major one.

Almost by definition, Open Source tools have Web sites associated with them. Usually, there is at least one site with the tool code and a discussion site with a mailing list.