Scire - Systems Configuration, Installation, and Replication Environment

1.  Application Overview

Objectives

Scire will serve as a common portal for administrative tasks for multiple Linux client machines. Common tasks will include updating software, installing software, customizing configuration files, and running scripts.

Scire will keep track of client machines and let privileged users assign tasks to individual clients or groups of clients.

The goal of Scire is to make administration of massive networks of Linux machines easy on administrators. It will be extremely modular so as to allow users to create modules that extend it's functionality.

In its simplest form, Scire is just a database of information about client machines along with modules designed to use that information to manage the clients.

Process

When possible Scire will use existing technologies in order to make the development as easy and pain-free as possible. This will likely include Apache, PHP, a SQL-compatible databse, and a SecureXMLRPC server and client that utilizes SSL certifications. Other technologies planned for use are PHP-GACL, ADOdb, and Smarty.

User Management Subsystem

Communication with clients will be permitted only to privileged users or user groups. For example: Samir is in the Technology group, and the Technology group is granted the Update privilege on the PrinterServers group, so Samir can schedule a "update world" job on Printer1 and Printer2 (which are in the PrinterServers group), but not on ImageServer1.

• 'root' user: The root Scire user will have the ability to control all machines and users in the network, including assigning them to client groups and user groups, respectively. The root user is the only user that can add users to the Administrators group. The 'Administrators' group has the ability to assign users to user groups, and grant privileges to them. Administrators will (though not recommended) have the ability to assign itself to every user group, it will be able to assign tasks to any client as well as granting/revoking privileges, adding/deleting clients, client groups, users, and user groups.
• Other users: Users will be given roles that will define what tasks they can assign to which clients. Thus, many maintenance tasks may be accomplished by people other than the 'root' user, saving the system administrator time.
• Users are defined by a userid # in the database for quick access, and are also unique by username (though this is changeable in case it is necessary). Users can only create jobs on clients that they have permissions on. These permissions define not only the user and the client, but also the script that the job executes. Thus, the scripts define the abilities of the permission and also the abilities of users on clients. Once a user creates a job on a client or group of clients, only users with the same permission on those clients can edit the job.
• Only users in the Administrators group will be able to view the permissions and user information of other users. All other users will only be able to see their own permissions. This limits the information that non-administrators can see about other users, an anti-phishing precaution.

Interaction with other systems

Scire will have two methods of communicating with clients to send jobs for the client to do. The common way will be to use a client program installed (likely in the crontab) on each client machine. This program will fetch any waiting jobs from the Scire server into a local queue to run. If this client program is not run, the client operates independently as if Scire didn't exist, and if configured to do so, Scire will present an alert to certain users or user groups stating that the client missed a communication interval. This method is preferred since it is a pull mechanism with built-in authentication checks and is more secure because it does not leave an open port.

Alternatively, a Scire client program can be run in daemon mode, where it then opens a port/socekt and both sends requests for work and waits for commands from the Scire server. This allows for immediate actions to be executed from the Scire server.

When requests are fetched either way, they are put into the client's local queue. The queue is ordered by priority and then by time (oldest jobs first). An example line for running the client might be: :$ scire_client --daemon --poll_interval 5m

When run, the client will be able to execute scripts and run jobs as the root user of that client, though this is not preferred. The access granted to the machine will be determined by the permissions the job has been assigned. The interval that the client program will be run should be configurable and be related to the number of clients, the required expediency of updates, and the hardware/network abilities of the Scire server.

In the hopes of creating a secure system, there will be at least two levels of authentication for clients before they will trust a job well enough to execute it. The client will authenticate that the host it is asking for work is indeed the Scire server, using a host key. If the key doesn't match the key on record on the Scire server, the client will not connect. In order to create a job, the user will need to login to the Scire server, and be granted the appropriate rights by the Administrators. This provides the second level of security.

Replacement of Legacy Systems

Scire will duplicate much of the functionality currently existing in other system management programs such as Red Hat Satellite, m23, and SystemInstaller to name a few, and will seek to improve on that functionality, while adding new functionality not yet found in other systems.

Terminology

2.  Functional Requirements

Statement of Functionality

Physically, Scire requires a server or servers to run the main database and web interface. The number of client machines will be arbitrary but Scire will be designed to scale. Setting up the clients will normally require the use of a module to configure the client machine to use the Scire client program. It will be possible, however, to install the Scire client program on any Linux computer and then set up that client's settings using the Scire web interface.

Because the developers are Gentoo users, the Gentoo Linux Installation Management Daemon will be a module designed to work cooperatively with Scire by optionally installing and configuring the Scire client program, and then providing Scire with the appropriate client information to set up the client (i.e. network settings, package versions, etc).

• Security
• Auditing
• Administration/Customization of the Application
• Reporting
• Scope
• Performance
• Usability
• Concurrency

3.  Component Descriptions

Scire User Management

The user management system will utilize a basic set of ACLs to control which users have access to which clients and what access that is. Access is defined as a set of "permissions" on a client. The core of this system will be php-GACL, with a simplified front-end made to suit Scire's needs. There will be a python implementation of the ACL checks for backend use. Before any job is sent to a client it must be checked first to ensure the user still has the permission to run the job on that client.

The Administrator group will have the ability to create users and UserGroups. Users may belong to multiple UserGroups. Clients will work similarly to Users, but it is not recommended to have a client belong to more than one ClientGroup. In the "Assign Permissions" screen, the Administrator will choose a user or UserGroup and then choose from a set of Permissions and then assign them to a Client, multiple Clients, or a ClientGroup.

Since the creator of a job as well as the Permission required for the job is stored in the database, a simple check of the ACL (i.e. "Does user X have permission Y on client Z") will yield a yes/no. php-GACL takes care of all potential conflicts. In doubt, individual ACLs override group ACLs.

Job scheduling and queuing system

When a user assigns a client a job, it will go into the queuing system to be fetched by the client program. Alternatively, users will be able to schedule jobs to be executed in the future, optionally recurring. Jobs will be stored in the database on the Scire server (web server side, database can be separate).

When the client machine requests work, it will fetch all jobs past the current time (will not fetch future jobs), and put them into a local queue. A directory structure such as /$LOCAL/Jobs/queue/priority@timestamp@job_id where $LOCAL is the root of the directory structure, priority is 1-9, 1 being highest priority, timestamp is a unix epoch, and job_id is the database job id # (for status values).

Once done fetching the client program will look at the queue and move the first file to $LOCAL/Jobs/running/. If client is unable to run the job or doesn't receive correctly, it will return a code that the server daemon will receive, and also move the job to $LOCAL/Jobs/failed/, otherwise if it succeeds it will move to $LOCAL/Jobs/done/. Since the client is calling the server, the server will automatically fork a thread per client connection. Since there is almost no overhead besides bandwidth in transferring the jobs, the load is not expected to be able to bring down the server. If stability becomes a problem, the max_threads/connections will be made to be customizable.

Scire Client Program

Communication protocols/methods between client and server

Client setup and configuration

4.  Appendices

The contents of this document are licensed under the Creative Commons - Attribution / Share Alike license.