Scire - Systems Configuration, Installation, and Replication Environment
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
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
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.
||The user with all access, main administrator.
||Someone else using Scire.
A group of users that job assigning and client access privileges may be
granted to, or revoked from.
|client machine || client
||The machines that Scire manages.
A group of client machines that privileges may be granted to, or revoked
from users or user groups.
Program that runs on a client machine and allows it to communicate
with the Scire server and gather and execute jobs.
A defined set of information describing an action to be performed on a
client which may include permissions information describing the context in
which it should be executed on the client.
||Protocol for job communication.
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).
Note: The following topics need to be expanded on:
- Administration/Customization of the Application
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
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.
For more detail and a very good set of examples see the php-GACL documentation
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
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 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
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
Scire Client Program
Note: This section is incomplete.
Communication protocols/methods between client and server
Note: This section is incomplete.
Client setup and configuration
Note: This section is incomplete.
The contents of this document, unless otherwise expressly stated, are licensed under the CC-BY-SA-2.5 license. The Gentoo Name and Logo Usage Guidelines apply.