Discussion:
[Sisuite-devel] Debian support in trunk - init scripts
g***@free.fr
2007-10-16 18:39:22 UTC
Permalink
Hi all,

In trunk all the init scripts are included into Debian packages with the
--no-start option. I agree that it fixes few issues but do we really want users
to manually start the daemons (because i guess that at the end they will have to
do so)?

Just a question i asked to myself comparing Debian stuff in trunk and in
systemimager-debian...

Regards,
Andrea Righi
2007-10-16 20:12:16 UTC
Permalink
Post by g***@free.fr
Hi all,
In trunk all the init scripts are included into Debian packages with the
--no-start option. I agree that it fixes few issues but do we really want users
to manually start the daemons (because i guess that at the end they will have to
do so)?
Just a question i asked to myself comparing Debian stuff in trunk and in
systemimager-debian...
I would say ok to automatically start systemimager-server-monitord,
systemimager-server-rsyncd and maybe systemimager-server-netbootmond (even if
NET_BOOT_DEFAULT=net by default in systemimager.conf), but I'm a bit dubious
about systemimager-server-flamethrowerd and in particular about
systemimager-server-bittorrent: special transports should be enabled only on a
explicit request by the user. And, in general, starting
systemimager-server-bittorrent at the boot is *bad* idea. BT_UPDATE=y by default
in /etc/systemimager/bittorrent.conf; this means that *all* the tarballs and the
torrents will be re-created at every reboot of the machine and this is a very
time consuming operation.

-Andrea
Geoffroy Vallée
2007-10-16 21:29:03 UTC
Permalink
Post by Andrea Righi
Post by g***@free.fr
Hi all,
In trunk all the init scripts are included into Debian packages with the
--no-start option. I agree that it fixes few issues but do we really want
users to manually start the daemons (because i guess that at the end they
will have to do so)?
Just a question i asked to myself comparing Debian stuff in trunk and in
systemimager-debian...
I would say ok to automatically start systemimager-server-monitord,
systemimager-server-rsyncd and maybe systemimager-server-netbootmond (even
if NET_BOOT_DEFAULT=net by default in systemimager.conf), but I'm a bit
dubious about systemimager-server-flamethrowerd and in particular about
systemimager-server-bittorrent: special transports should be enabled only
on a explicit request by the user. And, in general, starting
systemimager-server-bittorrent at the boot is *bad* idea. BT_UPDATE=y by
default in /etc/systemimager/bittorrent.conf; this means that *all* the
tarballs and the torrents will be re-created at every reboot of the machine
and this is a very time consuming operation.
-Andrea
Hi Andrea,

I agree that it is not a good idea to automatically start
systemimager-server-flamethrowerd and systemimager-server-bittorrent, i was
more thinking about the systemimager-server-rsyncd and maybe
systemimager-server-monitord. Sorry i was unclear.

For syncd and monitord, note that i think the automatic startup of the daemon
will fail with the current code because the init script will return an error
if the script does not "effectively" start (which is the case with the
default configuration). Therefore it may be impossible to install the
packages (see the todo list i sent few weeks ago).

But anyway, do you think we should start this two daemons by default or not?

Regards,
--
Geoffroy
Andrea Righi
2007-10-19 08:09:56 UTC
Permalink
Post by Geoffroy Vallée
Post by Andrea Righi
Post by g***@free.fr
Hi all,
In trunk all the init scripts are included into Debian packages with the
--no-start option. I agree that it fixes few issues but do we really want
users to manually start the daemons (because i guess that at the end they
will have to do so)?
Just a question i asked to myself comparing Debian stuff in trunk and in
systemimager-debian...
I would say ok to automatically start systemimager-server-monitord,
systemimager-server-rsyncd and maybe systemimager-server-netbootmond (even
if NET_BOOT_DEFAULT=net by default in systemimager.conf), but I'm a bit
dubious about systemimager-server-flamethrowerd and in particular about
systemimager-server-bittorrent: special transports should be enabled only
on a explicit request by the user. And, in general, starting
systemimager-server-bittorrent at the boot is *bad* idea. BT_UPDATE=y by
default in /etc/systemimager/bittorrent.conf; this means that *all* the
tarballs and the torrents will be re-created at every reboot of the machine
and this is a very time consuming operation.
-Andrea
Hi Andrea,
I agree that it is not a good idea to automatically start
systemimager-server-flamethrowerd and systemimager-server-bittorrent, i was
more thinking about the systemimager-server-rsyncd and maybe
systemimager-server-monitord. Sorry i was unclear.
For syncd and monitord, note that i think the automatic startup of the daemon
will fail with the current code because the init script will return an error
if the script does not "effectively" start (which is the case with the
default configuration). Therefore it may be impossible to install the
packages (see the todo list i sent few weeks ago).
But anyway, do you think we should start this two daemons by default or not?
Honestly I don't know which is the best solution... IMHO starting rsyncd and
monitord without an explicit action from the user could lead to security issues
(exposing the availability of the images before any customization of the
rsyncd.conf for example). OTOH starting the basic services at the boot could be
a good point in terms of usability: why the user has to start manually these
services when he'll surely use them? At least rsyncd is *always* needed for any
kind of operation made by systemimager.

In these cases I vote for the simplest solution: do not start the services on
boot and leave the things as they are.

The other problem, if I remember well, consists in the failure when you stop a
daemon and it has not been started before. Does this "corrupt" the removal of
the packages when the services are down? (not yet tested).

-Andrea
Geoffroy Vallée
2007-10-19 16:02:28 UTC
Permalink
Hi Andrea,
Post by Andrea Righi
Honestly I don't know which is the best solution... IMHO starting rsyncd
and monitord without an explicit action from the user could lead to
security issues (exposing the availability of the images before any
customization of the rsyncd.conf for example). OTOH starting the basic
services at the boot could be a good point in terms of usability: why the
user has to start manually these services when he'll surely use them? At
least rsyncd is *always* needed for any kind of operation made by
systemimager.
In these cases I vote for the simplest solution: do not start the services
on boot and leave the things as they are.
Works for me.
Post by Andrea Righi
The other problem, if I remember well, consists in the failure when you
stop a daemon and it has not been started before. Does this "corrupt" the
removal of the packages when the services are down? (not yet tested).
Yes i think so but we should double-check i am far from being 100% sure.

Regards,
--
Geoffroy
Loading...