Questions from my local LUG ML

[Scott James Remnant]

On Sat, 2007-01-06 at 17:32 -0600, Conrad Knauer wrote:

> - "Has anyone [outside of Ubuntu] taken a good, close look at upstart
> to see if there's any design problems there?" (and a corollary; are
> any other distros planning on adopting upstart?)
> 
I've no idea, since the initial announcement of its existence, upstart
has certainly had a lot of interest from outside of Ubuntu -- those
people have been helping out with its design, which has changed a fair
bit since the original discussion.

That's one thing to note, upstart was "released early" so it's still in
development; and we're certainly not afraid of changing things at this
point if things don't turn out right.

The 0.3 release in development at the moment is an attempt to fix many
of the problems we found during edgy, and while planning replacement of
the ordinary boot scripts.

> - In trying to replace "cron, atd, anacron and inetd" in addition to
> init, does "Upstart [run] contrary to the basic philosophy of Unix
> [...] Make each program do one thing well"? I quoted the Rationale
> section from https://wiki.ubuntu.com/ReplacementInitDiscussion but
> they didn't seem to agree that those "perform the same kind of job";
> one person said "Adding cron/at or inetd to the mix just doesn't make
> any sense." and another elaborated:
> 
One thing I do detest, and I'm guilty of doing this in the past my self,
is where a program attempts to expand to have every single feature of
any possible competitor in its field.

I strongly believe that programs turn out much better if they just focus
on doing one thing, and ignore anything that falls outside of that.

That being said, it's also foolish to artificially limit the features
one is planning simply because it may mean your program is doing two
things.


So what is the "one thing" that upstart is trying to do well?

 * Managing the services and tasks running on the system.


It provides the ability for a sysadmin to start, stop and query the
status of these jobs; as well as providing various methods of
automatically starting and the jobs.

Since init has to do this to bring up the system, it was natural to
replace init with something that could do all of this.


So why should we replace cron/atd/anacron as well?  Well, these are
daemons that largely do the above.  They have to duplicate all of the
code to switch users, begin a session, set up an environment, record the
output of the jobs, supervise the job and clean it up when done.

An argument is often fronted that cron e-mails the output, whereas init
just dumps it on the console ... which is odd, why shouldn't the
webmaster receive a copy of the output of apache in their e-mail, even
though it was started at boot time?

And if you can start a service when the network device comes up, and
stop the service when it goes down -- why can't you start a service at
8am and have it stop at 5pm?


So that's why cron, atd and anacron are on the hit list.

They don't make it any more complicated.  Upstart already has all of the
code, include timers as it needs to track timeouts.  The only extra
complexity is something to parse time syntax in the job definition file.

> -  Is upstart's design itself a potential security risk?  As one person put it:
> 
> "The idea of any monolithic program listening on a few dozen network
> ports is scary, as is any program responsible for managing many task
> along with extra stuff. [...] one tool running with privileges
> managing all that stuff is silly.  The day Window became insecure was
> the day MS started pushing all the userland tools into system space.
> BIND has been rewritten several times and still hasn't eliminated all
> the security problems associated with it's monolithic design. In
> comparison, how often do we see exploits for ls, head, cat, etc.?"
> 
I agree.

So at this point it's worth noting that the idea of replacing inetd
hasn't been finalised yet, and isn't that popular with most people
either -- including myself.

It's kinda there as a possibility for the future, it's not something
upstart can do right now.

If we were to do that, I would imagine that there would be a separate
process that did the network listening; and handed the open socket over
to the init daemon which started the services.


This decentralised process idea is something we're planning for other
bits of upstart.  For example we're convinced that we want to be able to
start and stop services because of DBUS messages, but don't want the
init daemon requiring the DBUS system bus be started first ... that
would be odd.

Instead we're planning for a upstart-dbus-proxy daemon that's started
along with the system bus, connects to it, and acts as a proxy talking
to the init daemon using its own native IPC.

That way is far more secure,

Scott
-- 
Have you ever, ever felt like this?
Had strange things happen?  Are you going round the twist?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/upstart-devel/attachments/20070107/3d771a3f/attachment.pgp