Skip to Content.
Sympa Menu

sm-discuss - [SM-Discuss] New openings in Developer Organization

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: "Eric Sandall" <eric AT sandall.us>
  • To: "Source Mage - Discuss" <sm-discuss AT lists.ibiblio.org>
  • Subject: [SM-Discuss] New openings in Developer Organization
  • Date: Thu, 24 Apr 2003 20:16:20 -0700 (PDT)

Sad news,

Since I haven't heard for Zoran, Yoav, and Joel (his e-mail doesn't even
work anymore) in a while, I am opening up their sections (cluster,
science, doc and x11) for those whom have some free time. :) I'd prefere
that people apply (by e-mail me and we'll discuss it) that do NOT already
have a section or so that they take care of, but if I get no responses
with that in mind, I'll let anyone take them.

Also, editors and games are still open as well. :)

I'd like it if someone could take over the test grimoire as well.

All you lurkers, ante up! :) If anyone knows anyone whom they think
would be interested, ask them to contact me.

-One of Four
a.k.a. sandalle

--
PGP Key Fingerprint: FCFF 26A1 BE21 08F4 BB91 FAED 1D7B 7D74 A8EF DD61
http://search.keyserver.net:11371/pks/lookup?op=get&search=0xA8EFDD61

Eric Sandall | Source Mage GNU/Linux Developer
eric AT sandall.us | http://www.sourcemage.org/
http://eric.sandall.us/ | SysAdmin @ Inst. Shock Physics @ WSU
http://counter.li.org/ #196285 | http://www.shock.wsu.edu/
>From rycee AT home.se Fri Apr 25 16:25:43 2003
Return-Path: <rycee AT home.se>
Delivered-To: sm-discuss AT lists.ibiblio.org
Received: from kirk (histgr138.sn.umu.se [130.239.131.199])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 7F65A2017F
for <sm-discuss AT lists.ibiblio.org>;
Fri, 25 Apr 2003 16:25:42 -0400 (EDT)
Date: Fri, 25 Apr 2003 22:25:35 +0200
To: sm-discuss AT lists.ibiblio.org
Message-ID: <20030425202535.GA24877@kirk>
Mail-Followup-To: sm-discuss AT lists.ibiblio.org
Mime-Version: 1.0
Content-Type: multipart/mixed; boundary="nFreZHaLTZJo0R7j"
Content-Disposition: inline
User-Agent: Mutt/1.4.1i
From: "Robert Helgesson" <rycee AT home.se>
Subject: [SM-Discuss] Source Mage init system proposal
X-BeenThere: sm-discuss AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Public SourceMage Discussion List <sm-discuss.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/sm-discuss>,
<mailto:sm-discuss-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/sm-discuss>
List-Post: <mailto:sm-discuss AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/sm-discuss>,
<mailto:sm-discuss-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Apr 2003 20:25:43 -0000


--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

Hello,

Attached is a document I've been working on during this week, with great
help from Eric Schabell, regarding a new initialization system for
Source Mage GNU/Linux.

Initially we went for full LSB compliance but after some consideration
chose a system which doesn't completely follow the LSB spec, please read
the document for further information regarding this.

This is a first draft and I hope there will be many helpful comments and
suggestion.

--
/ Robert Helgesson |-- rycee AT home.se --\
\-- ~~~~~~~~~~~~~~~~ --| http://www.rycee.cx/ /

--nFreZHaLTZJo0R7j
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=smgl_init_proposal

Authors: Eric Schabell and Robert Helgesson
Last changed: $LastChangedDate: 2003-04-25 23:17:00 +0200 (Fri, 25 Apr 2003) $
Formatting: vim:set ts=2 et tw=80:


Introduction
============

Since our start over a year ago, we have had two different attempts made to
'patch' our init scripts system. The last attempt was a copy of the RedHat
init
scripts and a half try to adhere to the LSB init script standards.

As of this writing, we have taken it upon ourselves to design, document and
create a valid, easy to use, easy to understand, as close to LSB init script
standards as is sensible and final Source Mage GNU/Linux init scripts system
solution.

When possible we have used other free software components, ideas and knowledge
to make this all possible.


Why not LSB compatible?
=======================

After reading the LSB standards docs on init scripts there are several
conclusions that we have come to. They are rather open ended, trying to
provide
an environment that is both flexible and restricted. Sometimes they go into
excruciating details about things like exit codes and then say nothing about
how
to handle other aspects of the init script system.

We have taken a look at the Linux Boot Scripts concept (see reference links)
and
have come to the conclusion that the script dependency handling described in
that document is more convenient and less complex than the system described in
LSB. This will allow us to keep the Source Mage GNU/Linux init system as
simple
as possible.

Another big plus about using the dependency handling from Linux Boot Scripts
is
that the util-linux package already contain much of the necessary
functionality,
mainly the need, provide and simpleinit programs.

We will try to apply the various LSB init scripts standards when we deem them
to
be functional and applicable. In all other cases we have chosen the route of
simplicity and understandability.

We hope you agree...


Init script names
=================

The script names must primarily follow the LANANA assigned list (see reference
links). If a spell requires a differently named init-script then the name must
be prefixed with "smgl-" and have no ".sh" suffix. An init-script for the
spell
"agt" would for example be named "smgl-agt".


Init script programming
=======================

Many parts in this section falls outside LSB specified behavior, much of it
is
plain incompatible with LSB.


Actions
^^^^^^^

Init-scripts must at the very least support the start and stop actions. The
other actions which are specified in LSB are not required but strongly
recommended.

An action (if supplied) must be defined to function as required in LSB.


Exit codes
^^^^^^^^^^

Exit codes should follow the LSB as far as possible, however the only
absolutely required exit codes are zero on successful start or stop, and non
zero on failure.


Special variables
^^^^^^^^^^^^^^^^^

These are variables that can/must be defined in an init-script. The
variables
must be defined at the top of the script, before smgl_init is sourced.

Variables marked * are mandatory.
Variables marked + are only useful when auto init is used

PROGRAM + (Example PROGRAM=/usr/sbin/atd)
This variable must be set to the _full path_ to the program which is to
be
run by the init script.

If this variable isn't defined or is defined to be an empty string then
the wrapper script assumes the init-script wishes to do all
initialization
manually. The "auto_init"-script is _not_ sourced in this case. The
"smgl-functions"-script is still available however.

ARGS + (Example: ARGS="--daemon")
Defines arguments which should be passed to the program at start.

RUNLEVEL * (Example: RUNLEVEL=3)
Must be set to 'S', 's' or a number between 1 and 6. This character
defines at which runlevel the script should be started.

This variable is not used directly by the scripts it is rather intended
for the script installer so that the script can be placed in the right
directory. Simplest way to get this number is to run the script through
some sort of text processor, such as sed.

ESSENTIAL (Example: ESSENTIAL=yes)
If a script with this variable defined exits with a non zero exit code
then the rest of the init process will be halted. This is used for
scripts
that are absolutely essential for the computer to function normally. The
script for mounting filesystems is an example of an essential script.

If undefined then ESSENTIAL=no is assumed.

NEEDS (Example: NEEDS="cups +syslog")
List of scripts and facilities that must be running before the script
can
start properly. Any item prefixed with a '+' is considered a facility.

In the example the cups daemon and a syslog daemon must be running
before
the script can start.

The need program (from util-linux) should never have to be run directly.

PROVIDES (Example: PROVIDES=syslog)
List of facilities provided by the script.

The provide program (from util-linux) should never be run directly.

SUSPEND (Example: SUSPEND=3)
If, for example, an init-script should be available at runlevel 2 and
above except for runlevel 3 then this must be specified through the
SUSPEND variable.

It must contain one or more numbers from 1 through 5. These numbers
describe in which runlevel the service should be stopped.


Auto init
^^^^^^^^^

This is a system which takes advantage of the similar way many daemons are
started. When enabled it checks which argument was passed to the
init-script, if the argument was one of: start, stop, restart, reload,
force-reload and status then the PROGRAM variable is used to execute the
action.

An example with the at daemon
==== begin atd ====
#!/bin/bash
PROGRAM=atd
RUNLEVEL=3
. /etc/init.d/smgl_init
==== end atd ====

The above code as all that is needed to make atd start, stop, restart and
so
on.

It is possible for an init-script to overload the behavior of the
different
actions by providing a function with the same name as the action being
overloaded.

An example with action overloading
==== begin atd ====
#!/bin/bash
PROGRAM=atd
RUNLEVEL=3
. /etc/init.d/smgl_init
start() {
# insert special handling of the start action here
}
==== end atd ====

Note. Overloading action force-reload is done by the function
force_reload.

The auto init system should provide init-script authors with a simple way
to
produce good init scripts.

It is important to note that it is possible to disable auto init by not
defining the PROGRAM variable or set it to an empty value.


Configuration
^^^^^^^^^^^^^

Configuring the behavior of an init-script is done by sourcing an
appropriately named file from the /etc/sysconfig directory.

The name of the file should be closely related to the name of the script
which is using the file, ideally exactly the same.

The file may, even though it is sourced and executed by bash, only contain
variable definitions of the type "variable_name=variable_content" and
comments. The variable name is recommended to contain only uppercase
letters.


Facilities
==========

Several spells might provide the same functionality, for example both sysklogd
and syslog-ng provide syslog facilities. If the user have both installed and
wish to prefer one over the other then the facilities-file should be used.

This file contains a list of variables which are named after the different
facilities available. If a variable is empty then the first script encountered
which provides that facility is used. If the variable is set to a string
matching one of the script providing a facility, then that script is used when
the facility in question is requested.

For example, if the facilities-file contains a line saying "syslog=" and both
sysklogd and syslog-ng is installed then either one might be started, but not
both.

If the line says "syslog=syslog-ng" then syslog-ng is always prioritized.


Runlevels
=========

As described in LSB.


Installing an init-script
=========================

Installing a particular script is done by looking at the RUNLEVEL variable
which
is defined in it. The script is then copied into
/etc/init.d/runlevel.$RUNLEVEL

A script might potentially be accompanied by a configuration file which should
be placed in /etc/sysconfig.

RUNLEVEL=s and RUNLEVEL=S are both valid and considered identical, care must
be
taken so scripts are placed in /etc/init.d/runlevel.S in both cases.


Making backups
==============

Init-scripts are not required to keep any sort of flag to signify when the
last
update was done.

To determine if two init-script versions differ some outside tool should be
used. The "cmp" program is recommended.

Making a backup of the original is recommended when installing a different
version of a script.

If backups are placed alongside the original script in any of the
/etc/init.d/runlevel.? directories then the backup must contain the suffix
".backup" to prohibit execution of the file.


Files and directories
=====================

This is a list of special files which are introduced in this system.

/etc/init.d/
_No_ init-script should be placed in this directory, only scripts which are
part of the init system.

/etc/init.d/auto_init
Provides the auto init functionality which allows many scripts to be
simplified significantly.

Should never be sourced directly by init-scripts

/etc/init.d/facilities
Describes facilities and allows customization of facility execution.

/etc/init.d/smgl-functions
Provides a number of convenient functions. Basically the same as the
"functions" file in the current system.

Should never be sourced directly by init-scripts

/etc/init.d/rc
Master control script, schedules script execution and generally keeps an eye
on the boot process.

/etc/init.d/smgl_init
This script sets up the environment for an init-script. This is the only
file
a script needs to source to be given the needed functionality.

Variables should be set _before_ sourcing this file.

/etc/init.d/runlevel.[S1-6]/
When installing an init-script it should be placed in the appropriate
directory for the runlevel requested in the RUNLEVEL variable.


Reference links
===============

http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/sysinit.html
http://www.atnf.csiro.au/people/rgooch/linux/boot-scripts/
http://www.winterdrache.de/linux/newboot/README.boot_concept
http://www.lanana.org/lsbreg/init/init.txt


TODO
====

* Clean up smgl-functions ( 0% )
* Write auto_init ( 50% )
* Write smgl_init ( 40% )
* Write rc ( 0% )
* Create a new inittab that works with simpleinit ( 0% )
* Modify util-linux spell to install necessary programs ( 0% )
* Switch from sysvinit to using simpleinit from util-linux. ( 0% )
* Modify existing init-scripts ( 7% )

--nFreZHaLTZJo0R7j--
>From jkolb AT brandeis.edu Sat Apr 26 01:55:34 2003
Return-Path: <jkolb AT brandeis.edu>
Delivered-To: sm-discuss AT lists.ibiblio.org
Received: from clara.unet.brandeis.edu (clara.unet.brandeis.edu
[129.64.99.165])
by happyhouse.metalab.unc.edu (Postfix) with ESMTP id 11F4C20030
for <sm-discuss AT lists.ibiblio.org>;
Sat, 26 Apr 2003 01:55:34 -0400 (EDT)
Received: from sam.unet.brandeis.edu (sam.unet.brandeis.edu [129.64.99.130])
h3Q5tY6P007860
for <sm-discuss AT lists.ibiblio.org>; Sat, 26 Apr 2003 01:55:34 -0400
Received: from localhost (jkolb@localhost)
by sam.unet.brandeis.edu (8.11.6/8.11.6) with ESMTP id h3Q5tXd28240
for <sm-discuss AT lists.ibiblio.org>; Sat, 26 Apr 2003 01:55:33 -0400
X-Authentication-Warning: sam.unet.brandeis.edu: jkolb owned process doing -bs
Date: Sat, 26 Apr 2003 01:55:33 -0400 (EDT)
From: "Jeremy A. Kolb" <jkolb AT brandeis.edu>
X-X-Sender: jkolb AT sam.unet.brandeis.edu
To: sm-discuss AT lists.ibiblio.org
Message-ID: <Pine.LNX.4.44.0304260154260.28229-100000 AT sam.unet.brandeis.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Subject: [SM-Discuss] ncurses messed stuff up
X-BeenThere: sm-discuss AT lists.ibiblio.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Public SourceMage Discussion List <sm-discuss.lists.ibiblio.org>
List-Unsubscribe: <http://lists.ibiblio.org/mailman/listinfo/sm-discuss>,
<mailto:sm-discuss-request AT lists.ibiblio.org?subject=unsubscribe>
List-Archive: <https://lists.ibiblio.org/sympa/arc/sm-discuss>
List-Post: <mailto:sm-discuss AT lists.ibiblio.org>
List-Help: <mailto:sympa AT lists.ibiblio.org?subject=HELP>
List-Subscribe: <http://lists.ibiblio.org/mailman/listinfo/sm-discuss>,
<mailto:sm-discuss-request AT lists.ibiblio.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Apr 2003 05:55:34 -0000

ever since the other day when i updated ncurses it's been giving me really
gross output in alsamixer, sorcery, and giFTcurs. anyone else have this
problem or know how to solve it? recompiling the progs and ncurses doesn't
help.

Jeremy



  • [SM-Discuss] New openings in Developer Organization, Eric Sandall, 04/24/2003

Archive powered by MHonArc 2.6.24.

Top of Page