Introduction

Who needs Sched ?

If you are currently using a program such as ssh or rsh to synchronise your jobs, and you would like a network solution, more flexibility, or central point of view, Sched will most likely provide the additional features you want. However, if you are new to Unix systems or do not have offsetting experience with a shell programming, we do not recommend using Sched as it is much more difficult to setup and use than rsh or ssh.

Sched will help your system administrator to synchronise task (stop, start, backup, etc...) in a network environment without using ssh passwordless account, and will permit you to follow each step with a graphical execution view.

Users can create his job with a gtk program (sched_builder) and can follow his job with a web interface (sched_view). The main goal of sched is to simplify systems jobs. For example :

1. Server 1 Stop Apache on web server
2. Server 2 Stop Postgresql database
3. Server 2 Backup everything
4. Server 2 Start database
5. Server 2 Do some extractions
6. Server 1 Start Apache

Warning

Sched isn't a graphical shell. It's not a simple language interpreter, but it's more a shell script scheduler. Shells must be good Shells. Their return code are used to determine if following actions can be execute.

Components

• sched_slave : Agent which permits to execute command on network environment.
• sched_xfer : Small web server witch permit to display log and to download files.
• sched_job : Interpreter that executes commands read from job file.
• sched_master : Master that controls remote execution and reporting.
• sched_builder : Gtk Interface for editing job.
• sched_view : Web interface web for reporting and configuration.

Figure 1: Architecture

Figure 2: sched_builder

Figure 3: sched_view