Re: [DNG] OpenRC and Runit without SysVinit packages

[Steve Litt]

On Sat, 13 Oct 2018 10:31:33 -0400
Hendrik Boom  wrote:


> It would be pleasant to quiet those who chant "Nyaa Nyaa Devuan isn't 
> really about choice", but it's not worth the price we'd have to pay. 

Most anti-Devuan people are brainless, so if we were to (crazily)
incorporate some systemd in Devuan, they'd invent another chant. My
opinion is that as long as we keep supplying a sans-systemd OS, we
fulfill our mission, and people with brains understand that.

 
SteveT

Steve Litt 
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Alessandro Selli]

On 13/10/18 at 16:31, Hendrik Boom wrote:
> On Sat, Oct 13, 2018 at 09:55:46AM -0400, Steve Litt wrote:
>> On Fri, 12 Oct 2018 09:44:14 -0400
>> Hendrik Boom  wrote:
>>
>>
>>> And while we're at it, we want not to support systemd.
>>> But living with inert systemd scripts is at least tolerable.
>> Huh? U mean systemd unit files?
> yes.


  Again: systemd's unit files are *not* scripts!  Compare them with real
scripts:


~]$ /lib/systemd/system/zebra.service status
-bash: /lib/systemd/system/zebra.service: Permission denied
~]$ file /lib/systemd/system/zebra.service
/lib/systemd/system/zebra.service: ASCII text
~]$


~]$/etc/init.d/tinc status
Usage: /etc/init.d/tinc {start|stop|reload|restart|force-reload|alarm}
~]$ file /etc/init.d/tinc
/etc/init.d/tinc: POSIX shell script, ASCII text executable
~]$



  Are new a newbie to GNU/Linux?



-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Jimmy Johnson]

On 10/12/2018 01:56 AM, KatolaZ wrote:

On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote:

On Fri, 12 Oct 2018 03:24:44 +
alecfeld...@disroot.org wrote:



1. Split the runit package into separate packages with alternate
stage files.

2. Provide a configuration file for how runit should act. For
instance, if openrc or sysvinit is installed, runit can depend
on /etc/init.d and /etc/rc*.d scripts for booting.


On a related note, I think the best way of acquiring runit run files is
to install Void Linux on a VM, install all the various daemons, and
then view the run files in /etc/sv/$daemonname/run.

Void has had enough time supporting runit that most of their run files
work great. The exceptions usually assume device names that shouldn't
be assumed.

Devuan could thus acquire a whole bunch of run scripts and not have to
beg the upstreams to do it.



The main problem remains how to distribute those scripts, without
having to fork all the packages that provide a runit script and don't
have one in the corresponding Debian package. Any concrete proposal is
welcome there (but I know that most of the simple ones won't work,
since people willing to use runit want their preferred service to work
ootb and already have runit scripts, and only when they install that
specific server...).

Also, we are not just talking of supporting either openrc or runit,
but to add support for runit *on top* of sysvinit and openrc.

We should definitely find a way through, but I can't see the optimal
one at the moment :\

My2Cents

KatolaZ



Why not a meta-package including all packages for each init?
--
Jimmy Johnson

Slackware64 14.2 - KDE 4.14.32 - AMD A8-7600 - EXT4 at sda9
Registered Linux User #380263

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Hendrik Boom]

On Sat, Oct 13, 2018 at 09:55:46AM -0400, Steve Litt wrote:
> On Fri, 12 Oct 2018 09:44:14 -0400
> Hendrik Boom  wrote:
> 
> 
> > And while we're at it, we want not to support systemd.
> > But living with inert systemd scripts is at least tolerable.
> 
> Huh? U mean systemd unit files?

yes.

> 
> > Ideally there should be some systematic solution for all of this, 
> > leaving the choices to the sysadmin, but I don't see it as easy.
> 
> I think the sysadmin choice,  if he wants systemd, is to quit Devuan
> and go to Debian. If we try to support systemd just a little, we start
> down a path which will be difficult to travel and even more difficult
> to back out of.

Correct.  We do not have the resources, and Debian, who might, isn't 
interested.

It would be pleasant to quiet those who chant "Nyaa Nyaa Devuan isn't 
really about choice", but it's not worth the price we'd have to pay. 

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Steve Litt]

On Fri, 12 Oct 2018 09:44:14 -0400
Hendrik Boom  wrote:


> And while we're at it, we want not to support systemd.
> But living with inert systemd scripts is at least tolerable.

Huh? U mean systemd unit files?

> Ideally there should be some systematic solution for all of this, 
> leaving the choices to the sysadmin, but I don't see it as easy.

I think the sysadmin choice,  if he wants systemd, is to quit Devuan
and go to Debian. If we try to support systemd just a little, we start
down a path which will be difficult to travel and even more difficult
to back out of.

SteveT

Steve Litt 
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Steve Litt]

On Fri, 12 Oct 2018 10:56:26 +0200
KatolaZ  wrote:

> On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote:

> > On a related note, I think the best way of acquiring runit run
> > files is to install Void Linux on a VM, install all the various
> > daemons, and then view the run files in /etc/sv/$daemonname/run.
> > 
> > Void has had enough time supporting runit that most of their run
> > files work great. The exceptions usually assume device names that
> > shouldn't be assumed.
> > 
> > Devuan could thus acquire a whole bunch of run scripts and not have
> > to beg the upstreams to do it.
> >   
> 
> The main problem remains how to distribute those scripts, without
> having to fork all the packages that provide a runit script and don't
> have one in the corresponding Debian package. 

Who needs packages? Just have all the scripts on a website somewhere,
downloadable. Anybody wanting to use runit just installs the runscript
and makes the symlink. A simple document would tell them how. It's
easier than package handling.


[snip]

> Also, we are not just talking of supporting either openrc or runit,
> but to add support for runit *on top* of sysvinit and openrc.

Yes! As a matter of fact, a good intermediate goal would be runit used
only as a supervisor, on top of sysvinit or on top of sysvinit plus
OpenRC. As such, it would stand alone as a tiny "do one thing and do it
right" process.

> We should definitely find a way through, but I can't see the optimal
> one at the moment :\

I think we should start by enabling runit (and perhaps s6) as a
supervisor only. We could curate runit run scripts mostly from Void
Linux, and make documents on how to switch supervision of a process
from /etc/rc.d/init.d to runit. When lots of people find out how easy
and wonderful it is, the next step will reveal itself.
 
SteveT

Steve Litt 
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Steve Litt]

On Thu, 11 Oct 2018 23:23:38 -0700
Rick Moen  wrote:

> Part
> of the point I wanted to make, here (bearing in mind that I'm
> speaking only my own view), is that Devuan needs to be mindful of
> priorities and has necessarily limited volunteer effort.  For better
> or worse, _if_ I understand correctly, for now Devuan's primary
> delivery target for current and future releases involves SysVInit.
> 
> As it hapens, I personally share your liking for OpenRC over SysVInit,
> and respect runit based on readings but haven't experimented with it
> as Steve Litt has.  But my point is that, if I guess correctly, in the
> short term there may not be enough time/effort available to build in
> fully packaged, optimally architected implementations of those two
> init systems.

Speaking for both runit and s6, packaging isn't all that necessary. A
document would suffice. Runit's not a huge monster like sysvinit (or
a massively entangled monolith like systemd). And in my opinion, the
capability of initting with multiple inits is s *good* thing.

> 
> The other immediate thought I had, and I'll just throw this out as a
> slightly rhetorical question:  Is it so bad to retain the PID1-process
> fragment of SysVinit, e.g., as what runs the OpenRC init system?
> Seems to me, it's the part of SysVinit nobody has any significant
> problem with.  It's not unreasonably complex, it's not notably buggy,
> and it's certainly not overfeatured.

Yes. First of all, you need sysvinit or something like it to be
OpenRC's PID1, so yeah, install sysvinit just to init via OpenRC:
That's how OpenRC is designed to be used, and /etc/inittab is OpenRC's
way of doing respawns (unless OpenRC has recently acquired powers I
don't know about). Second, it's quite a bit easier to run runit as a
non-init supervisor, using sysvinit's PID1. All you do when you want
sane supervision is:

1) Permanently disable the service from /etc/rc.d/init.d

2) Obtain a runit run script (from Void Linux?)

3) Spin up the service in runit: Mainly just install a symlink.

The three preceding work equally well for s6, although I know of no
distro defaulting to s6 so somebody has to write the run scripts. None
of what we're talking about involves changes to current packaging, so
we can respect the priorities Rick discussed.

> 
> I note with interest and appreciation your suggestions about how runit
> might be provided in better built packaging, but will leave it to
> others (such as my friend Steve Litt) to comment.  Daniel's wording
> about a way to extend these ideals into a framework for other init
> systems is particularly cheering, so thanks for posting that.

My understanding is that the current Debian runit package is sufficient
to use runit as a non-initting, non-PID1 *supervisor*. If this is true,
why not run it (no pun intended) that way? We'd need a document stating
best practices in turning off the daemon from /etc/rc.d/init.d, and
we'd need to grab the run script from Void and make sure it works.

Everyone knows I don't like sysvinit, because of the monstrous init
scripts. But if supervision is done by runit, s6 or daemontools-encore,
my entire objection goes away, because the sysvinit scripts aren't
used. There's nothing wrong with the PID1 part of sysvinit.

SteveT

Steve Litt 
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Alessandro Selli]

On 12/10/18 at 15:44, Hendrik Boom wrote:
> living with inert systemd scripts


  Uh?  What scripts?  What systemd scripts (i.e. executable, interpreted
text files) do Devuan packages install?


Alessandro


-- 
Alessandro Selli 
VOIP SIP: dhatarat...@ekiga.net
Chiave firma e cifratura PGP/GPG signing and encoding key:
  BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE




signature.asc
Description: OpenPGP digital signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Hendrik Boom]

On Fri, Oct 12, 2018 at 10:56:26AM +0200, KatolaZ wrote:
> On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote:
> > On Fri, 12 Oct 2018 03:24:44 +
> > alecfeld...@disroot.org wrote:
> > 
> > 
> > > 1. Split the runit package into separate packages with alternate
> > > stage files.
> > > 
> > > 2. Provide a configuration file for how runit should act. For
> > > instance, if openrc or sysvinit is installed, runit can depend
> > > on /etc/init.d and /etc/rc*.d scripts for booting.
> > 
> > On a related note, I think the best way of acquiring runit run files is
> > to install Void Linux on a VM, install all the various daemons, and
> > then view the run files in /etc/sv/$daemonname/run.
> > 
> > Void has had enough time supporting runit that most of their run files
> > work great. The exceptions usually assume device names that shouldn't
> > be assumed.
> > 
> > Devuan could thus acquire a whole bunch of run scripts and not have to
> > beg the upstreams to do it.
> > 
> 
> The main problem remains how to distribute those scripts, without
> having to fork all the packages that provide a runit script and don't
> have one in the corresponding Debian package. Any concrete proposal is
> welcome there (but I know that most of the simple ones won't work,
> since people willing to use runit want their preferred service to work
> ootb and already have runit scripts, and only when they install that
> specific server...).
> 
> Also, we are not just talking of supporting either openrc or runit,
> but to add support for runit *on top* of sysvinit and openrc.

And while we're at it, we want not to support systemd.
But living with inert systemd scripts is at least tolerable.
Ideally there should be some systematic solution for all of this, 
leaving the choices to the sysadmin, but I don't see it as easy.

-- hendrik

> 
> We should definitely find a way through, but I can't see the optimal
> one at the moment :\
> 
> My2Cents
> 
> KatolaZ
> 
> -- 
> [ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
> [ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
> [   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
> [ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
> [ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]



> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[KatolaZ]

On Thu, Oct 11, 2018 at 11:55:29PM -0400, Steve Litt wrote:
> On Fri, 12 Oct 2018 03:24:44 +
> alecfeld...@disroot.org wrote:
> 
> 
> > 1. Split the runit package into separate packages with alternate
> > stage files.
> > 
> > 2. Provide a configuration file for how runit should act. For
> > instance, if openrc or sysvinit is installed, runit can depend
> > on /etc/init.d and /etc/rc*.d scripts for booting.
> 
> On a related note, I think the best way of acquiring runit run files is
> to install Void Linux on a VM, install all the various daemons, and
> then view the run files in /etc/sv/$daemonname/run.
> 
> Void has had enough time supporting runit that most of their run files
> work great. The exceptions usually assume device names that shouldn't
> be assumed.
> 
> Devuan could thus acquire a whole bunch of run scripts and not have to
> beg the upstreams to do it.
> 

The main problem remains how to distribute those scripts, without
having to fork all the packages that provide a runit script and don't
have one in the corresponding Debian package. Any concrete proposal is
welcome there (but I know that most of the simple ones won't work,
since people willing to use runit want their preferred service to work
ootb and already have runit scripts, and only when they install that
specific server...).

Also, we are not just talking of supporting either openrc or runit,
but to add support for runit *on top* of sysvinit and openrc.

We should definitely find a way through, but I can't see the optimal
one at the moment :\

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Rick Moen]

Quoting alecfeld...@disroot.org (alecfeld...@disroot.org):

> First of all, I want to thank the developers for the efforts to
> continue debian without "systemd creep". I've experimented with the
> distribution on and off, but there's one big turnoff for me currently
> that I don't think would take an enormous amount of effort to change:
> sysvinit. While it does work perfectly fine on its own, I prefer
> openrc, and runit even more so. While they do work in Devuan, they
> require sysvinit as a "backend". In Devuan ceres and up, openrc 0.25
> provides openrc-init and no longer relies on sysvinit-core. In fact,
> it can be removed entirely (I have an addiction to removing everything
> I don't want to use). However, openrc-init boots openrc directly and
> skips the /etc/inittab file, so it won't start the gettys. All that
> would be needed to fix this is a separate getty service package.

You're right, of course.  (For clarification purposes, I'm not a Devuan
project spokesperson of any kind, just another interested user and
longtime sysadmin.)  It would be cool if that were done, and maybe the
maintainers will figure out the best way to do that.  Part of the point
I wanted to make, here (bearing in mind that I'm speaking only my own
view), is that Devuan needs to be mindful of priorities and has
necessarily limited volunteer effort.  For better or worse, _if_ I
understand correctly, for now Devuan's primary delivery target for
current and future releases involves SysVInit.

As it hapens, I personally share your liking for OpenRC over SysVInit,
and respect runit based on readings but haven't experimented with it as
Steve Litt has.  But my point is that, if I guess correctly, in the
short term there may not be enough time/effort available to build in
fully packaged, optimally architected implementations of those two init
systems.

The other immediate thought I had, and I'll just throw this out as a
slightly rhetorical question:  Is it so bad to retain the PID1-process
fragment of SysVinit, e.g., as what runs the OpenRC init system?  Seems
to me, it's the part of SysVinit nobody has any significant problem
with.  It's not unreasonably complex, it's not notably buggy, and it's
certainly not overfeatured.

I note with interest and appreciation your suggestions about how runit
might be provided in better built packaging, but will leave it to others 
(such as my friend Steve Litt) to comment.  Daniel's wording about a way
to extend these ideals into a framework for other init systems is
particularly cheering, so thanks for posting that.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Runit without SysVinit packages

[Steve Litt]

On Fri, 12 Oct 2018 03:24:44 +
alecfeld...@disroot.org wrote:


> 1. Split the runit package into separate packages with alternate
> stage files.
> 
> 2. Provide a configuration file for how runit should act. For
> instance, if openrc or sysvinit is installed, runit can depend
> on /etc/init.d and /etc/rc*.d scripts for booting.

On a related note, I think the best way of acquiring runit run files is
to install Void Linux on a VM, install all the various daemons, and
then view the run files in /etc/sv/$daemonname/run.

Void has had enough time supporting runit that most of their run files
work great. The exceptions usually assume device names that shouldn't
be assumed.

Devuan could thus acquire a whole bunch of run scripts and not have to
beg the upstreams to do it.

SteveT

Steve Litt 
September 2018 featured book: Quit Joblessness: Start Your Own Business
http://www.troubleshooters.com/startbiz
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] OpenRC and Runit without SysVinit packages

[alecfeldman]

This is a "remail" of what I sent Daniel about a month ago for others on the 
mailing list to see with a few changes and added details.

First of all, I want to thank the developers for the efforts to continue debian 
without "systemd creep". I've experimented with the distribution on and off, 
but there's one big turnoff for me currently that I don't think would take an 
enormous amount of effort to change: sysvinit. While it does work perfectly 
fine on its own, I prefer openrc, and runit even more so. While they do work in 
Devuan, they require sysvinit as a "backend". In Devuan ceres and up, openrc 
0.25 provides openrc-init and no longer relies on sysvinit-core. In fact, it 
can be removed entirely (I have an addiction to removing everything I don't 
want to use). However, openrc-init boots openrc directly and skips the 
/etc/inittab file, so it won't start the gettys. All that would be needed to 
fix this is a separate getty service package. Runit is a different story, since 
its initialization and shutdown stages rely heavily on sysv-rc scripts 
(/etc/rc*.d). These scripts can be completely avoided by using an 
implementation similar to how Void Linux does it. In fact, I did some tweaking 
with https://github.com/cloux/aws-devuan (https://github.com/cloux/aws-devuan) 
and https://gitea.artixlinux.org/artix/runit-rc 
(https://gitea.artixlinux.org/artix/runit-rc). I was able to get a fully 
booting devuan install without any initscripts. However, these aren't 
officially supported in Devuan, and should thus not be considered permanent 
solutions. With that in mind, what would be a permanent solution? I proposed 
two:

1. Split the runit package into separate packages with alternate stage files.

2. Provide a configuration file for how runit should act. For instance, if 
openrc or sysvinit is installed, runit can depend on /etc/init.d and /etc/rc*.d 
scripts for booting.

Daniel in response proposed:

For your runit proposal we could probably modify or provide a runit source that 
builds binaries that have the needed changes for each init system it runs 
alongside - ie runit-sysvinit, runit-openrc, runit-init etc. We can build these 
from the same source package and just provide the alternate stage files. This 
makes it also extensible to other init systems down the track.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] OpenRC and Runit without SysVinit packages

[alecfeldman]

This is a "remail" of what I sent Daniel about a month ago for others on the 
mailing list to see with a few changes and added details.

First of all, I want to thank the developers for the efforts to continue debian 
without "systemd creep". I've experimented with the distribution on and off, 
but there's one big turnoff for me currently that I don't think would take an 
enormous amount of effort to change: sysvinit. While it does work perfectly 
fine on its own, I prefer openrc, and runit even more so. While they do work in 
Devuan, they require sysvinit as a "backend". In Devuan ceres and up, openrc 
0.25 provides openrc-init and no longer relies on sysvinit-core. In fact, it 
can be removed entirely (I have an addiction to removing everything I don't 
want to use). However, openrc-init boots openrc directly and skips the 
/etc/inittab file, so it won't start the gettys. All that would be needed to 
fix this is a separate getty service package. Runit is a different story, since 
its initialization and shutdown stages rely heavily on sysv-rc scripts 
(/etc/rc*.d). These scripts can be completely avoided by using an 
implementation similar to how Void Linux does it. In fact, I did some tweaking 
with https://github.com/cloux/aws-devuan (https://github.com/cloux/aws-devuan) 
and https://gitea.artixlinux.org/artix/runit-rc 
(https://gitea.artixlinux.org/artix/runit-rc). I was able to get a fully 
booting devuan install without any initscripts. However, these aren't 
officially supported in Devuan, and should thus not be considered permanent 
solutions. With that in mind, what would be a permanent solution? I proposed 
two:

1. Split the runit package into separate packages with alternate stage files.

2. Provide a configuration file for how runit should act. For instance, if 
openrc or sysvinit is installed, runit can depend on /etc/init.d and /etc/rc*.d 
scripts for booting.

Daniel in response proposed:

For your runit proposal we could probably modify or provide a runit source that 
builds binaries that have the needed changes for each init system it runs 
alongside - ie runit-sysvinit, runit-openrc, runit-init etc. We can build these 
from the same source package and just provide the alternate stage files. This 
makes it also extensible to other init systems down the track.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] openrc init: Was Re: Please provide systemd-free libreswan package

[Benda Xu]

Hi all,

Acknowledged!

Could you elaborate the main feature of openrc-init that sysvinit does
not have?

Yours,
Benda

Svante Signell  writes:

> On Fri, 2017-11-17 at 08:42 -0500, Ismael L. Donis Garcia wrote:
>
>> But I understand that the new versions of openrc already bring the 
>> possibility of functioning as an init system independently.
>> 
>> In that case, openrc could not be used as an alternative init?
>
> Yes, openrc is now able to be pid 1 with openrc-init,
> see https://wiki.gentoo.org/wiki/OpenRC
>
> Unfortunately the Debian packager has not enabled this yet. It would be
> nice if it could be selectable.
>
> Benda, hint hint :)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] openrc-init: Was Re: Please provide systemd-free libreswan package

[Svante Signell]

On Sat, 2017-11-18 at 01:51 -0500, Steve Litt wrote:
> On Fri, 17 Nov 2017 08:42:51 -0500
> "Ismael L. Donis Garcia"  wrote:
> 
> > But I understand that the new versions of openrc already bring the 
> > possibility of functioning as an init system independently.
> > 
> > In that case, openrc could not be used as an alternative init?
> 
> Yes.
> 
> However, an alternative init wasn't the subject of this thread: It
> started as getting libreswan to run even though Debian doesn't
> provide a sysvinit init script, and then addition of a Process
> Supervisor to sysvinit was suggested (by me) as a possible solution.
> 
> Later, somebody renamed this thread to "openrc init", which discusses
> openrc as an alternative init.

That somebody was me. Hi Steve I have a name. And if discussing openrc
as an init you should have replied to my mail, not the previous one.
And openrc-init is not a supervisor, has never claimed to be either.

In my opinion you are pushing too hard for your runit, s6 etc scrpits.
Just show us the code please. That talks much more than words ;)

Just for clarity: This changed thread subject is _not_ about libreswan
or or supervisors. You can continue with that in the origilan thread.
But honestly, that thread is not even about supervisors. Maybe you
should start your own thread?

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] openrc init: Was Re: Please provide systemd-free libreswan package

[Svante Signell]

On Fri, 2017-11-17 at 08:42 -0500, Ismael L. Donis Garcia wrote:

> But I understand that the new versions of openrc already bring the 
> possibility of functioning as an init system independently.
> 
> In that case, openrc could not be used as an alternative init?

Yes, openrc is now able to be pid 1 with openrc-init,
see https://wiki.gentoo.org/wiki/OpenRC

Unfortunately the Debian packager has not enabled this yet. It would be
nice if it could be selectable.

Benda, hint hint :)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] openrc, eudev, test iso

[fsmithred]

On 08/16/2017 07:06 AM, fsmithred wrote:
> 
> It is installable with refractainstaller, but it has grub-efi installed.
> If you're on a legacy bios system, install the grub-pc debs before you run
> the installer, and don't select a place for the bootloader if it asks. Let
> the installer do that (it will ask, too.) Grub debs are in the root of the
> filesystem. In the live session, run:
>   dpkg -i /grub-pc*.deb
> 

No, that's wrong. grub-efi was installed and was replaced with grub-pc.
You don't have to do anything special before running the installer. If you
happen to boot on uefi, it will boot and efibootmgr is still installed and
will run. Use the graphical installer from the menu and it will (should)
do the right thing. Both grub-pc and grub-efi debs are in / in case you
need them.

fsr


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] openrc, eudev, test iso

[fsmithred]

On 08/16/2017 07:06 AM, fsmithred wrote:
> I made a live-iso with ascii, openrc and eudev for testing purposes.
> http://distro.ibiblio.org/refracta/files/experimental/ascii_oblx_eudv_oprc-20170813_.iso
> 
> This started as a no-X Refracta-ascii amd64 live iso (standard system plus
> extra system utilities). Added openbox, lxpanel, lxterminal, leafpad and a
> couple other apps. Didn't do much in the way of configuring.
> 
> It is installable with refractainstaller, but it has grub-efi installed.
> If you're on a legacy bios system, install the grub-pc debs before you run
> the installer, and don't select a place for the bootloader if it asks. Let
> the installer do that (it will ask, too.) Grub debs are in the root of the
> filesystem. In the live session, run:
>   dpkg -i /grub-pc*.deb
> 
> 
> If you want to do it yourself, short instructions for installing openrc
> are here:
> https://dev1galaxy.org/viewtopic.php?pid=4443#p4443
> 
> and for installing eudev:
> https://dev1galaxy.org/viewtopic.php?id=1543
> 
> fsmithred
> 

You might need this:

login/password:  root/root, user/user

fsr

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] openrc, eudev, test iso

[fsmithred]

I made a live-iso with ascii, openrc and eudev for testing purposes.
http://distro.ibiblio.org/refracta/files/experimental/ascii_oblx_eudv_oprc-20170813_.iso

This started as a no-X Refracta-ascii amd64 live iso (standard system plus
extra system utilities). Added openbox, lxpanel, lxterminal, leafpad and a
couple other apps. Didn't do much in the way of configuring.

It is installable with refractainstaller, but it has grub-efi installed.
If you're on a legacy bios system, install the grub-pc debs before you run
the installer, and don't select a place for the bootloader if it asks. Let
the installer do that (it will ask, too.) Grub debs are in the root of the
filesystem. In the live session, run:
  dpkg -i /grub-pc*.deb


If you want to do it yourself, short instructions for installing openrc
are here:
https://dev1galaxy.org/viewtopic.php?pid=4443#p4443

and for installing eudev:
https://dev1galaxy.org/viewtopic.php?id=1543

fsmithred

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OPENRC now works! thank you Svante for your patience

[zap]

Just to make it clear, I have replied once more with the title changed...

I have donated 10$ to devuan as a thanks. I am not super rich, but I
have done what I can. so thank you.


On 07/02/2017 04:34 PM, zap wrote:
>
> On 07/02/2017 04:25 PM, Svante Signell wrote:
>> On Sun, 2017-07-02 at 14:51 -0400, zap wrote:
>>> I appear to be getting conflicts, so I must need sysvinit-utils in
>>> deb
>>> form.
>>> this probably is the last thing I need at the moment to make it
>>> work...
>> Sorry, but you have to show us what conflicts you see... And your
>> /etc/apt/sources.list, and your commands used.
> That makes sense my bad... I just got to the last step. I just have to
> install initscripts. I figured a way out somehow? gdebi isn't as
> reliable I guess..
>
> Edit: I finally got it installed,
>
> at last...
>
> Tell me something though, is it up to testing quality standards yet?
> regardless, though thank you for being paitent, this was kind of
> confusing... heh.  dpkg > gdebi 
>
> for some reason gdebi must have been causing failures aka... hehe.
>

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Svante Signell]

On Sun, 2016-09-11 at 23:59 +0200, emnin...@riseup.net wrote:
> Am Sun, 11 Sep 2016 18:09:56 +0200
> schrieb Svante Signell :
> 
> > 
> > Maybe you have to install sys-rc before installing openrc?
> 
> I looked and i have already installed sysv-rc. In any case, i did a
> re-install but it did not help.
> 
> Does that mean openrc as an option for devuan is gone?

emninger,

with the latest release 0.21-3, with a patch by Marvin Kohl and an
upload by Adam Borowski, the Debian version of openrc should be
installable again, also in Devuan.

Good luck!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Adam Borowski]

On Mon, Sep 12, 2016 at 10:32:52AM +0200, Jaromil wrote:
> On Sun, 11 Sep 2016, emnin...@riseup.net wrote:
> > Does that mean openrc as an option for devuan is gone?
> 
> not at all. We even plan to roll out our own openrc package, ditching
> the one from Debian which has many problems. Perhaps what you are
> hitting is one of them.
> 
> For Devuan's Openrc we will follow the design proposed by upstream and
> Gentoo's, the maintainer volunteering for this is Parazyd (also on
> this list) who works with us at Dyne.org. We will also use Openrc in
> our projects and are advocating for it as the next new standard in
> Devuan ascii, at the condition of a 100% smooth transition from
> sysvinit.
> 
> At last, we haven't done anything on the OpenRC package yet so your
> problems are entirely caused by the Debian maintainership, which can't
> be trusted at all, IMHO

Actually, it appears there's effectively _no_ Debian maintainership.
The package was uninstallable (but upgradeable) for two months, including
a week after someone posted a patch to the bug report.

I've just uploaded that fix.  Technically, I do have commit rights to the
packaging repository (got them after a NMU), but I've never really cared
about openrc -- sysv-rc works well enough for me, at least so far.

So, if you have some ideas for what to change, please step up!  If you say,
"we will follow the design proposed by upstream and Gentoo", the current
main maintainer's (Benda Xu's) address @gentoo.org doesn't exactly look like
someone not aligned with them :)  He apparently has no tuits to work on
openrc's maintenance in Debian so I guess any help is welcome.

I see some bugs I could fix:
* closing fds 0,1,2 is bad (#832940)
* scary bogus messages on upgrade about replacing sysv-rc
* insserv warnings
but I don't commit to any serious work myself, sorry, at least for now.


There are areas where you'd want to differentiate Devuan from Debian to give
people a reason to switch, but I'd say openrc is one where it'd be a really
bad idea: if sysv-rc goes away and openrc is not in a good enough shape, you
can count on hordes of systemd fanbois to start purging non-systemd support. 
And suddenly having to maintain a diff for thousands of packages is
something you don't have the manpower for.


Meow!
-- 
An imaginary friend squared is a real enemy.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Didier Kryn]

Le 16/09/2016 18:32, Steve Litt a écrit :

On Fri, 16 Sep 2016 12:24:45 +0200
Didier Kryn  wrote:


  Steve,

  I like more and more this idea of separating the tasks:
   - pid1 (sysvinit or whatever) performs one-shot startups and
basic supervision (like for getty),

sysvinit, right? Spawn your gettys and run the rc files, which run the
supervisor. Is that what you mean?


Rather the following: sysvinit spawns your gettys and your 
supervisor, and runs the rc files.



   - services needing a sophisticated supervisor use a supervisor
which is only a supervisor, not pid1,

This could be daemontools-encore or runit or s6.


   - services which depend on conditions use specialized tools to
wait for these conditions.

Does OpenRC do the conditional starts?

The architecture I had in mind looks something like this:

..   ..
|sysvinit| .--. run as   |runit supvisr or|
|  PID1  |-|OpenRC|--|daemontools or  |
`' `--' daemon   |s6 supervisor   |
   |  |   `'
   |-getty1   `-most processes|-httpd
   |-getty1   |-sshd
   |-...  `-Other respawnables
   `-getty6


Yes, or the following, where runit etc is respawned automatically 
by sysvinit.


..
|sysvinit|
|  PID1  |  ..
`'  |runit supvisr or|   |-httpd
  |-|daemontools or  |---|-sshd
  | |s6 supervisor   |   |-other supervised servers
  | `'
  |-getty1
  |-getty1
  |...
  |-getty6  .---.
  | | whatever  |
  |-| launch-and-forget |---|-other services
| rc|
`---'

   But this makes sense only if the supervisor (runit, s6, etc) has a smarter 
way to keep track of its children than wait(). For example, it could keep some 
named pipe connection to each of them. I haven't explored the ways to do that, 
though.


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 19:16:01 +0200
poitr pogo  wrote:

> I agree.
> In perfect world of knowlegable programmers writing software that
> works there is no need for supervisors.
> 
> One can handle errors or leave this for supervisor.
> 
> For me supervisor will always be a tool of a helpless admin.

:-)

Lighten up you guys. I'm not telling you to use supervisors, and I'm
not putting in Halloween Code to force you to use supervisors. I'm not
telling you to to blindly respawn on aircraft navigation systems, Xray
machines, or missile guidance systems.

I'm simply pointing out that supervision systems have some major
conveniences on both desktops and servers, and that these conveniences
widen their appeal beyond helpless admins and 0.0001% of users.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 13:17:52 -0400
Rob Owens  wrote:

> On Fri, Sep 16, 2016 at 12:32 PM, Steve Litt
>  wrote:
> 
> >
> > Does OpenRC do the conditional starts?  
> 
> 
> Yes, it does.  See "The depend function" here:
> http://www.funtoo.org/Package:OpenRC

Nice!

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Rob Owens]

On Fri, Sep 16, 2016 at 12:32 PM, Steve Litt 
wrote:

>
> Does OpenRC do the conditional starts?


Yes, it does.  See "The depend function" here:
http://www.funtoo.org/Package:OpenRC
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[poitr pogo]

I agree.
In perfect world of knowlegable programmers writing software that works
there is no need for supervisors.

One can handle errors or leave this for supervisor.

For me supervisor will always be a tool of a helpless admin.

Regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 12:52:45PM -0400, Steve Litt wrote:

[cut]

> > 
> > But I am sure that 99.% of the users do not need supervisors in
> > 99.% of the cases...
> 
> I wouldn't say 99.%. I think everyone running wpa_supplicant can
> benefit from having it respawnable, because it crashes at the slightest
> excuse, and respawning makes it available whenever needed.
>

Sorry but if wpa_supplicant crashes for whatever reason (something
that I have never experienced so far, to be honest), then it means
that wpa_supplicant is not doing its job properly. The only way for a
program to do its job properly is by *stayng alive* not by
*crashing*.

If a program crashes while doing its job, then you don't need a
supervisor, rather a piece of software which does its job without
crashing. Crashing should not be the norm, ever. And the problem is
not solved by respawning, ever. 

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 15:22:25 +0100
KatolaZ  wrote:

> On Fri, Sep 16, 2016 at 03:51:43PM +0200, Didier Kryn wrote:
> 
> [cut]
> 
> > Nobody supervises pid1, OK? So why would the supervisor need to
> > be supervised? It is supposed to be rock solid. Note that it can be
> > barely relaunched by sysvinit in the same way as getty.
> >   
> 
> Yep, but if a supervisor dies, all his children will be orphaned, and
> even if init respawns the supervisor, this might not imply that all
> the supervisor's children are respawn :)
> 
> I personally don't care at all about supervision systems, since I find
> them completely useless in most of the common applications. I have
> written a couple of custom ones, back in the days, but just for really
> mission-critical stuff, where a process failing to do something meant
> potentially damaging costly devices. And in that case the most logical
> thing to do was to have part of the supervision managed by pid1.
> 
> But I am sure that 99.% of the users do not need supervisors in
> 99.% of the cases...

I wouldn't say 99.%. I think everyone running wpa_supplicant can
benefit from having it respawnable, because it crashes at the slightest
excuse, and respawning makes it available whenever needed.

Supervisors have more benefits than just respawning. They're easier to
understand. They're easier to turn on and off in a wide variety of
situations. They're more trackable via ps axjf. With supervisors, you
don't need to deal with PID files. And, perhaps coolest of all, if
you're running processes off a supervisor, you can make your own daemon
simply by writing a program that runs in the foreground, and the
supervisor will "daemonize" it, instead of having to write your program
to doublefork itself.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 15:51:43 +0200
Didier Kryn  wrote:

> Le 16/09/2016 13:15, KatolaZ a écrit :
> > On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:
> >
> > [cut]
> >  
> >>  Steve,
> >>
> >>  I like more and more this idea of separating the tasks:
> >>   - pid1 (sysvinit or whatever) performs one-shot startups and
> >> basic supervision (like for getty),
> >>   - services needing a sophisticated supervisor use a
> >> supervisor which is only a supervisor, not pid1,
> >>   - services which depend on conditions use specialized tools
> >> to wait for these conditions.
> >>  
> > That looks like a great plan, but who will supervise the
> > supervisors? :)
> >
> > I admit this might seem like a stupid comment, at least at first
> > sight, but whenever you introduce a supervision system under unix
> > you most probably end up deciding that the supervision should be
> > delegated to pid1, since pid1 is the only process able to guarantee
> > that supervision will be working, whatever happens.  
>  Nobody supervises pid1, OK? So why would the supervisor need to
> be supervised? It is supposed to be rock solid. Note that it can be
> barely relaunched by sysvinit in the same way as getty.

I can answer that. There are a lot of architectures in which the
supervisor isn't part of PID1, in which case the purist would say it
must be supervised at least enough, by PID1, that PID1 can respawn the
supervisor.
 
SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 12:24:45 +0200
Didier Kryn  wrote:

>  Steve,
> 
>  I like more and more this idea of separating the tasks:
>   - pid1 (sysvinit or whatever) performs one-shot startups and
> basic supervision (like for getty),

sysvinit, right? Spawn your gettys and run the rc files, which run the
supervisor. Is that what you mean?

>   - services needing a sophisticated supervisor use a supervisor 
> which is only a supervisor, not pid1,

This could be daemontools-encore or runit or s6.

>   - services which depend on conditions use specialized tools to 
> wait for these conditions.

Does OpenRC do the conditional starts?

The architecture I had in mind looks something like this:

..   ..
|sysvinit| .--. run as   |runit supvisr or|
|  PID1  |-|OpenRC|--|daemontools or  |
`' `--' daemon   |s6 supervisor   |
  |  |   `'
  |-getty1   `-most processes|-httpd
  |-getty1   |-sshd
  |-...  `-Other respawnables
  `-getty6


I once built the preceding architecture in Manjaro-OpenRC, and it
worked. Regardless of your "init system", it's always an asset to
control your own process supervisor.
 
SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Peter Olson]

> On September 16, 2016 at 9:51 AM Didier Kryn  wrote:
> 
> Le 16/09/2016 13:15, KatolaZ a écrit :
> > On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:
> >
> > [cut]
> >
> >>  Steve,
> >>
> >>  I like more and more this idea of separating the tasks:
> >>   - pid1 (sysvinit or whatever) performs one-shot startups and basic
> >> supervision (like for getty),
> >>   - services needing a sophisticated supervisor use a supervisor which 
> >> is
> >> only a supervisor, not pid1,
> >>   - services which depend on conditions use specialized tools to wait 
> >> for
> >> these conditions.
> >>
> > That looks like a great plan, but who will supervise the supervisors?
> > :)
> >
> > I admit this might seem like a stupid comment, at least at first
> > sight, but whenever you introduce a supervision system under unix you
> > most probably end up deciding that the supervision should be delegated
> > to pid1, since pid1 is the only process able to guarantee that
> > supervision will be working, whatever happens.
>  Nobody supervises pid1, OK? So why would the supervisor need to be 
> supervised? It is supposed to be rock solid. Note that it can be barely 
> relaunched by sysvinit in the same way as getty.
> 
>  Didier

In the spirit of the minimal PID1 in 30 lines of code, I would propose that one 
of the RC tasks spawned by it would be the minimal supervisor in about 30 lines 
of code, which only supervises supervisors and knows how to launch/relaunch 
them.  Failure unlikely.  The OOM killer won't ever see it, right?

It would require a separation in PID1's RC to move supervisable things into the 
other list, or perhaps a way for a PID1 supervisable task to ask for other 
supervision.  Bleah, this could be more clearly expressed :-)

Peter Olson
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 12:16:03PM -0400, Steve Litt wrote:

[cut]

> 
> Hi KatolaZ,
> 
> The preceding paragraph represents a philosophy more than anything
> else. It's the philosophy that your computer must never, ever, for any
> reason ever become unresponsive. You share that philosophy with Laurent
> Bercot, the developer of the s6 (and s6-rc) init systems. He built s6
> such that pid1 can always respawn more stuff: The supervisor is in PID1.
>

Hi Steve,

please don't let me say things that I have not said. I don't share
that philosophy, at all. To be precise, I have said that in 99.%
of the cases supervision is just *useless*. I simply can't see the
point for it.

For those cases in which supervision *really* matters, and I mean,
where a failing process means damage to device, people, experiments,
buildings, etc.  then the only sensible thing is to not use unix, at
all, since it does not have a safe way of providing supervision. If
you *must* to use unix for those critical tasks, then most of the
supervision *has* to be done by pid1.

The rest of your email has been cut out, since it was based on the
assumptions that I actually need a supervisor, which is false, and
that I need help to find a good one, which does not make sense since
the former one is false :)

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Fri, 16 Sep 2016 12:15:01 +0100
KatolaZ  wrote:

> On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:
> 
> [cut]
> 
> > 
> > Steve,
> > 
> > I like more and more this idea of separating the tasks:
> >  - pid1 (sysvinit or whatever) performs one-shot startups and
> > basic supervision (like for getty),
> >  - services needing a sophisticated supervisor use a supervisor
> > which is only a supervisor, not pid1,
> >  - services which depend on conditions use specialized tools to
> > wait for these conditions.
> >   
> 
> That looks like a great plan, but who will supervise the supervisors?
> :)
> 
> I admit this might seem like a stupid comment, at least at first
> sight, but whenever you introduce a supervision system under unix you
> most probably end up deciding that the supervision should be delegated
> to pid1, since pid1 is the only process able to guarantee that
> supervision will be working, whatever happens.

Hi KatolaZ,

The preceding paragraph represents a philosophy more than anything
else. It's the philosophy that your computer must never, ever, for any
reason ever become unresponsive. You share that philosophy with Laurent
Bercot, the developer of the s6 (and s6-rc) init systems. He built s6
such that pid1 can always respawn more stuff: The supervisor is in PID1.

I don't share this philosophy. I've never had it happen to me, but if
somehow my (non-pid1) supervisor ever dies and I don't have a terminal
on which to rerun it, then PID1 is unreachable, and I have to either
Ctrl+Alt+Del (if it's enabled and I set up PID1 to do the proper thing
with that interrupt), or power cycle the computer. These occur so
rarely that I'm not at all concerned about them.

So instead of using a product like s6, which has a more complex PID1
that does supervision, I use runit or Suckless Init plus
daemontools-encore plus LittKit or whatever, to obtain the tiniest
possible PID1.

It's funny. Both runit and s6 are inspired by daemontools. Both have
similar syntaxes, and if you can get along in one, you can more or less
get along in the other. Like Spanish and Italian. But they address two
different philosophies.

Anyway, your question about who supervises the supervisors to me
indicates your need for s6. And I'm pretty sure that the new s6-rc
can intermix both respawned and oneshot processes. I've used s6 only a
few times, but my impression is it's the Cadillac of the industry. I
don't have the time to make an s6/s6-rc package, but it would be a cool
addition,  assuming it doesn't uninstall the other init systems
installed on the machine.

By the way, s6 and s6-rc appear to be undergoing some pretty heavy
development. Their documentation pages include much more than they did
a year ago.

http://skarnet.org/software/s6-rc/

http://skarnet.org/software/s6/
 
SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 03:51:43PM +0200, Didier Kryn wrote:

[cut]

> Nobody supervises pid1, OK? So why would the supervisor need to be
> supervised? It is supposed to be rock solid. Note that it can be barely
> relaunched by sysvinit in the same way as getty.
> 

Yep, but if a supervisor dies, all his children will be orphaned, and
even if init respawns the supervisor, this might not imply that all
the supervisor's children are respawn :)

I personally don't care at all about supervision systems, since I find
them completely useless in most of the common applications. I have
written a couple of custom ones, back in the days, but just for really
mission-critical stuff, where a process failing to do something meant
potentially damaging costly devices. And in that case the most logical
thing to do was to have part of the supervision managed by pid1.

But I am sure that 99.% of the users do not need supervisors in
99.% of the cases...

HND

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Didier Kryn]

Le 16/09/2016 13:15, KatolaZ a écrit :

On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:

[cut]


 Steve,

 I like more and more this idea of separating the tasks:
  - pid1 (sysvinit or whatever) performs one-shot startups and basic
supervision (like for getty),
  - services needing a sophisticated supervisor use a supervisor which is
only a supervisor, not pid1,
  - services which depend on conditions use specialized tools to wait for
these conditions.


That looks like a great plan, but who will supervise the supervisors?
:)

I admit this might seem like a stupid comment, at least at first
sight, but whenever you introduce a supervision system under unix you
most probably end up deciding that the supervision should be delegated
to pid1, since pid1 is the only process able to guarantee that
supervision will be working, whatever happens.
Nobody supervises pid1, OK? So why would the supervisor need to be 
supervised? It is supposed to be rock solid. Note that it can be barely 
relaunched by sysvinit in the same way as getty.


Didier


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Dr. Nikolaus Klepp]

Am Freitag, 16. September 2016 schrieb KatolaZ:
> That looks like a great plan, but who will supervise the supervisors?
> :)
The NSA .. or BND ... . If you don't have something to hide, then you have 
nothing to fear ;-)



-- 
Please do not email me anything that you are not comfortable also sharing with 
the NSA.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[KatolaZ]

On Fri, Sep 16, 2016 at 12:24:45PM +0200, Didier Kryn wrote:

[cut]

> 
> Steve,
> 
> I like more and more this idea of separating the tasks:
>  - pid1 (sysvinit or whatever) performs one-shot startups and basic
> supervision (like for getty),
>  - services needing a sophisticated supervisor use a supervisor which is
> only a supervisor, not pid1,
>  - services which depend on conditions use specialized tools to wait for
> these conditions.
> 

That looks like a great plan, but who will supervise the supervisors?
:)

I admit this might seem like a stupid comment, at least at first
sight, but whenever you introduce a supervision system under unix you
most probably end up deciding that the supervision should be delegated
to pid1, since pid1 is the only process able to guarantee that
supervision will be working, whatever happens.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - GLUGCT -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Didier Kryn]

Le 16/09/2016 12:02, Steve Litt a écrit :

On Thu, 15 Sep 2016 12:31:28 -1000
Joel Roth  wrote:


emnin...@riseup.net wrote:

Am Mon, 12 Sep 2016 08:31:54 +
schrieb Jaromil :
   

not at all. We even plan to roll out our own openrc package,
ditching the one from Debian which has many problems. Perhaps
what you are hitting is one of them.

For Devuan's Openrc we will follow the design proposed by
upstream and Gentoo's, the maintainer volunteering for this is
Parazyd (also on this list) who works with us at Dyne.org. We
will also use Openrc in our projects and are advocating for it as
the next new standard in Devuan ascii, at the condition of a 100%
smooth transition from sysvinit.

At last, we haven't done anything on the OpenRC package yet so
your problems are entirely caused by the Debian maintainership,
which can't be trusted at all, IMHO

Thanks a lot Jaromil for the info.

It's not - by chance ;) - i could
pickup from somewhere a beta of the OpenRC package you're working
on?

I hate the idea to redo several scripts (i - painfully ;) adapted
from Gentoo to the previous deb version to make them work with the
debian crippeled openrc) to make them goable for sysvinit.

In any case, me for one (simple user!), i like a lot the idea to
use the original gentoo style openrc - and i like openrc for its
ease to use.

I'll be interested how this work goes. If I understand
correctly, system startup with Devuanized openrc will be
totally handled for the user, the way it is with sysvinit
now.

To that extent, I'm sure openrc will offer "ease of use",
however going by  the feature set and documentation, openrc
aims at a more comprehensive offering (from
https://en.wikipedia.org/wiki/OpenRC):

 Parallel service startup (optional, in development)[3]
 Process segregation through cgroups
 Per-service resource limits (ulimit)
 Separation of code and configuration (init.d / conf.d)
 Ability to include an unlimited variety of commands beyond basic
"start, stop, and status" Stateful init scripts (is it started
already?) Complex init scripts to start multiple components (Samba
(smbd and nmbd), NFS (nfsd, portmap, etc.)) Automatic dependency
calculation and service ordering Proper integration into
container/virtualization (Linux-VServer, OpenVZ, etc.)[4] Proper
modular architecture and separation of optional components (Cron,
syslog) Expressive and flexible network handling (including VPN,
bridges, etc.) Support for bare-metal bare-dependency servers[5][6]

OOTB support for Samba and NFS (along with being Devuan
default) will definitely win users.

The preceding list looks a heck of a lot like the exact feature list of
systemd. What a feather in our cap if that turns out to be true.

As far as OpenRC's inability to respawn, respawnable apps can be
handled partly by a sysvinit PID1, and partially by running
daemontools-encore, runit or s6 as a daemon spawned by OpenRC.




Steve,

I like more and more this idea of separating the tasks:
 - pid1 (sysvinit or whatever) performs one-shot startups and basic 
supervision (like for getty),
 - services needing a sophisticated supervisor use a supervisor 
which is only a supervisor, not pid1,
 - services which depend on conditions use specialized tools to 
wait for these conditions.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Thu, 15 Sep 2016 12:31:28 -1000
Joel Roth  wrote:

> emnin...@riseup.net wrote:
> > Am Mon, 12 Sep 2016 08:31:54 +
> > schrieb Jaromil :
> >   
> > > not at all. We even plan to roll out our own openrc package,
> > > ditching the one from Debian which has many problems. Perhaps
> > > what you are hitting is one of them.
> > > 
> > > For Devuan's Openrc we will follow the design proposed by
> > > upstream and Gentoo's, the maintainer volunteering for this is
> > > Parazyd (also on this list) who works with us at Dyne.org. We
> > > will also use Openrc in our projects and are advocating for it as
> > > the next new standard in Devuan ascii, at the condition of a 100%
> > > smooth transition from sysvinit.
> > > 
> > > At last, we haven't done anything on the OpenRC package yet so
> > > your problems are entirely caused by the Debian maintainership,
> > > which can't be trusted at all, IMHO  
> > 
> > Thanks a lot Jaromil for the info. 
> > 
> > It's not - by chance ;) - i could
> > pickup from somewhere a beta of the OpenRC package you're working
> > on?
> > 
> > I hate the idea to redo several scripts (i - painfully ;) adapted
> > from Gentoo to the previous deb version to make them work with the
> > debian crippeled openrc) to make them goable for sysvinit.
> > 
> > In any case, me for one (simple user!), i like a lot the idea to
> > use the original gentoo style openrc - and i like openrc for its
> > ease to use.  
> 
> I'll be interested how this work goes. If I understand
> correctly, system startup with Devuanized openrc will be
> totally handled for the user, the way it is with sysvinit
> now.
> 
> To that extent, I'm sure openrc will offer "ease of use",
> however going by  the feature set and documentation, openrc
> aims at a more comprehensive offering (from
> https://en.wikipedia.org/wiki/OpenRC):
> 
> Parallel service startup (optional, in development)[3]
> Process segregation through cgroups
> Per-service resource limits (ulimit)
> Separation of code and configuration (init.d / conf.d)
> Ability to include an unlimited variety of commands beyond basic
> "start, stop, and status" Stateful init scripts (is it started
> already?) Complex init scripts to start multiple components (Samba
> (smbd and nmbd), NFS (nfsd, portmap, etc.)) Automatic dependency
> calculation and service ordering Proper integration into
> container/virtualization (Linux-VServer, OpenVZ, etc.)[4] Proper
> modular architecture and separation of optional components (Cron,
> syslog) Expressive and flexible network handling (including VPN,
> bridges, etc.) Support for bare-metal bare-dependency servers[5][6]
> 
> OOTB support for Samba and NFS (along with being Devuan
> default) will definitely win users. 

The preceding list looks a heck of a lot like the exact feature list of
systemd. What a feather in our cap if that turns out to be true.

As far as OpenRC's inability to respawn, respawnable apps can be
handled partly by a sysvinit PID1, and partially by running
daemontools-encore, runit or s6 as a daemon spawned by OpenRC.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Joel Roth]

emnin...@riseup.net wrote:
> Am Mon, 12 Sep 2016 08:31:54 +
> schrieb Jaromil :
> 
> > not at all. We even plan to roll out our own openrc package, ditching
> > the one from Debian which has many problems. Perhaps what you are
> > hitting is one of them.
> > 
> > For Devuan's Openrc we will follow the design proposed by upstream and
> > Gentoo's, the maintainer volunteering for this is Parazyd (also on
> > this list) who works with us at Dyne.org. We will also use Openrc in
> > our projects and are advocating for it as the next new standard in
> > Devuan ascii, at the condition of a 100% smooth transition from
> > sysvinit.
> > 
> > At last, we haven't done anything on the OpenRC package yet so your
> > problems are entirely caused by the Debian maintainership, which can't
> > be trusted at all, IMHO
> 
> Thanks a lot Jaromil for the info. 
> 
> It's not - by chance ;) - i could
> pickup from somewhere a beta of the OpenRC package you're working on?
> 
> I hate the idea to redo several scripts (i - painfully ;) adapted from
> Gentoo to the previous deb version to make them work with the debian
> crippeled openrc) to make them goable for sysvinit.
> 
> In any case, me for one (simple user!), i like a lot the idea to use the
> original gentoo style openrc - and i like openrc for its ease to use.

I'll be interested how this work goes. If I understand
correctly, system startup with Devuanized openrc will be
totally handled for the user, the way it is with sysvinit
now.

To that extent, I'm sure openrc will offer "ease of use",
however going by  the feature set and documentation, openrc
aims at a more comprehensive offering (from 
https://en.wikipedia.org/wiki/OpenRC):

Parallel service startup (optional, in development)[3]
Process segregation through cgroups
Per-service resource limits (ulimit)
Separation of code and configuration (init.d / conf.d)
Ability to include an unlimited variety of commands beyond basic "start, 
stop, and status"
Stateful init scripts (is it started already?)
Complex init scripts to start multiple components (Samba (smbd and nmbd), 
NFS (nfsd, portmap, etc.))
Automatic dependency calculation and service ordering
Proper integration into container/virtualization (Linux-VServer, OpenVZ, 
etc.)[4]
Proper modular architecture and separation of optional components (Cron, 
syslog)
Expressive and flexible network handling (including VPN, bridges, etc.)
Support for bare-metal bare-dependency servers[5][6]

OOTB support for Samba and NFS (along with being Devuan
default) will definitely win users. 

All that is ease of use, but technically speaking, runit
is much simpler and less to master.


> Cheers!

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[emninger]

Am Mon, 12 Sep 2016 08:31:54 +
schrieb Jaromil :

> not at all. We even plan to roll out our own openrc package, ditching
> the one from Debian which has many problems. Perhaps what you are
> hitting is one of them.
> 
> 
> For Devuan's Openrc we will follow the design proposed by upstream and
> Gentoo's, the maintainer volunteering for this is Parazyd (also on
> this list) who works with us at Dyne.org. We will also use Openrc in
> our projects and are advocating for it as the next new standard in
> Devuan ascii, at the condition of a 100% smooth transition from
> sysvinit.
> 
> At last, we haven't done anything on the OpenRC package yet so your
> problems are entirely caused by the Debian maintainership, which can't
> be trusted at all, IMHO

Thanks a lot Jaromil for the info. 

It's not - by chance ;) - i could
pickup from somewhere a beta of the OpenRC package you're working on?

I hate the idea to redo several scripts (i - painfully ;) adapted from
Gentoo to the previous deb version to make them work with the debian
crippeled openrc) to make them goable for sysvinit.

In any case, me for one (simple user!), i like a lot the idea to use the
original gentoo style openrc - and i like openrc for its ease to use.

Cheers!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Fred DC]

On 12/09/2016 10:32, Jaromil wrote:
> ...
> 
> (the above space is left intentionally blank for conspiracy theorists)
> 
> Openrc in Debian coul be labeled as a "self hating package",
> I recommend you compile from source until we provide an openrc
> package.

The same could be said regarding the 'runit-package'. I got bitten!
On Steve Litt's advice I compiled it now from source and I feel a lot
better now.

BTW, I  left sysvinit-core as is - but I diverted some of the
sysvinit-scripts and replaced them with a home-grown stub which checks
what is running as Pid 1 (and a bit more) and based on the result it either
calls the diverted script or uses the "runit-speak". This way it does
not matter if during an debian-upgrade runit-init or sysv-init is Pid 1.

Regards

Fred

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Jaromil]

On Sun, 11 Sep 2016, emnin...@riseup.net wrote:

> Am Sun, 11 Sep 2016 18:09:56 +0200
> schrieb Svante Signell :
> 
> > Maybe you have to install sys-rc before installing openrc?
> 
> I looked and i have already installed sysv-rc. In any case, i did a
> re-install but it did not help.
> 
> Does that mean openrc as an option for devuan is gone?

not at all. We even plan to roll out our own openrc package, ditching
the one from Debian which has many problems. Perhaps what you are
hitting is one of them.


For Devuan's Openrc we will follow the design proposed by upstream and
Gentoo's, the maintainer volunteering for this is Parazyd (also on
this list) who works with us at Dyne.org. We will also use Openrc in
our projects and are advocating for it as the next new standard in
Devuan ascii, at the condition of a 100% smooth transition from
sysvinit.

At last, we haven't done anything on the OpenRC package yet so your
problems are entirely caused by the Debian maintainership, which can't
be trusted at all, IMHO






(the above space is left intentionally blank for conspiracy theorists)

Openrc in Debian coul be labeled as a "self hating package",
I recommend you compile from source until we provide an openrc
package.

ciao



___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Rick Moen]

Quoting emnin...@riseup.net (emnin...@riseup.net):

> I was away from the keyboard a very long time (had to work
> outside/outdoor for a life), so very likely i missed a lot. Sorry in
> anticipation if i'm doubling something:
> 
> One system is/was running devuan ascii quite nicely but when i came
> back i did an 'apt-get update && apt-get dist-upgrade' and i
> realize(d), that openrc (which i was used to use) was removed. When i
> try to reinstall openrc, i see that nearly the complete system would be
> removed 

I suggest you investigate what within this package's metadata causes that
proposed removal.  E.g., what the Conflicts, Depends, Provides, etc.
lines are.  You should have access to this data, whereas (speaking for
myself, at least) the rest of us don't even know what version you're
seeking to install.

I spent a few minutes looking at
https://packages.devuan.org/devuan/dists/*.Packages.gz files trying to
get that information, but didn't find it.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Svante Signell]

On Sun, 2016-09-11 at 23:41 +0200, emnin...@riseup.net wrote:
> Am Sun, 11 Sep 2016 18:09:56 +0200
> schrieb Svante Signell :
> 
> > 
> > Maybe you have to install sys-rc before installing openrc?
> 
> The version is 0.21-2.
> 
> Do you mean sysv-rc or sys-rc indeed?

Yes, of course i meant sysv-rc :)
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[emninger]

Am Sun, 11 Sep 2016 18:09:56 +0200
schrieb Svante Signell :

> Maybe you have to install sys-rc before installing openrc?

I looked and i have already installed sysv-rc. In any case, i did a
re-install but it did not help.

Does that mean openrc as an option for devuan is gone?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[emninger]

Am Sun, 11 Sep 2016 18:09:56 +0200
schrieb Svante Signell :

> On Sun, 2016-09-11 at 17:44 +0200, emnin...@riseup.net wrote:
> > I was away from the keyboard a very long time (had to work
> > outside/outdoor for a life), so very likely i missed a lot. Sorry in
> > anticipation if i'm doubling something:
> > 
> > One system is/was running devuan ascii quite nicely but when i came
> > back i did an 'apt-get update && apt-get dist-upgrade' and i
> > realize(d), that openrc (which i was used to use) was removed. When
> > i try to reinstall openrc, i see that nearly the complete system
> > would be
> > removed   
> 
> Which version did you have/are you trying to install?
> From the 0.21-2 debian changelog:
> openrc (0.21-2) unstable; urgency=medium
> 
>   * Move Recommends init-system-helpers to Pre-Depend (Closes:
> 829488).
>   * Drop Provides sysv-rc.
>   * Install transit into /etc/init.d directly.
> 
> Maybe you have to install sys-rc before installing openrc?

The version is 0.21-2.

Do you mean sysv-rc or sys-rc indeed?

Thanks a lot!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Steve Litt]

On Sun, 11 Sep 2016 17:44:19 +0200
 wrote:

> One system is/was running devuan ascii quite nicely but when i came
> back i did an 'apt-get update && apt-get dist-upgrade' and i
> realize(d), that openrc (which i was used to use) was removed.

[snip]
> 
> Anyway, any pointer will be highly welcome!

The following advice is completely unresponsive to your question, but
is perhaps tangentially related...

Have you tried initting with runit instead of openrc (or sysvinit)?

OpenRC is so big and complex that it's best installed with a package,
and it seems like init packages like to de-install their competitors
the way new alpha-male lions kill the cubs of their predecessors. 

Runit is extremely simple: Simple enough to easily install,
sans-package, straight from the "upstream's" website. Doing this gives
you a parallel Runit/sysvinit init choice, simply by changing the init
section of the kernel line in grub.cfg.

I personally think that Runit is better than OpenRC and sysvinit, which
of course are in turn much better than systemd. Of course, I'm
prejudiced: I'm a huge fan of djb's daemontools software and everything
influenced by it.

If you're *not* a daemontools fanatic like I am, another init system
you might want to try is Epoch: 

* https://universe2.us/epoch.html
* https://github.com/Subsentient/epoch

Epoch is probably the easiest init system to install and configure. I
used it experimentally about 18 months ago, and it's excellent. 

So, if you refuse to use systemd, but you're not a huge fan of sysvinit
either, then if OpenRC doesn't attract you with specific features,
initting with runit or Epoch might be easier for you to achieve.

SteveT

Steve Litt 
September 2016 featured book: Twenty Eight Tales of Troubleshooting
http://www.troubleshooters.com/28


___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Openrc

[Svante Signell]

On Sun, 2016-09-11 at 17:44 +0200, emnin...@riseup.net wrote:
> I was away from the keyboard a very long time (had to work
> outside/outdoor for a life), so very likely i missed a lot. Sorry in
> anticipation if i'm doubling something:
> 
> One system is/was running devuan ascii quite nicely but when i came
> back i did an 'apt-get update && apt-get dist-upgrade' and i
> realize(d), that openrc (which i was used to use) was removed. When i
> try to reinstall openrc, i see that nearly the complete system would
> be
> removed 

Which version did you have/are you trying to install?
From the 0.21-2 debian changelog:
openrc (0.21-2) unstable; urgency=medium

  * Move Recommends init-system-helpers to Pre-Depend (Closes: 829488).
  * Drop Provides sysv-rc.
  * Install transit into /etc/init.d directly.

Maybe you have to install sys-rc before installing openrc?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] Openrc

[emninger]

I was away from the keyboard a very long time (had to work
outside/outdoor for a life), so very likely i missed a lot. Sorry in
anticipation if i'm doubling something:

One system is/was running devuan ascii quite nicely but when i came
back i did an 'apt-get update && apt-get dist-upgrade' and i
realize(d), that openrc (which i was used to use) was removed. When i
try to reinstall openrc, i see that nearly the complete system would be
removed 

alsa-firmware-loaders bluetooth bluez bumblebee ceni clamav
clamav-daemon clamav-freshclam clamav-milter clamav-unofficial-sigs
clamsmtp clamtk cups cups-browsed cups-core-drivers cups-daemon
gnumeric gnumeric-plugins-extra hplip init initramfs-tools
initramfs-tools-core initscripts inxi kodi kodi-bin kodi-data
linux-image-4.6-4.dmz.2-liquorix-amd64 linux-image-4.6.0-1-amd64
linux-image-4.7.0-3.1-liquorix-amd64 primus printer-driver-gutenprint
printer-driver-hpcups printer-driver-postscript-hp printer-driver-splix
procps sane-utils sysv-rc sysvinit sysvinit-core task-print-server udev
virtualbox virtualbox-ext-pack virtualbox-guest-x11 virtualbox-qt xorg
xserver-xorg xserver-xorg-core xserver-xorg-input-all
xserver-xorg-input-evdev xserver-xorg-input-libinput
xserver-xorg-input-mouse xserver-xorg-input-synaptics
xserver-xorg-input-vmmouse xserver-xorg-video-all
xserver-xorg-video-amdgpu xserver-xorg-video-ati
xserver-xorg-video-cirrus xserver-xorg-video-fbdev
xserver-xorg-video-intel xserver-xorg-video-mach64
xserver-xorg-video-mga xserver-xorg-video-neomagic
xserver-xorg-video-nouveau xserver-xorg-video-openchrome
xserver-xorg-video-r128 xserver-xorg-video-radeon
xserver-xorg-video-savage xserver-xorg-video-sisusb
xserver-xorg-video-tdfx xserver-xorg-video-trident
xserver-xorg-video-vesa xserver-xorg-video-vmware Die folgenden NEUEN
Pakete werden installiert: libeinfo1 librc1 makedev openrc WARNUNG: Die
folgenden essentiellen Pakete werden entfernt. Dies sollte NICHT
geschehen, außer Sie wissen genau, was Sie tun! init sysvinit-core
(wegen init)
---

BTW, this is the same with the option --no-install-recommends

When i installed openrc time ago, installation was smooth and i did not
have any of this problems. Did devuan became incompatible with openrc
in the meantime?

A small, side problem, i will have to solve in the next future: My
zram-init script does not work anymore. May be it's why i installed it
under openrc?

Anyway, any pointer will be highly welcome!

Thanks a lot in advance!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC: Was: Re: Dng Digest, Vol 20, Issue 138

[Steve Litt]

On Thu, 26 May 2016 12:50:19 +0200
Svante Signell  wrote:

> On Thu, 2016-05-26 at 11:28 +0200, emnin...@riseup.net wrote:
> 
> Please keep the subject, even if you are reading the mails via the
> Digest service!

In addition, if you respond to a digest subjected email, please change
the subject back to the original, like Svante just did. If that's too
much trouble, just don't reply. My opinion: if somebody isn't willing to
take the time to MAKE ABSOLUTELY SURE he has the right subject, he
doesn't deserve a reply.

I think the "convenience" of getting email via digest implies the
*responsibility* of the extra work in fixing the subject and deleting
all extraneous body. That's why I never use a digest: by the time you
do what's right, it's not convenient anymore.
 
SteveT

Steve Litt 
May 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC

[Steve Litt]

On Thu, 26 May 2016 01:53:07 +0200
Dragan FOSS  wrote:

> On 05/26/2016 01:23 AM, Steve Litt wrote:
> > capability of respawning daemons that crash? OpenRC can't do that.  
> 
> OpenRC *can* do that:
> 
> ---
> Automatic respawning crashed services
> ---
> 
> https://wiki.gentoo.org/wiki/OpenRC


Thanks Dragan FOSS!

I've been saying that OpenRC can't respawn ever since the people on
Freenode's #openrc answered my question "How do you respawn in OpenRC
rather than sysvinit's inittab?" with "You can't and you wouldn't want
to." I've been saying this for a year, and nobody ever said "oh yes you
can" til you just did.

So I'll need to quit saying that until I can lay down Manjaro-OpenRC on
a VM, do what the link you supplied says to do, and try it myself. At
which time I'll either continue saying it, or issue a whole bunch of
retractions.

Thanks,
 
SteveT

Steve Litt 
May 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC: Was: Re: Dng Digest, Vol 20, Issue 138

[emninger]

Am Thu, 26 May 2016 12:50:19 +0200
schrieb Svante Signell :

> On Thu, 2016-05-26 at 11:28 +0200, emnin...@riseup.net wrote:
> 
> Please keep the subject, even if you are reading the mails via the
> Digest service!

You're right! Sorry about that, i was too fast :-( Btw, could that be
corrected ex post, by the administrator(s)? 

Eventually bringing back the correct subjectline or simply by bouncing
back the entire mail (with a reason) giving the chance to the author to
correct the subjectline?
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] OpenRC: Was: Re: Dng Digest, Vol 20, Issue 138

[Svante Signell]

On Thu, 2016-05-26 at 11:28 +0200, emnin...@riseup.net wrote:

Please keep the subject, even if you are reading the mails via the
Digest service!
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC

[Didier Kryn]

Le 26/05/2016 01:23, Steve Litt a écrit :

Many people feel that respawning is a pact with the devil: If something
crashes, it should stay crashed for further investigation rather than
"painting over it" with a respawn. If you feel that way, OpenRC is a
good bet.


The arguments pro and cons are all sensible. I think the good 
decision depends on the case.


I'm the admin of a dozen servers in a remote site visited one day 
every two weeks by people with no computing expertise. I would like the 
ssh servers be supervised. In general I think the syslog server should 
be supervised as well. Of course I don't want the ssh server to be 
supervised on my laptop  - in particular because I know how to restart it.


Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC

[Dragan FOSS]

On 05/26/2016 01:23 AM, Steve Litt wrote:

capability of respawning daemons that crash? OpenRC can't do that.


OpenRC *can* do that:

---
Automatic respawning crashed services
---

https://wiki.gentoo.org/wiki/OpenRC

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC

[Steve Litt]

On Tue, 24 May 2016 14:06:33 +0200
 wrote:

> Is there a link to an instruction how to use (and setup) openrc
> together with sysvinit? 
> 
> I'd like to use openrc as a tool to administrate daemons and services
> since i find it a lot more "logical" (easy?). 

Before you do this, allow me to ask you this question: Do you want the
capability of respawning daemons that crash? OpenRC can't do that. If
you prefer respawning, consider using s3, daemontools-encore or even
Runit to manage your daemons.

Many people feel that respawning is a pact with the devil: If something
crashes, it should stay crashed for further investigation rather than
"painting over it" with a respawn. If you feel that way, OpenRC is a
good bet. 

SteveT

Steve Litt 
May 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC

[Dragan FOSS]

On 05/24/2016 02:06 PM, emnin...@riseup.net wrote:

Is there a link to an instruction how to use (and setup) openrc
together with sysvinit?

I'd like to use openrc as a tool to administrate daemons and services
since i find it a lot more "logical" (easy?).



TRIOS Mia is fully functional Debian jessie-based distro with OpenRC, 
Eudev, Refind UEFI manager, ZFS support, systemd completely removed...


Desktop environments: Xfce, Gnome3, Mate, Cinnamon, Enlightenment, KDE, 
Lumina..


https://foss.rs/threads/trios-mia-openrc-zfs.3057

Enjoy :)

Dragan
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC

[Irrwahn]

On Tue, 24 May 2016 14:06:33 +0200, Emninger wrote:
> Is there a link to an instruction how to use (and setup) openrc
> together with sysvinit? 

DISCLAIMER: I never tried that, so please take my 
suggestions with a buckload of salt. (Corrections welcome!)

Having that out of the way: There is this presumably 
outdated page you might want to have a look at: 
https://wiki.debian.org/OpenRC

> I'd like to use openrc as a tool to administrate daemons and services
> since i find it a lot more "logical" (easy?). One question for example
> is, if can be used the (needed) openrc scripts from other distros (like
> Gentoo or Manjaro)? To form them on my one, i think that's far away
> from my capabilities ...

AIUI, OpenRC uses the same RC scripts as does SysV-RC. 

However, if _I_ were to tinker with that, I'd first try 
it in a virtual machine. The risks to end up with an 
unbootable system are IMHO to high to mess with a 
"production machine"[1][2]. Plus, VMs are much faster 
in rebooting, and much easier to restore to a working 
state (think snapshots).

[1] In the broadest sense of the term.

[2] Just because there is by now already a variety of 
preliminary Devuan live images (BTW, thanks aitor, fsr, 
KatolaZ, et al.!), is not necessarily a sound reason to 
test drive them as a recovery option for a botched up 
system.

Regards
Urban


 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

[DNG] OpenRC

[emninger]

Is there a link to an instruction how to use (and setup) openrc
together with sysvinit? 

I'd like to use openrc as a tool to administrate daemons and services
since i find it a lot more "logical" (easy?). One question for example
is, if can be used the (needed) openrc scripts from other distros (like
Gentoo or Manjaro)? To form them on my one, i think that's far away
from my capabilities ...
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Didier Kryn]

Le 04/05/2016 15:44, Rob Owens a écrit :

- Original Message -

From: "Didier Kryn" 
Le 03/05/2016 19:10, Rob Owens a écrit :

Yes, but then when an openrc user wants to start/stop a service, he
cannot do '/etc/init.d/myservice start' like he could do on any other
OS using openrc.  He'd have to do '/etc/openrc/myservice start'.  Not a
really big deal, but I think it's undesirable to make Devuan's openrc
procedures different (especially when it could be addressed with a
simple symlink).

 Normally the admin invokes the service command,

 sudo service ssh restart
 sudo service nginx status

 etc.

 service could probably be modified to talk to the init system in
charge.

Normally *this* admin never uses the service command because:
I always use it. With some experience you know the service names as 
well as the basic Unix command names.


1) it is not available on all distros or may not be installed


Talking of Debian/Devuan

2) tab completion doesn't always work with the service command (depending
on the distro, I suppose)
3) tab completion always works when you specify the path to the script
and you are running a bash shell

Is the service called 'smb' or 'samba'?  Is it 'network' or 'networking'?
That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.


Bash tab completion does work - I agree it's rather sophisticated.

Didier

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

upstart is init subsystem which is using same names for binaries; commands
as sysvinit probably to be a drop in replacement, not ment to coexist with
sysvinit.

sysv-rc,openrc , file-rc all depend on init binary daemon and are
replacements for init.d/rc(S) files which init binary executes. so they
also cannot coexist.

so openrc is not an init subsystem on its own.

deamontools  are IMHO helpers for broken software like java application
which cannot daemonize itself under unix becaouse of java desing. trying to
convince people that writing unix daemons the old way is badthing(tm).

maybe i should go back to sls.
--
regards
piotr
04-05-2016 18:49, "Steve Litt"  napisał(a):

> On Wed, 4 May 2016 09:54:37 -0400 (EDT)
> Rob Owens  wrote:
>
> > - Original Message -
> > > From: "Steve Litt" 
> >
> > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > > Rob Owens  wrote:
> > >
> > >> I agree with putting each init in its own directory, but sysvinit
> > >> should not own /etc/init.d.  sysvinit stuff should go
> > >> in /etc/sysvinit and by default /etc/init.d should be a link
> > >> to /etc/sysvinit/init.d. The reason is that other init systems may
> > >> expect to own /etc/init.d. For instance, openrc puts all its
> > >> scripts in /etc/init.d (at least on Funtoo it does).
> > >
> > > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > > and the only one I know that wants to do that is systemd.
> > >
> > > I wouldn't change sysvinit's expected files one little bit. Everyone
> > > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > > change to sysvinit would require lots of testing, and who needs
> > > that headache?
>
> > Then you would be designing under the assumption that sysvinit is the
> > "one true way"
>
> Not "one true way", but "it's what we have right now, let's not mess
> with it.
>
> > and that all others must be modified to work around
> > sysvinit -- an init system that you/we are actively attempting to make
> > obsolete (eventually) by way of providing all these alternatives.
>
> The other inits should have had the good sense not to entangle
> themselves with sysvinit, and in fact most of them did have that good
> sense, so for them this is a moot point.
>
> At this point I'm not sure that *any* init system other than sysvinit
> puts its daemon starting code/config under /etc/init.d. But if there is
> such an init system putting its stuff under/etc/init.d, that's some
> serious hubris. They could have taken their own namespace, but no,
> they polluted the namespace used by sysvinit for 30 years. If there is
> such an init system, moving their script/config storage is actually
> correcting a problem caused by the init system.
>
> SteveT
>
> Steve Litt
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Wed, 4 May 2016 09:54:37 -0400 (EDT)
Rob Owens  wrote:

> - Original Message -
> > From: "Steve Litt"   
> 
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > Rob Owens  wrote:
> >   
> >> I agree with putting each init in its own directory, but sysvinit
> >> should not own /etc/init.d.  sysvinit stuff should go
> >> in /etc/sysvinit and by default /etc/init.d should be a link
> >> to /etc/sysvinit/init.d. The reason is that other init systems may
> >> expect to own /etc/init.d. For instance, openrc puts all its
> >> scripts in /etc/init.d (at least on Funtoo it does).  
> > 
> > I don't remember any other init wanting to use /etc/init.d, EXCEPT
> > OpenRC, or EXCEPT when they want to use the sysvinit init scripts,
> > and the only one I know that wants to do that is systemd.
> > 
> > I wouldn't change sysvinit's expected files one little bit. Everyone
> > assumes that /etc/init.d belongs exclusively to sysvinit. Any
> > change to sysvinit would require lots of testing, and who needs
> > that headache? 

> Then you would be designing under the assumption that sysvinit is the
> "one true way" 

Not "one true way", but "it's what we have right now, let's not mess
with it.

> and that all others must be modified to work around
> sysvinit -- an init system that you/we are actively attempting to make
> obsolete (eventually) by way of providing all these alternatives.

The other inits should have had the good sense not to entangle
themselves with sysvinit, and in fact most of them did have that good
sense, so for them this is a moot point.

At this point I'm not sure that *any* init system other than sysvinit
puts its daemon starting code/config under /etc/init.d. But if there is
such an init system putting its stuff under/etc/init.d, that's some
serious hubris. They could have taken their own namespace, but no,
they polluted the namespace used by sysvinit for 30 years. If there is
such an init system, moving their script/config storage is actually
correcting a problem caused by the init system.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[poitr pogo]

If I had to be and admin of mixture of linux distributions I would
probably use 'service', instead of remembering all commands suited for
different init flavours and checking on which box I'm about to run a
command.

But in such a case I probably would not care what kind of init
subsystem is running on my box. I would not wait for Devuan to get
something with sysvinit.

So if I'm stick to sysvinit why I am to use 'service'? Why learn
another wrapper name which does one thing more if I can always do

env /etc/init.d/blabla start

If I want to have clean environment when starting this script.

But I cannot imagine why should I even use 'env' command (in ideal
world). The init script should use it if it is important that the
environment is cleaned up before starting the application daemon ( or
service if you want to call it this way). This is responsibility of
application maintainer to provide 'idiot proof' starting script.  The
assumption that 'service' command will prepare environment is IMHO  a
mistake, cause the init script _can_ be executed directly as it was
done for a long time, before 'service' command was introduced.

Yes, I think it was bad design decision to make 'service' command to
cleanup environment, not leaving this task to  init script, because of
legacy of /etc/init.d , and because the init.d scripts  can be
executed directly anyway.

If 'service' command  was running scripts from other
folder/schema/subsystem, but not from well known /etc/init.d, than I
would say I should obey the rules of the new command, once decided i
want to use it.

So, please make the system suit your needs, but do not assume what are mine. :)

--
regards
piotr
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Stephan Seitz]

On Wed, May 04, 2016 at 09:44:30AM -0400, Rob Owens wrote:

Normally *this* admin never uses the service command because:


You should because the service command cleans the environment. If you do 
„/etc/init.d/ start” you can have strange results.



1) it is not available on all distros or may not be installed


It is available in SLES11 and Debian (since 6?). Which distro doesn’t 
have service?
Besides, as far as I know the service command is independant from the 
init system, so it works with systemd or sysvinit.



2) tab completion doesn't always work with the service command (depending
  on the distro, I suppose)
3) tab completion always works when you specify the path to the script
  and you are running a bash shell


These are valid points. SLES doesn’t have bash completion in 11. IIRC tab 
completion with service works in SLES 12 which uses systemd.
In Debian or debian based distros you have to install bash-completion and 
activate it in /etc/bash.bashrc.



That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.


No, but with bash-completion this works with service in Debian as well.

Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rob Owens]

- Original Message -
> From: "Steve Litt" 

> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> Rob Owens  wrote:
> 
>> I agree with putting each init in its own directory, but sysvinit
>> should not own /etc/init.d.  sysvinit stuff should go in /etc/sysvinit
>> and by default /etc/init.d should be a link to /etc/sysvinit/init.d.
>> The reason is that other init systems may expect to own /etc/init.d.
>> For instance, openrc puts all its scripts in /etc/init.d (at least on
>> Funtoo it does).
> 
> I don't remember any other init wanting to use /etc/init.d, EXCEPT
> OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
> the only one I know that wants to do that is systemd.
> 
> I wouldn't change sysvinit's expected files one little bit. Everyone
> assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
> sysvinit would require lots of testing, and who needs that headache?
> 
Then you would be designing under the assumption that sysvinit is the
"one true way" and that all others must be modified to work around
sysvinit -- an init system that you/we are actively attempting to make
obsolete (eventually) by way of providing all these alternatives.  This 
doesn't make a lick of sense.

>> Even though sysvinit is our default init system these days, we should
>> not design Devuan such that it is difficult to change that in the
>> future.  So put sysvinit stuff in its own directory just like all the
>> other inits.
> 
> If you leave sysvinit's directories exactly as they exist now,
> switching back and forth between sysvinit and runit is trivial. Same is
> true of s6 and Epoch.
> 
It is also trivial to do with a symlink.

> Because OpenRC has seen fit to intermix their init scripts
> with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> OpenRC be kept somewhere besides /etc/init.d.
> 
I have only used openrc on Funtoo, but there is no intermixing with 
sysvinit there.  It is exclusively openrc in /etc/init.d.  Are you using
a distro where /etc/init.d contains both openrc scripts and sysvinit 
scripts?

-Rob
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rainer Weikusat]

Robert Storey  writes:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it. I can't speak
> for anyone else, of course, but I tend to think the sort of people who are
> attracted to Devuan see the virtue of simplicity.

The main attraction of the sysvinit-based system is its simpliciy: While
init has a few features it could do without (eg, process management), it
mostly just invokes (configurable) external programs with certain
arguments in response to system state change requests. By itself, that's
flexible enough to implement anything on top of it (including the
'historically grown' init.d script thicket).
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Rob Owens]

- Original Message -
> From: "Didier Kryn" 

> Le 03/05/2016 19:10, Rob Owens a écrit :
>> Yes, but then when an openrc user wants to start/stop a service, he
>> cannot do '/etc/init.d/myservice start' like he could do on any other
>> OS using openrc.  He'd have to do '/etc/openrc/myservice start'.  Not a
>> really big deal, but I think it's undesirable to make Devuan's openrc
>> procedures different (especially when it could be addressed with a
>> simple symlink).
> Normally the admin invokes the service command,
> 
> sudo service ssh restart
> sudo service nginx status
> 
> etc.
> 
> service could probably be modified to talk to the init system in
> charge.

Normally *this* admin never uses the service command because:

1) it is not available on all distros or may not be installed
2) tab completion doesn't always work with the service command (depending
   on the distro, I suppose)
3) tab completion always works when you specify the path to the script
   and you are running a bash shell

Is the service called 'smb' or 'samba'?  Is it 'network' or 'networking'?
That's why tab completion is important to me.  I'm surprised that I seem
to be the only one who thinks this way.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Hendrik Boom]

On Wed, May 04, 2016 at 08:10:40AM +0100, Simon Hobson wrote:
> Steve Litt  wrote:
> 
> > There's a special place in hell for people using ambiguous
> > abbreviations, acronyms, and nicknames.
> 
> You mean, like the whole IT industry - and in fact pretty well any industry ? 
> Such terms are routinely used because they make speech and writing less 
> verbose. I did my apprenticeship in an engineering (plenty of acronyms there) 
> firm that was also a supplier to the UK's navy - the defence field is a sea 
> of acronyms* :-)
> 
> But back to our world, "pen testing" is a common term. A few seconds with 
> ${preferred_search_engine} would come up with a definition.

The trouble is with abbreviations that are common words in their own 
right, with the result that people not knowing it's an abbreviation 
will get a quite different meaning, and not know they've 
misunderstood.

-- hendrik
.
> 
> * I was involved in software, and one day for a bit of light amusement 
> decided to fully expand the acronym of something I was working on. Thing is, 
> some of the letters in the acronym were in fact initial of other acronyms, 
> and by the time I'd fully expended all the levels I think a 6 letter acronym 
> became a whole paragraph !
> 
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Noel Torres]

Steve Litt  escribió:
[...]

I think the only daemons you really need in an installer are the
gettys, sshd, wpa_supplicant and dhcpcd. And you'll probably want
the display manager too. Those obviously must be included in packages.
The more obscure stuff can exist first on the Wiki, and gradually be
incorporated into the packages after they've been proven correct.


Better expressed that way :)


What I was trying to do is shelter the poor maintainers from having a
brand new job thrown at them, and having to learn about every init
system out there (conspicuously excluding systemd).


Agreed


At this point let me say this: It's way premature to speak of any
change in the default init system. What I'm personally speaking of is
alternate inits you can lay down on Devuan, for that minority of people
who care what their init system is (as long as it's not an entangled
monolith).


Yes, but Devuan packagers can (almost blindly) copy scripts from wiki  
to packages, slowly, to allow that happen in a proper way.


[some things about how to package, with which I don't agree but that  
aren't priority]


Anyway, none of this is top priority: We're doing just fine with
sysvinit, and the people who *really* want to alt-init already know how
to do so, with or without Devuan packages to help them. Let those
people do the pioneering work.


Agreed

Noel
er Envite


bin1LIy6CVg5O.bin
Description: Clave PGP pública


pgp_bAm5Q0Yuz.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Wed, 04 May 2016 06:47:06 +
Noel Torres  wrote:

> Steve Litt  escribió:
> 
> > On Mon, 2 May 2016 22:15:44 -1000
> > Joel Roth  wrote:
> >
> >  
> >> The problem with supporting multiple init systems is that
> >> there is an init script for each service that has to be
> >> ported or rewritten.  
> [...]
> > It's a documentation task. If we had a wiki upon which users could
> > write their successful init scripts/run scripts/EpochConfigs etc,
> > this task would be removed from upstream developers, who never
> > should have had this responsibility in the first place.  
> 
> We can use a wiki for collecting this, but the scripts should be in  
> packages, and should be installed, so maybe this wiki might help  
> creating bug reports for the maintainers to just add these files to  
> their packages.
> 
> It is not conceivable that a user that wants a
> different-than-default init system must copy scripts from the wiki
> while the machine can not yet access the wiki as it is still being
> installed!

Oh yeah, that issue :-)

I think the only daemons you really need in an installer are the
gettys, sshd, wpa_supplicant and dhcpcd. And you'll probably want
the display manager too. Those obviously must be included in packages.
The more obscure stuff can exist first on the Wiki, and gradually be
incorporated into the packages after they've been proven correct.

What I was trying to do is shelter the poor maintainers from having a
brand new job thrown at them, and having to learn about every init
system out there (conspicuously excluding systemd).

At this point let me say this: It's way premature to speak of any
change in the default init system. What I'm personally speaking of is
alternate inits you can lay down on Devuan, for that minority of people
who care what their init system is (as long as it's not an entangled
monolith). 

Let's talk about a person who is partial enough to a specific init
system to alt-init Devuan. Their system installation is sysvinit, and
then later they install OpenRC or runit or s6 or Epoch. Let's take
runit as an example, as it's the only one I know a lot about. They
install the runit package, which comes with run scripts for tty1-tty6,
sshd, wpa_supplicant, dhcpcd, ntpd, httpd. Then, as they need software
without included run scripts, they write the run scripts. Because
they're enthusiasts of that init system, they probably do it well. Then
they put the run scripts on the wiki, others test them, and over time
they become tested enough to go in the runit package. Nobody has an
undue amount of work, and nobody's working on something they don't give
a flying flamingo about. 

Over time each init will end up with init scripts/run scripts,
EpochConfs for lots and lots of daemons. Maybe at some point the
scripts for a given init system will be complete enough that they can
be transferred to the daemon's package, but I don't see a need to rush
that.

Anyway, none of this is top priority: We're doing just fine with
sysvinit, and the people who *really* want to alt-init already know how
to do so, with or without Devuan packages to help them. Let those
people do the pioneering work.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Joel Roth]

On Wed, May 04, 2016 at 01:03:08PM +0800, Robert Storey wrote:
> For whatever it's worth, I'm fully supportive of the idea of defaulting to
> a simpler init system such as S6, Epoch, Runit, you-name-it. 

Many people agree that sysvinit with its symlinks and run
levels is overly complex for the common use case.

> The main issue with switching from sysvinit to something else is just
> finding someone willing to do the work.

As I wrote before, hundreds of scripts could be involved.
Daniel Reurich observed that bug reports could be filed
with each package, and then resolved as scripts are added.

The upstream software developer may not care about multiple
init systems, so the burden would be on the Devuan package
developer to support them. It would be great if some
automated tools could do this, but programmatically parsing
and transforming shell scripts is a task that will be
fraught with complexity. Perhaps some examples to follow for
each init system will be enough for packagers,
or init system advocate teams to write the necessary
scripts.

cheers,

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Simon Hobson]

Steve Litt  wrote:

> There's a special place in hell for people using ambiguous
> abbreviations, acronyms, and nicknames.

You mean, like the whole IT industry - and in fact pretty well any industry ? 
Such terms are routinely used because they make speech and writing less 
verbose. I did my apprenticeship in an engineering (plenty of acronyms there) 
firm that was also a supplier to the UK's navy - the defence field is a sea of 
acronyms* :-)

But back to our world, "pen testing" is a common term. A few seconds with 
${preferred_search_engine} would come up with a definition.

* I was involved in software, and one day for a bit of light amusement decided 
to fully expand the acronym of something I was working on. Thing is, some of 
the letters in the acronym were in fact initial of other acronyms, and by the 
time I'd fully expended all the levels I think a 6 letter acronym became a 
whole paragraph !

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Noel Torres]

Steve Litt  escribió:


On Mon, 2 May 2016 22:15:44 -1000
Joel Roth  wrote:



The problem with supporting multiple init systems is that
there is an init script for each service that has to be
ported or rewritten.

[...]

It's a documentation task. If we had a wiki upon which users could
write their successful init scripts/run scripts/EpochConfigs etc, this
task would be removed from upstream developers, who never should have
had this responsibility in the first place.


We can use a wiki for collecting this, but the scripts should be in  
packages, and should be installed, so maybe this wiki might help  
creating bug reports for the maintainers to just add these files to  
their packages.


It is not conceivable that a user that wants a different-than-default  
init system must copy scripts from the wiki while the machine can not  
yet access the wiki as it is still being installed!


Regards

Noel
er Envite


binVWvKQgNw1c.bin
Description: Clave PGP pública


pgpWRVmrSNERQ.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[KatolaZ]

On Wed, May 04, 2016 at 12:55:09AM -0400, Peter Olson wrote:
> > On May 3, 2016 at 11:43 PM Joel Roth  wrote:
> 
>  [...]
> 
> > Interesting, I thought /sbin was historically for statically
> > linked executables needed at boot time, or for system
> > recovery.
> 
> The /sbin and /usr/sbin are analogous to /bin and /usr/sbin but they contain
> programs for administrative purposes such as adduser which require privileges
> and are not needed by user logins or might not be expected for ordinary user
> access.
> 
> On some distros ifconfig is in one of these and isn't visible to the user, 
> even
> though it might be useful.
> 

This is just a mishap. You might include /sbin in your PATH and
ifconfig automagically becomes available to you. Not all the
executables in /sbin and /usr/sbin require root privilege to run...

PDSCE

KatolaZ

-- 
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Noel Torres]

Jim Murphy  escribió:
[...]

UNIX and lookalikes have been able to boot into single user mode
with a small root filesystem without the need for /usr, /var or ...
There are still admins that have split any number of these directories
into their own filesystems for various reasons. I guess you can call
these use-cases. By placing the init systems in /var we again remove
another choice for admins/users.  If we are about choice, then /var
may not be the best place to put inits.

[...]

For sure my installations have /var separated, to avoid  
/var/log/syslog growing enough to fill / and thus causing the system  
to fail.


The only things I consider to be on root filesystem are:
/ (obviously)
/etc
/lib
/bin
/sbin

Not even /boot, which I use to have in a separated partition  
independently in each hard disk, while all the others are in a  
replicated RAID among all disks.


From this, I derive that init system files should be in /etc  
(configuration) and /sbin (executables). For the sake of keeping  
things as they are, shell scripts could continue in /etc as in  
/etc/init.d so I strongly raise hand for /etc/orc or /etc/wtf-is .


Regards

Noel
er Envite


bin7zwZdCxPow.bin
Description: Clave PGP pública


pgpfq2MMHqQCU.pgp
Description: Firma digital PGP
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[emninger]

Am Tue, 03 May 2016 08:27:05 +
schrieb dng-requ...@lists.dyne.org:

> From: parazyd <para...@dyne.org>
> To: Hendrik Boom <hend...@topoi.pooq.com>
> Cc: dng@lists.dyne.org
> Subject: Re: [DNG] OpenRC and Devuan
> Message-ID: <20160503071226.GA10101@hansolo>
> Content-Type: text/plain; charset="utf-8"
> 
> On Mon, 02 May 2016, Hendrik Boom wrote:
> 
> > Is there a summary of some sort explaining the various init
> > systems, how they're put together, how they work, and especially
> > the salient points on which they differ?  
> 
> Perhaps this as a short intro:
> https://wiki.gentoo.org/wiki/Comparison_of_init_systems

http://www.troubleshooters.com/linux/init/manjaro_experiments.htm
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Robert Storey]

For whatever it's worth, I'm fully supportive of the idea of defaulting to
a simpler init system such as S6, Epoch, Runit, you-name-it. I can't speak
for anyone else, of course, but I tend to think the sort of people who are
attracted to Devuan see the virtue of simplicity. The main reason why we
disdain systemd is because it's a mass of incomprehensible spaghetti code
with dependencies up the ying-yang, and all that entails (ie a huge
potential attack surface, dependency on Red Hat's "good will" for
maintenance, etc).

The main issue with switching from sysvinit to something else is just
finding someone willing to do the work. I don't feel very qualified myself.
I'm not sure if SteveL was volunteering or suggesting we organize
something, but anyway, the idea of S6, Epoch, Runit or similar simple and
comprehensible init systems appeals to me.

cheers,
Robert
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Peter Olson]

> On May 3, 2016 at 11:43 PM Joel Roth  wrote:

 [...]

> Interesting, I thought /sbin was historically for statically
> linked executables needed at boot time, or for system
> recovery.

The /sbin and /usr/sbin are analogous to /bin and /usr/sbin but they contain
programs for administrative purposes such as adduser which require privileges
and are not needed by user logins or might not be expected for ordinary user
access.

On some distros ifconfig is in one of these and isn't visible to the user, even
though it might be useful.

Peter Olson
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Joel Roth]

Steve Litt wrote:
> Joel Roth  wrote:
> 
> > Hendrik Boom wrote:
> > > There's a small number of directories that are supposed to be on
> > > the root filesystem, or otherwise available during boot.  I
> > > believe /etc and /bin are two of these.
> > > 
> > > /usr is not.  I suspect /var isn't either.
> > > 
> > > init is supposed to be able to read /etc/fstab to find the others.  
> > > That's why /etc has to be on the root filesystem.
> > > 
> > > So it is available for init-time configuration files.  
> > 
> > /etc is the right place for config files, and init scripts
> > have historically lived there. I hope we can agree on at
> > least this part!
> 
> No doubt about it. /etc is the tree where init scripts, run scripts,
> EpochConfig files belong.
> 
> I think the nonobvious thing comes from the daemontools-inspired inits,
> which at a minimum have a /service directory somewhere that contains
> symlinks to the actual service directories. No reason that can't be
> somewhere under /etc. Daemontools, and maybe some other ones, also have
> a /command directory, directly off the root, that houses executables
> specific to themselves. It's possible this odd placement is to
> guarantee they're available the minute the root partition is mounted.

Interesting, I thought /sbin was historically for statically
linked executables needed at boot time, or for system
recovery.
 
> Bizarrely, Runit on Void Linux has a directory at /run/runit that has
> all sorts of oddball symlinks. I believe this is so, if /etc/ is
> mounted read-only, parts of Runit that need to change file conttents
> can still operate. I think this is usually placed at /var/run/runit,
> but on Void it's just /run/runit.
> 
> I did a little runit experimentation during my Manjaro Experiments, and
> have found that Void's runit implementation is much more complex and
> full of chained symlinks than was my Manjaro alt-initted runit.

Well, all of these sources can be patched to suit the
policies of Devuan, if it can be agreed what these policies
are :-)
 
> SteveT
> 
> Steve Litt 
> April 2016 featured book: Rapid Learning for the 21st Century
> http://www.troubleshooters.com/rl21

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Tue, 3 May 2016 15:24:47 -1000
Joel Roth  wrote:

> Hendrik Boom wrote:
> > There's a small number of directories that are supposed to be on
> > the root filesystem, or otherwise available during boot.  I
> > believe /etc and /bin are two of these.
> > 
> > /usr is not.  I suspect /var isn't either.
> > 
> > init is supposed to be able to read /etc/fstab to find the others.  
> > That's why /etc has to be on the root filesystem.
> > 
> > So it is available for init-time configuration files.  
> 
> /etc is the right place for config files, and init scripts
> have historically lived there. I hope we can agree on at
> least this part!

No doubt about it. /etc is the tree where init scripts, run scripts,
EpochConfig files belong.

I think the nonobvious thing comes from the daemontools-inspired inits,
which at a minimum have a /service directory somewhere that contains
symlinks to the actual service directories. No reason that can't be
somewhere under /etc. Daemontools, and maybe some other ones, also have
a /command directory, directly off the root, that houses executables
specific to themselves. It's possible this odd placement is to
guarantee they're available the minute the root partition is mounted.

Bizarrely, Runit on Void Linux has a directory at /run/runit that has
all sorts of oddball symlinks. I believe this is so, if /etc/ is
mounted read-only, parts of Runit that need to change file conttents
can still operate. I think this is usually placed at /var/run/runit,
but on Void it's just /run/runit.

I did a little runit experimentation during my Manjaro Experiments, and
have found that Void's runit implementation is much more complex and
full of chained symlinks than was my Manjaro alt-initted runit.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Nate Bargmann]

* On 2016 03 May 16:38 -0500, Steve Litt wrote:

> "Pen testing" My Aunt's Hat!

I thought it was trying different Linux distributions from a USB pen.

Shrug.

- Nate

-- 

"The optimist proclaims that we live in the best of all
possible worlds.  The pessimist fears this is true."

Ham radio, Linux, bikes, and more: http://www.n0nb.us
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Joel Roth]

Hendrik Boom wrote:
> There's a small number of directories that are supposed to be on the 
> root filesystem, or otherwise available during boot.  I believe /etc 
> and /bin are two of these.
> 
> /usr is not.  I suspect /var isn't either.
> 
> init is supposed to be able to read /etc/fstab to find the others.  
> That's why /etc has to be on the root filesystem.
> 
> So it is available for init-time configuration files.

/etc is the right place for config files, and init scripts
have historically lived there. I hope we can agree on at
least this part!
 
> -- hendrik
> 
> > 
> > Perhaps LSB should add a directory called /mustnotbemountpoint directly
> > off the root, for stuff that must be available immediately upon
> > mounting the root partition for the first time.
> 
> There are already several suuch directories.
> 
> -- hendrik
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

-- 
Joel Roth
  

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Tue, 03 May 2016 23:07:05 +0200
Svante Signell  wrote:

> On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > 
> > Because OpenRC has seen fit to intermix their init scripts
> > with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> > OpenRC be kept somewhere besides /etc/init.d.
> >   
> 
> Hi Steve,
> 
> We had a patch where openrc in debian was openrc.postrm and
> openrc.preinst was used to to divert update-rc.d + invoke-rc.d files
> to not conflict with the init- system-helpers scripts: update-rc.d
> and invoke-rc.d, see dpkg-divert. That is the solution used
> by file-rc. Currently systemd, sysvinit-core and openrc use the
> method of cooperating with the scripts update-rc.d and invoke-rc.d in
> the init-system-helpers package. Which is your preferred solution, we
> can go either way.

:-)

Hi Svante,

I don't understand a single word of your preceding paragraph, which
isn't surprising given my lack of knowledge of packaging systems. I
also know very little about OpenRC. So I have no opinion on the choice
you give in the preceding paragraph.

An opinion I *do* have is that for s6, runit and Epoch, the Devuan
package as much as possible mimic the idiomatic way that the program's
developer says to install it. I don't think that will be particularly
hard to do, and in another post I outlined how sysvinit, s6, runit and
Epoch can coexist simply by naming their PID1's sysvinit.pid1, s6.pid1,
runit.pid1 and epoch.pid1, and then switching inits is as simple as
copying one of those .pid1 files to /sbin/init.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Svante Signell]

On Tue, 2016-05-03 at 23:24 +0200, parazyd wrote:
> On Tue, 03 May 2016, Svante Signell wrote:
> 
> As I've stated at the beginning of this whole thread, debian-openrc is
> irrelevant and a bad way to solve the whole issue of using OpenRC
> properly, becase they keep using LSB initscripts...

What about replacing the LSB initscripts, one by one in a suitable pace,
starting from the current state (they can be mixed, right?) And of course we
should replace the init-system-helpers package with a init-freedom package, as
pointed out before ;-)

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Steve Litt]

Thanks Stephanie!

There's a special place in hell for people using ambiguous
abbreviations, acronyms, and nicknames. I mean really, do they think
this makes them sound more "in the know?"

That author is a WAD. Now I get to feel superior as the word WAD rolls
glibly and effortlessly off my tongue.

"Pen testing" My Aunt's Hat!

Thanks Stephanie,

SteveT



On Tue, 03 May 2016 18:05:41 +
Stephanie Daugherty  wrote:

> I assume "penetration testing", and seems like a shortsighted view.
> 
> On Tue, May 3, 2016 at 1:57 PM Steve Litt 
> wrote:
> 
> > On Tue, 3 May 2016 09:05:03 + (UTC)
> > Go Linux  wrote:
> >
> >  
> > > 
> > >
> > > Linux = Pen testing
> > > Windows = everything else  
> >
> > What is pen testing? Am I out of touch, or is this guy making up
> > words?
> >
> > SteveT
> >
> > Steve Litt
> > April 2016 featured book: Rapid Learning for the 21st Century
> > http://www.troubleshooters.com/rl21
> > ___
> > Dng mailing list
> > Dng@lists.dyne.org
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> >  
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

On Tue, 03 May 2016, Svante Signell wrote:

> On Tue, 2016-05-03 at 23:05 +0200, parazyd wrote:
> > On Tue, 03 May 2016, Svante Signell wrote:
> > 
> > > 
> > > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > > > 
> > > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > > >  
> > > > Because OpenRC has seen fit to intermix their init scripts
> > > > with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> > > > OpenRC be kept somewhere besides /etc/init.d.
> > > > 
> > > Hi Steve,
> > > 
> > > We had a patch where openrc in debian was openrc.postrm and openrc.preinst
> > > was
> > > used to to divert update-rc.d + invoke-rc.d files to not conflict with the
> > > init-
> > > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That
> > > is
> > > the solution used by file-rc. Currently systemd, sysvinit-core and openrc
> > > use
> > > the method of cooperating with the scripts update-rc.d and invoke-rc.d in
> > > the
> > > init-system-helpers package. Which is your preferred solution, we can go
> > > either
> > > way.
> > invoke-rc.d and update-rc.d will NOT be used with OpenRc.
> 
> In Debian openrc they are.
> 

As I've stated at the beginning of this whole thread, debian-openrc is
irrelevant and a bad way to solve the whole issue of using OpenRC
properly, becase they keep using LSB initscripts...

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgpb3NgSXd0KV.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Svante Signell]

On Tue, 2016-05-03 at 23:05 +0200, parazyd wrote:
> On Tue, 03 May 2016, Svante Signell wrote:
> 
> > 
> > On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > > 
> > > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > >  
> > > Because OpenRC has seen fit to intermix their init scripts
> > > with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> > > OpenRC be kept somewhere besides /etc/init.d.
> > > 
> > Hi Steve,
> > 
> > We had a patch where openrc in debian was openrc.postrm and openrc.preinst
> > was
> > used to to divert update-rc.d + invoke-rc.d files to not conflict with the
> > init-
> > system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That
> > is
> > the solution used by file-rc. Currently systemd, sysvinit-core and openrc
> > use
> > the method of cooperating with the scripts update-rc.d and invoke-rc.d in
> > the
> > init-system-helpers package. Which is your preferred solution, we can go
> > either
> > way.
> invoke-rc.d and update-rc.d will NOT be used with OpenRc.

In Debian openrc they are.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

On Tue, 03 May 2016, Svante Signell wrote:

> On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> > On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> > 
> > Because OpenRC has seen fit to intermix their init scripts
> > with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> > OpenRC be kept somewhere besides /etc/init.d.
> > 
> 
> Hi Steve,
> 
> We had a patch where openrc in debian was openrc.postrm and openrc.preinst was
> used to to divert update-rc.d + invoke-rc.d files to not conflict with the 
> init-
> system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That is
> the solution used by file-rc. Currently systemd, sysvinit-core and openrc use
> the method of cooperating with the scripts update-rc.d and invoke-rc.d in the
> init-system-helpers package. Which is your preferred solution, we can go 
> either
> way.

invoke-rc.d and update-rc.d will NOT be used with OpenRc.

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgppiqAXuDHjn.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Svante Signell]

On Tue, 2016-05-03 at 16:32 -0400, Steve Litt wrote:
> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> 
> Because OpenRC has seen fit to intermix their init scripts
> with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> OpenRC be kept somewhere besides /etc/init.d.
> 

Hi Steve,

We had a patch where openrc in debian was openrc.postrm and openrc.preinst was
used to to divert update-rc.d + invoke-rc.d files to not conflict with the init-
system-helpers scripts: update-rc.d and invoke-rc.d, see dpkg-divert. That is
the solution used by file-rc. Currently systemd, sysvinit-core and openrc use
the method of cooperating with the scripts update-rc.d and invoke-rc.d in the
init-system-helpers package. Which is your preferred solution, we can go either
way.

___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[parazyd]

On Tue, 03 May 2016, Steve Litt wrote:

> On Tue, 3 May 2016 10:06:07 -0400 (EDT)
> Rob Owens  wrote:
> 
> 
> > I agree with putting each init in its own directory, but sysvinit
> > should not own /etc/init.d.  sysvinit stuff should go in /etc/sysvinit
> > and by default /etc/init.d should be a link to /etc/sysvinit/init.d.
> > The reason is that other init systems may expect to own /etc/init.d. 
> > For instance, openrc puts all its scripts in /etc/init.d (at least on 
> > Funtoo it does).
> 
> I don't remember any other init wanting to use /etc/init.d, EXCEPT
> OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
> the only one I know that wants to do that is systemd. 
> 
> I wouldn't change sysvinit's expected files one little bit. Everyone
> assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
> sysvinit would require lots of testing, and who needs that headache?
> 
> > 
> > Even though sysvinit is our default init system these days, we should
> > not design Devuan such that it is difficult to change that in the
> > future.  So put sysvinit stuff in its own directory just like all the
> > other inits.
> 
> If you leave sysvinit's directories exactly as they exist now,
> switching back and forth between sysvinit and runit is trivial. Same is
> true of s6 and Epoch.
> 
> Because OpenRC has seen fit to intermix their init scripts
> with sysvinit's in /etc/init.d, I'd suggest that any files needed by
> OpenRC be kept somewhere besides /etc/init.d.

The problem with this is Debian itself. They insist on using LSB init
scripts and in my opinion that they are somewhat different than what OpenRC
wants.

(For me at least) openrc initscripts are simpler, and also
for respecting the openrc way(?) I wish to keep it in /etc/openrc. This
way, with or without debhelper scripting OpenRC should work much more
easily. The only thing then is that the package maintainers would have
to include new initscripts in their packages, which might or might not
be cumbersome for them.

sysvinit should and will just stay where it already is. There is really
no point in changing it's current configuration when other alternatives
offer very easy ways to work around it.

-- 
~ parazyd
0333 7671 FDE7 5BB6 A85E  C91F B876 CB44 FA1B 0274



pgpbfnv5FOub3.pgp
Description: PGP signature
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Tue, 3 May 2016 10:06:07 -0400 (EDT)
Rob Owens  wrote:


> I agree with putting each init in its own directory, but sysvinit
> should not own /etc/init.d.  sysvinit stuff should go in /etc/sysvinit
> and by default /etc/init.d should be a link to /etc/sysvinit/init.d.
> The reason is that other init systems may expect to own /etc/init.d. 
> For instance, openrc puts all its scripts in /etc/init.d (at least on 
> Funtoo it does).

I don't remember any other init wanting to use /etc/init.d, EXCEPT
OpenRC, or EXCEPT when they want to use the sysvinit init scripts, and
the only one I know that wants to do that is systemd. 

I wouldn't change sysvinit's expected files one little bit. Everyone
assumes that /etc/init.d belongs exclusively to sysvinit. Any change to
sysvinit would require lots of testing, and who needs that headache?

> 
> Even though sysvinit is our default init system these days, we should
> not design Devuan such that it is difficult to change that in the
> future.  So put sysvinit stuff in its own directory just like all the
> other inits.

If you leave sysvinit's directories exactly as they exist now,
switching back and forth between sysvinit and runit is trivial. Same is
true of s6 and Epoch.

Because OpenRC has seen fit to intermix their init scripts
with sysvinit's in /etc/init.d, I'd suggest that any files needed by
OpenRC be kept somewhere besides /etc/init.d.

SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Mitt Green]

‎Steven W. Scott wrote:
‎
> Wow. Funny that, my view is:‎
> Windows: Gaming
> Linux: everything else

I am kind of a "hardcore" gamer,
nowadays especially in Sauerbraten
and Urban Terror, back then in RedEclipse,
I actually think that the situation with
games is good.

Count here 0 A.D., Battle for Wesnoth,
Quake(s), OpenArena, AssaultCube,
Speed Dreams and its parent, TORCS.

On Steam Dota 2 and CS 1.6, CS:GO
are available. Probably some other very
popular games too. Some claim
that performance in Linux is better
due to the quality of the drivers.

So, in my opinion:
Windows - I couldn't find FreeDOS/Linux
pre-installed;
Linux - everything;
OS X - I am gay.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Hendrik Boom]

On Tue, May 03, 2016 at 02:16:55PM -0400, Steve Litt wrote:
> On Tue, 3 May 2016 13:00:39 +0100
> KatolaZ  wrote:
> 
> > On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote:
> > 
> > [cut]
> > 
> > > 
> > > I know this is in the very early stages and where things go is
> > > still open to discussion, but consider this.
> > > 
> > > UNIX and lookalikes have been able to boot into single user mode
> > > with a small root filesystem without the need for /usr, /var or ...
> > > There are still admins that have split any number of these
> > > directories into their own filesystems for various reasons. I guess
> > > you can call these use-cases. By placing the init systems in /var
> > > we again remove another choice for admins/users.  If we are about
> > > choice, then /var may not be the best place to put inits.
> > > 
> > > Something to consider and discuss, I hope.
> > >   
> > 
> > I definitely agree with you Jim, and this is certainly one aspect to
> > be taken into account seriously. We should strive to allow the maximum
> > flexibility in choosing an init system, ensuring that the set of
> > constraints remains as small as possible.
> 
> Interesting point. Perhaps that's why Daniel J Bernstein (djb) put
> the /service directory directly off the root. He also put his
> executables in, IIRC, /command directly off the root. I always thought
> he was crazy, but Jim's point brings some sense to what djb did.
> 
> One distro I saw (perhaps Debian) put the /service directory
> under /etc. At the time I thought the packager was psychotic, but Jim's
> point makes me wonder if the real truth is I was a little shortsighted. 

There's a small number of directories that are supposed to be on the 
root filesystem, or otherwise available during boot.  I believe /etc 
and /bin are two of these.

/usr is not.  I suspect /var isn't either.

init is supposed to be able to read /etc/fstab to find the others.  
That's why /etc has to be on the root filesystem.

So it is available for init-time configuration files.

-- hendrik

> 
> Perhaps LSB should add a directory called /mustnotbemountpoint directly
> off the root, for stuff that must be available immediately upon
> mounting the root partition for the first time.

There are already several suuch directories.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Linux O'Beardly]

Actually, since Valve released a native Steam client for Linux, I've even
abandoned Windows for gaming.  Yes, I'm quite limited to what I can play,
but it has enough titles to keep me busy.

Linux O'Beardly
@LinuxOBeardly
http://o.beard.ly
linux.obear...@gmail.com

On Tue, May 3, 2016 at 3:00 PM, Steven W. Scott <codekra...@gmail.com>
wrote:

> Wow. Funny that, my view is:
>
> Windows: Gaming
> Linux: everything else
>
> Linux for pentest, hell yes, mostly because it lends itself extremely well
> to quickly implementing a prototype and automating it in a reliable manner.
> Windows scheduler is a joke, Windows development is a masochist's dream.
> Poweshell is an indicator that MS has only recently come to the
> understanding that automation is more than just a room full of low-skilled
> operators reacting to pop-up dialogs. Where does the cloud live, on
> Windows? Lol!
>
> SWS
> On May 3, 2016 5:05 AM, "Go Linux" <goli...@yahoo.com> wrote:
>
>> On Tue, 5/3/16, Mitt Green <mitt_gr...@riseup.net> wrote:
>>
>>  Subject: Re: [DNG] OpenRC and Devuan
>>  To: dng@lists.dyne.org
>>  Date: Tuesday, May 3, 2016, 1:51 AM
>>
>> >> The current init system is old. Ancient.
>> >> We should all agree on it. Devuan is looking
>> >> for a new init system that is not systemd and my
>> >> personal choice for this task from now on is
>> >> Gentoo's OpenRC.
>> ‎>
>> > Unix is old. Ancient. We should all agree on it.
>> > Devuan is looking for a new base system that
>> > is not Unix and my personal choice for this
>> > task from now is Microsoft's Windows.
>> >
>>
>> 
>>
>> Mitt's response reminded me of a post that was made to the forum earlier
>> today in the topic "Windows explained to Devuan supporters" at
>> https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 :
>>
>> 
>>
>> Linux = Pen testing
>> Windows = everything else
>>
>> There are no advantages in using any linux distros other than pen testing
>> and that it can be installed on a USB key(and I think that's very cool).
>> Even Software Defined Radio (SDR) with maybe the exception of GMS
>> intercepting and decoding, has more development under Windows. Night and
>> day. One works extremely well on all PCs and permits the User to actually
>> be productive and do things. The other one is a clunky Windows wannabe with
>> a couple of specialized advantages that most don't care about. So..
>>
>> YES
>> I like its functionality, its popularity(more software dev and hardware
>> support), its clarity and ease of use.
>> The only thing wrong with my Windows is its lack of pen testing
>> capability, and that is why I'm here (KL2 using Debian8 and now looking for
>> an alternative with Dev-one as a base), otherwise I would >> n e v e r <<
>> bother with anything linux, life is too short
>>
>> 
>>
>> I'll spare you my personal thoughts on this evaluation of Linux but
>> looking forward to all of yours.  :)
>>
>> golinux
>>
>>
>>
>>
>> ___
>> Dng mailing list
>> Dng@lists.dyne.org
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan (and Windows)

[Steven W. Scott]

Wow. Funny that, my view is:

Windows: Gaming
Linux: everything else

Linux for pentest, hell yes, mostly because it lends itself extremely well
to quickly implementing a prototype and automating it in a reliable manner.
Windows scheduler is a joke, Windows development is a masochist's dream.
Poweshell is an indicator that MS has only recently come to the
understanding that automation is more than just a room full of low-skilled
operators reacting to pop-up dialogs. Where does the cloud live, on
Windows? Lol!

SWS
On May 3, 2016 5:05 AM, "Go Linux" <goli...@yahoo.com> wrote:

> On Tue, 5/3/16, Mitt Green <mitt_gr...@riseup.net> wrote:
>
>  Subject: Re: [DNG] OpenRC and Devuan
>  To: dng@lists.dyne.org
>  Date: Tuesday, May 3, 2016, 1:51 AM
>
> >> The current init system is old. Ancient.
> >> We should all agree on it. Devuan is looking
> >> for a new init system that is not systemd and my
> >> personal choice for this task from now on is
> >> Gentoo's OpenRC.
> ‎>
> > Unix is old. Ancient. We should all agree on it.
> > Devuan is looking for a new base system that
> > is not Unix and my personal choice for this
> > task from now is Microsoft's Windows.
> >
>
> 
>
> Mitt's response reminded me of a post that was made to the forum earlier
> today in the topic "Windows explained to Devuan supporters" at
> https://talk.devuan.org/t/windows-explained-to-devuan-supporters/139/10 :
>
> 
>
> Linux = Pen testing
> Windows = everything else
>
> There are no advantages in using any linux distros other than pen testing
> and that it can be installed on a USB key(and I think that's very cool).
> Even Software Defined Radio (SDR) with maybe the exception of GMS
> intercepting and decoding, has more development under Windows. Night and
> day. One works extremely well on all PCs and permits the User to actually
> be productive and do things. The other one is a clunky Windows wannabe with
> a couple of specialized advantages that most don't care about. So..
>
> YES
> I like its functionality, its popularity(more software dev and hardware
> support), its clarity and ease of use.
> The only thing wrong with my Windows is its lack of pen testing
> capability, and that is why I'm here (KL2 using Debian8 and now looking for
> an alternative with Dev-one as a base), otherwise I would >> n e v e r <<
> bother with anything linux, life is too short
>
> 
>
> I'll spare you my personal thoughts on this evaluation of Linux but
> looking forward to all of yours.  :)
>
> golinux
>
>
>
>
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Tue, 3 May 2016 13:00:39 +0100
KatolaZ  wrote:

> On Tue, May 03, 2016 at 06:32:41AM -0500, Jim Murphy wrote:
> 
> [cut]
> 
> > 
> > I know this is in the very early stages and where things go is
> > still open to discussion, but consider this.
> > 
> > UNIX and lookalikes have been able to boot into single user mode
> > with a small root filesystem without the need for /usr, /var or ...
> > There are still admins that have split any number of these
> > directories into their own filesystems for various reasons. I guess
> > you can call these use-cases. By placing the init systems in /var
> > we again remove another choice for admins/users.  If we are about
> > choice, then /var may not be the best place to put inits.
> > 
> > Something to consider and discuss, I hope.
> >   
> 
> I definitely agree with you Jim, and this is certainly one aspect to
> be taken into account seriously. We should strive to allow the maximum
> flexibility in choosing an init system, ensuring that the set of
> constraints remains as small as possible.

Interesting point. Perhaps that's why Daniel J Bernstein (djb) put
the /service directory directly off the root. He also put his
executables in, IIRC, /command directly off the root. I always thought
he was crazy, but Jim's point brings some sense to what djb did.

One distro I saw (perhaps Debian) put the /service directory
under /etc. At the time I thought the packager was psychotic, but Jim's
point makes me wonder if the real truth is I was a little shortsighted. 

Perhaps LSB should add a directory called /mustnotbemountpoint directly
off the root, for stuff that must be available immediately upon
mounting the root partition for the first time.

Steve

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] OpenRC and Devuan

[Steve Litt]

On Tue, 3 May 2016 12:18:13 +0100
KatolaZ  wrote:


> Ideally, switching between init systems (e.g., reverting back to an
> init system which is known to work) should be achievable from a
> single-user root shell spawned as an emergency "init", using only a
> few executables in /bin and /sbin. Anything more complicated than that
> risks to become not that useful or even harmful in the long run, IMHO.

I was going to mention that. My understanding is that in Debian if you
install one init it removes the others. I like having multiple inits
for much the same reason many people have multiple kernels: You might
need to switch, you might need to A/B test, etc.

IMHO the package should install everything, and from what I understand
each init has completely different files than the others, and then
compile the pid1 to be runit.pid1 or s6.pid1 or epoch.pid1.

If so, then switching to, let's say, epoch, would be as simple as this:

cp -p /sbin/epoch.pid1 /sbin/init
 
SteveT

Steve Litt 
April 2016 featured book: Rapid Learning for the 21st Century
http://www.troubleshooters.com/rl21
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng