Skip to Content.
Sympa Menu

sm-discuss - Re: [SM-Discuss] Init_Plans Project

sm-discuss AT lists.ibiblio.org

Subject: Public SourceMage Discussion List

List archive

Chronological Thread  
  • From: Jeremy Blosser <jblosser-smgl AT firinn.org>
  • To: sm-discuss <sm-discuss AT lists.ibiblio.org>
  • Subject: Re: [SM-Discuss] Init_Plans Project
  • Date: Wed, 28 Feb 2007 11:47:32 -0600

On Feb 28, "Andra?? 'ruskie' Levstik" [ruskie AT mages.ath.cx] wrote:
> http://wiki.sourcemage.org/Init_Plans
>
> It's based on the discussions that happened on irc. The overall consensus
> is that we should switch to a more mainstream, maintained and stable init
> system. This is a long term plan so don't expect any serious work being done
> on it in the next 6 months.
>
> We do have a green light from our project lead to start researching
> various init systems so that we could in the end make an informed
> decision about which one we would like.

I want to make some clarifications here before people get any wrong idea
about what I think we are "officially" doing. Yes, I definitely think we
need changes in the init area, that's nothing new. What we have is not
maintained and is suffering from bit rot. We're ending up spending a fair
amount of cycles tracking things down and fixing them to keep it on life
support, and we have better things to do. We also get a fair amount of
complaints from new users with admin experience (theoretically a high
target group for us) that we aren't letting them control all aspects of
their system when the one init system we make them deal with is dead, was
never all that widespread, and was relatively new even when it was used.
We aren't keeping our promises with them here, we're giving them a
distro-specific init scheme they have to love or leave. These problems are
where I get the notion of "mainstream, maintained, and stable".

For the *short term* it would probably help if we could at least get off
simpleinit onto some other supported /sbin/init that at least is maintained
and not buggy and can generally support our current init scripts, but that
should be seen as a stopgap measure to just deal with the problem of
simpleinit bitrot so we can spend time on better things. That may be
debatable depending on our actual resource availability vs. the severity of
simpleinit's issues. The current bug is looking a lot less serious the
more we dig into it.

Regardless, I don't think the long-term solution is *just* to do research
on other systems with a goal of finding one to switch to. We need to
change, and part of that is definitely research into other init systems,
but I think we need to look at how we apply our philosophy to init and
general system configuration as well. I think we definitely need to *at
least* provide a "mainstream, maintained, and stable" init system for
people to use, but I don't think that's all we should do. In the end our
goal should be to let the admin do what they want and stay out of their way
beyond automating the routine stuff if they want us to.

There has been talk of basically three approaches to init:

1) One init system; this produces lots of arguing about what the init needs
to do, not surprising considering our philosophy of choice. This is not
who we are and it's not going to get us progress.

2) A metainit system, where we provide some kind of template init script
instead of one targetted at a specific init system, and then have spells
for the different inits we support. Users pick the one they want and
some engine parses the template into the right init script format and
installs it. This has some aspects of an ideal solution but it also
requires a lot of work and may still limit us to only some inits
supported or a limited type of inits supported (not everything fits a
template).

3) No init system beyond spells; let the admins figure it out themselves.
Just have a spell for each init system someone wants to write a spell
for, have them conflict with each other, and make basesystem depend on
INIT-SYSTEM. This is the truest to letting the admin control their
system, and doesn't limit us at all in which ones we provide, but it
also means potentially automating fewer routine things for people than
we do now, and that's controversial. Most of us probably don't want to
write all of our own init scripts, and there's no question that once
someone writes some they will probably want to be able to share them.

These 3 can reasonably seen as a continuum of most distro control to least
distro control, with #2 as an ideal, given unlimited resources on our end.
But we don't have unlimited resources, so I think we should make use of all
3 in getting from where we are now to a more ideal state. Right now we are
on #1. We may need to move to a different form of #1 to solve the
short-term problems with simpleinit. But we shouldn't stay there.

I personally would want us to move to something like #3, because we can get
there somewhat quickly, and because it's frankly where we should have
started from in the first place. We should have always let people pick
their own init poison, and added support for managing the different scripts
later as it was needed and made sense. I don't want to disrupt users but I
would like to see us get to this as our base for init. We can pretty
easily avoid being disruptive to people if we get a decent script sharing
mechanism in place, such as:

a) Having a scripts/ area with each init system that contains all the init
scripts people have written that are compatible with that system, so
when you eg 'cast bsd-init' you'd get 'Install provided init scripts?"
This keeps it with the systems but means people have scripts installed
they don't use.

b) Having the init.d/ dir for each spell contain init scripts for different
systems, as people contribute them. eg init.d/sshd.{simple,sysv,bsd,etc}
This lets them only get the ones they use, but means the advocates of
given init systems have to touch more spells, and spells potentially get
bigger.

Whichever of these we'd use, we'd make it so the migration just ends
someone in the place they'd be if we'd had this all along and they'd chosen
simpleinit and installed the scripts provided. Then if they want to
migrate from there, they can.

If we get there I think we have a solid base that fits our philosophy.
*Then* if people want to look at doing #2 above by creating a new component
or tool that provides a better way to manage the different types of
scripts, I think they have somewhere to work from, and the distro still has
somewhere solid to fall back to if it doesn't work out.

Attachment: pgpCy_TwCAZcP.pgp
Description: PGP signature




Archive powered by MHonArc 2.6.24.

Top of Page