Re: [DNG] Switching to OpenRC

[Alessandro Selli]

On Mon, 21 May 2018 at 14:01:42 +0200
Adam Borowski  wrote:

> On Mon, May 21, 2018 at 05:53:56PM +1000, wirelessd...@gmail.com wrote:
>
>> Originally, I really had no idea what I was referring to specifically. 
>> After some more poking around, I think you’re right.  I said sysv-rc
>> because I noticed that installing the openrc package would only
>> uninstall/conflict with the sysv-rc package and not the rest of
>> sysvinit.  
>
> The important part is: sane init systems are _modular_.  Various fields have
> various integration-to-modularity tradeoffs, and init+rc+supervisor schemes
> are at such an extreme that I say it would take a deranged mind to argue
> that an unextendable blob is fit for this job.

  I fully agree.  What you wrote is to me the best rationale against systemd,
beyond the fine technical details.


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

Re: [DNG] Switching to OpenRC

[Steve Litt]

On Mon, 21 May 2018 14:01:42 +0200
Adam Borowski  wrote:


> ... none of the contenders is adequate for every single
> use case, thus you need to allow the sysadmin to replace pieces with
> something that he/she wants.  

Quoted for truth in perpetuity. Well said!

> Don't fear change, fear inability to change.

Even more quoted for truth in perpetuity!

I'll be using these points often. Thanks!

SteveT

Steve Litt 
June 2018 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] Switching to OpenRC, including respawn

[Steve Litt]

On Mon, 21 May 2018 19:05:37 +1000
wirelessd...@gmail.com wrote:

> > On 14 May 2018, at 18:51, Steve Litt 
> > wrote:
> > 
> > One property of OpenRC is it has no facility to respawn a daemon
> > when the old daemon crashes. Some folks like it this way, some
> > don't, but it's a fact of OpenRC. Except...
> > 
> > There are two ways to have OpenRC respawn. Way 1 is to run the
> > daemon from /etc/inittab, with the "respawn" flag. Remember, OpenRC
> > doesn't have its own PID1, and traditionally uses sysvinit's PID1.
> > 
> > Way 2 is to have OpenRC run either runit or s6 from /etc/inittab
> > with "respawn", and then to put all respawnable daemons in runit or
> > s6. Running either runit or s6 *as a supervisor rather than an
> > init* is dead-bang easy. Since about 2010 I've been doing something
> > similar: I ran daemontools on top of sysvinit, and it always worked
> > out great for me.
> > 
> > SteveT  
> 
> I had a closer look at OpenRC docs and noticed they now include a
> built-in “supervise-daemon”[1] supervisor that can be used instead of
> the default start-stop-daemon.  It will restart a daemon if it
> terminates unexpectedly.

Dang that's big news, and changes things profoundly. From reading it,
did it look like you could use the start-stop on some things,  and the
"supervise daemon" on others? That would be ideal.

> 
> The only issue with it for my use case is that I couldn’t find any
> way to send an arbitrary signal to the supervised daemon without
> signalling it to stop. The problem being that the pidfile created
> exists for the individual supervisor process and not the supervised
> daemon process.

I'll tell you about signals in runit, in the hope that you can find
something similar in OpenRC. Runit has the sv command, which can be
used to start the process being supervised, send signals to the process,
or get info about the process:

sv down sshd sends TERM then CONT to sshd

Without going into syntax, sv can easily send any of the following
signals to the daemon (sshd in this example):

STOP, CONT, HUP, ALRM, INT, QUIT, USR1, USR2, TERM, or KILL

But wait, there's more. If somehow you need to send yet some other
signal, the generic way is to find the daemon's PID is the following:


[root@mydesk ~]# sv status sshd
run: sshd: (pid 739) 56174s
[root@mydesk ~]#


A little awk-foo, and you have your PID, and from there, you can use
the kill command (or equivalent in whatever language you're using) to
send absolutely any signal to that PID.

I bet OpenRC's supervisor has an equivalent to sv status, because
daemontools, runit and s6, all prior art, have that capability.

SteveT

Steve Litt 
June 2018 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] Switching to OpenRC

[Adam Borowski]

On Mon, May 21, 2018 at 05:53:56PM +1000, wirelessd...@gmail.com wrote:
> >> On Tue, 15 May 2018 23:39:24 +1000
> >> Tom  wrote:
> >> 
> >>> Thanks as always for your insightful information Steve. Much
> >>> appreciated. As someone who knows very little about init systems,
> >>> can you explain what this respawning business is all about?
> >> 
> >> Terminology: I call the init system we've used for 30 years "sysvinit".
> > 
> >> I assume here you mean sysvinit when you write sysv-rc.
> > 
> >  I think Tom is not referring to the whole init system, rather to just the
> > rc scripts:

> Originally, I really had no idea what I was referring to specifically. 
> After some more poking around, I think you’re right.  I said sysv-rc
> because I noticed that installing the openrc package would only
> uninstall/conflict with the sysv-rc package and not the rest of sysvinit.

The important part is: sane init systems are _modular_.  Various fields have
various integration-to-modularity tradeoffs, and init+rc+supervisor schemes
are at such an extreme that I say it would take a deranged mind to argue
that an unextendable blob is fit for this job.

The reason is: none of the contenders is adequate for every single use case,
thus you need to allow the sysadmin to replace pieces with something that
he/she wants.  More importantly, "job security" is antithetical to Free
Software: an irreplaceable tangle can't be reasonably improved.  A set of
small modules, on the other hand, is _made_ for experiments, many of which
will take over their predecessors.  Don't fear change, fear inability to
change.

Main parts here are:

* init.  Pid 1.  Its tasks are: 1. spawning the rc system; 2. reaping
  orphaned processes.  That's all.  Other functionality might be also
  implemented in pid 1, but that's up to you -- for example, sysvinit chose
  to add a rudimentary process supervisor whose main use today is spawning
  getties -- and a particular contender put pretty much everything there.

* rc system.  On De??an started by /etc/init.d/rcS; its tasks are starting
  daemons whenever you boot, shutdown, switch to a different runlevel,
  install or remove a package, or otherwise manually request.  This is
  sysv-rc or openrc.

* daemon supervisor.  This is what handles daemons that unexpectedly die. 
  Most daemons are designed to not die, the only case on a regular Unix
  system  is getty -- anything else tends to be a hallmark of an attack;
  usually mindlessly restarting turns a DoS into giving more and more
  opportunity of a successful intrusion.
  
  For a real supervisor you want something like runit; sysvinit has inittab
  which is extremely limited.  OpenRC has no equivalent -- or rather, had
  none until the introduction of supervise-daemon which I don't know yet.
  But hey, it's not like I'm one of uploaders of openrc or anything to be
  supposed to know such things, am I?


.sig related.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start
⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax
⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child:
⠈⠳⣄ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Switching to OpenRC, including respawn

[wirelessduck]

> On 14 May 2018, at 18:51, Steve Litt  wrote:
> 
> One property of OpenRC is it has no facility to respawn a daemon when
> the old daemon crashes. Some folks like it this way, some don't, but
> it's a fact of OpenRC. Except...
> 
> There are two ways to have OpenRC respawn. Way 1 is to run the daemon
> from /etc/inittab, with the "respawn" flag. Remember, OpenRC doesn't
> have its own PID1, and traditionally uses sysvinit's PID1.
> 
> Way 2 is to have OpenRC run either runit or s6 from /etc/inittab with
> "respawn", and then to put all respawnable daemons in runit or s6.
> Running either runit or s6 *as a supervisor rather than an init* is
> dead-bang easy. Since about 2010 I've been doing something similar: I
> ran daemontools on top of sysvinit, and it always worked out great for
> me.
> 
> SteveT

I had a closer look at OpenRC docs and noticed they now include a built-in 
“supervise-daemon”[1] supervisor that can be used instead of the default 
start-stop-daemon.  It will restart a daemon if it terminates unexpectedly.

The only issue with it for my use case is that I couldn’t find any way to send 
an arbitrary signal to the supervised daemon without signalling it to stop. The 
problem being that the pidfile created exists for the individual supervisor 
process and not the supervised daemon process.

[1] https://github.com/OpenRC/openrc/blob/master/supervise-daemon-guide.md

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

Re: [DNG] Switching to OpenRC

[wirelessduck]

> On 19 May 2018, at 12:36, Alessandro Selli <alessandrose...@linux.com> wrote:
> 
>  Sorry for breaking the thread, but I no longer have the original post to
> reply to.
> 
> Author: Steve Litt
> Date: 2018-05-15 16:55 +200
> To: dng
> Subject: Re: [DNG] Switching to OpenRC
> 
>> On Tue, 15 May 2018 23:39:24 +1000
>> Tom <wirelessduck@???> wrote:
>> 
>>> Thanks as always for your insightful information Steve. Much
>>> appreciated. As someone who knows very little about init systems,
>>> can you explain what this respawning business is all about?
>> 
>> Terminology: I call the init system we've used for 30 years "sysvinit".
> 
> [...]
> 
>>> I didn’t
>>> realise the existing sysv-rc
>> 
>> I assume here you mean sysvinit when you write sysv-rc.
> 
>  I think Tom is not referring to the whole init system, rather to just the
> rc scripts:
> 
> Pure SysV Devuan Ascii:
> 
> [alessandro@wkstn09 ~ ]$ dpkg-query --search /etc/init.d/rc
> sysv-rc: /etc/init.d/rc
> [alessandro@wkstn09 ~ ]$ 
> 
> SysV+OpenRC Devuan Ascii:
> 
> alessandro@kratom:~$ dpkg-query --search /etc/init.d/rc
> openrc: /etc/init.d/rc
> alessandro@kratom:~$

Originally, I really had no idea what I was referring to specifically. After 
some more poking around, I think you’re right. I said sysv-rc because I noticed 
that installing the openrc package would only uninstall/conflict with the 
sysv-rc package and not the rest of sysvinit.

Hopefully that clears things up a bit.

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

Re: [DNG] Switching to OpenRC

[Alessandro Selli]

  Sorry for breaking the thread, but I no longer have the original post to
reply to.

Author: Steve Litt
Date: 2018-05-15 16:55 +200
To: dng
Subject: Re: [DNG] Switching to OpenRC

> On Tue, 15 May 2018 23:39:24 +1000
> Tom <wirelessduck@???> wrote:
>
>> Thanks as always for your insightful information Steve. Much
>> appreciated. As someone who knows very little about init systems,
>> can you explain what this respawning business is all about?
>
> Terminology: I call the init system we've used for 30 years "sysvinit".

[...]

>> I didn’t
>> realise the existing sysv-rc
>
> I assume here you mean sysvinit when you write sysv-rc.

  I think Tom is not referring to the whole init system, rather to just the
rc scripts:

Pure SysV Devuan Ascii:

[alessandro@wkstn09 ~ ]$ dpkg-query --search /etc/init.d/rc
sysv-rc: /etc/init.d/rc
[alessandro@wkstn09 ~ ]$ 

SysV+OpenRC Devuan Ascii:

alessandro@kratom:~$ dpkg-query --search /etc/init.d/rc
openrc: /etc/init.d/rc
alessandro@kratom:~$

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

Re: [DNG] Switching to OpenRC

[Didier Kryn]

Le 15/05/2018 à 18:53, Martin Steigerwald a écrit :

Didier Kryn - 15.05.18, 14:26:

Le 15/05/2018 à 13:23, Martin Steigerwald a écrit :

wirelessd...@gmail.com - 14.05.18, 02:52:

I’ve read that the ascii RC has optional support for OpenRC.How
can I switch to this on an existing system to try it out?

Is it simply a matter of running “apt-get install openrc”?

This basically did it for me. But this warning has been unhelpful
for me:

%:/var/lib/dpkg/info# grep -A 2 "sysv" *openrc*
openrc.postinst:echo "*** WARNING: if you are replacing
sysv-rc by OpenRC, then you must ***" openrc.postinst-echo
"*** reboot immediately using the following command:
***" openrc.postinst-echo 'for file in /etc/rc0.d/K*; do
s=`basename $(readlink "$file")` ; /etc/init.d/$s stop; done'

...


What this did on my system is: Stop all services and then sit there.

  That's what this long command exactly means: for every init
script which is to be stopped at shutdown (those with a symlink with
a K prefix), execute the stop command. There's just an error in the
postinst message, because it says that would also perform the reboot.

That is what I thought to. But then there was also this postinst
message.


   It
did not reboot. I asked a co-worker to reboot the machine via the
hypervisor and it worked.

  You could as well send the command 'reboot'

Not after SSH was gone.

    Sure. I missed that point.


But you mean instead of this loop I could have used reboot? Then why is
this postinst message there to begin with?
    No. Reboot would fail because it wouldn't be able to stop the 
services. It seems you have to sit in front of the computer to be able 
to switch from sysv to openrc (and vice-versa). Or to connect to it via 
some backdoor of your own, not managed by init scripts. Or use some 
behated management engine (IPMI).


Didier




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

Re: [DNG] Switching to OpenRC

[Martin Steigerwald]

Hector Gonzalez - 15.05.18, 15:55:
> On 05/15/2018 06:23 AM, Martin Steigerwald wrote:
> > This basically did it for me. But this warning has been unhelpful
> > for me:
> > 
> > %:/var/lib/dpkg/info# grep -A 2 "sysv" *openrc*
> > openrc.postinst:echo "*** WARNING: if you are replacing
> > sysv-rc by OpenRC, then you must ***" openrc.postinst-echo
> > "*** reboot immediately using the following command:   
> > ***" openrc.postinst-echo 'for file in /etc/rc0.d/K*; do
> > s=`basename $(readlink "$file")` ; /etc/init.d/$s stop; done'
> > 
> > (Devuan Ascii with sysvinit-core, systemd package already purged)
> > 
> > What this did on my system is: Stop all services and then sit there.
> > It did not reboot. I asked a co-worker to reboot the machine via
> > the hypervisor and it worked.
> 
> This happens because runlevel 0 ends with "K12halt", so the warning is
> wrong, if you want to reboot you should use runlevel 6, the last
> command it runs is "K12reboot".

Hmm, I bet that is worth a bug report. In the Debian bugtracker is no 
open report about it, but Debian GNU/Sid has already 0.34-2 of OpenRC.

Should a bug report go into the Debian bugtracker or into the Devuan 
bugtracker or both?

-- 
Martin


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

Re: [DNG] Switching to OpenRC

[Steve Litt]

On Tue, 15 May 2018 23:39:24 +1000
Tom  wrote:

> > On 14 May 2018, at 18:51, Steve Litt 
> > wrote:
> > 

> > Way 2 is to have OpenRC run either runit or s6 from /etc/inittab
> > with "respawn", and then to put all respawnable daemons in runit or
> > s6. Running either runit or s6 *as a supervisor rather than an
> > init* is dead-bang easy. Since about 2010 I've been doing something
> > similar: I ran daemontools on top of sysvinit, and it always worked
> > out great for me.
> > 
> > SteveT  
> 
> Thanks as always for your insightful information Steve.  Much
> appreciated.  As someone who knows very little about init systems,
> can you explain what this respawning business is all about?  

Terminology: I call the init system we've used for 30 years "sysvinit".

Yes, I'll explain. Your httpd server crashes. There are two ways of
handling it:

1) Let it stay crashed until human intervention restarts it.
2) Make it restart itself (this is called respawning)

Neither is better than the other: Which one to use depends on the
situation. With something like httpd, perhaps it's best for a human to
fix and diagnose it so it doesn't keep happening. However, some of my
home-grown daemons are buggy enough that I'd rather they just log the
crash and restart.

* Sysvinit mainly stays crashed, but daemons identified as "respawn"
  in /etc/inittab respawn themselves.

* OpenRC, by itself, only stays crashed.

* SystemD does either.

* Runit and s6 only respawn unless extraordinary measures are taken

* s6 plus s6-rc does either

* Bolting on either runit or s6 on top of either sysvinit or 

> I didn’t
> realise the existing sysv-rc 

I assume here you mean sysvinit when you write sysv-rc.

> did anything like that as I’ve never had
> one of the regular system daemons (or apache2, ntp, etc.) knowingly
> crash on me.

In which case, you probably have little need for respawning.

> 
> Apart from being a drop-in replacement for sysv-rc, is there any
> noticeable feature that I would use as a sysadmin with OpenRC?  

I'm not an OpenRC expert, so everything I know is second hand. I've
heard OpenRC can do parallel instantiation, for faster boots. You know,
like systemd claims to do. People more knowledgeable than I can give
you other OpenRC advantages.

> I’ve
> never encountered any boot issues or problems starting/stopping
> services with says-rc.  

You sound like the ideal candidate for either sysvinit or OpenRC.

> Perhaps there are other features of init
> systems that people use regularly?

YES! I use the following two features of runit regularly:

1) Simplicity
2) Run scripts are <10 lines, not the 30Megaline behemoths of sysvinit
   and OpenRC.
3) Daemons run by runit (or s6 or any other daemontools-inspired init
   or process supervisor) needn't (and shouldn't) background itself.
   Makes it much easier to write your own daemons.

SteveT

Steve Litt 
June 2018 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] Switching to OpenRC

[Didier Kryn]

Le 15/05/2018 à 13:23, Martin Steigerwald a écrit :

wirelessd...@gmail.com - 14.05.18, 02:52:

I’ve read that the ascii RC has optional support for OpenRC. How can I
switch to this on an existing system to try it out?

Is it simply a matter of running “apt-get install openrc”?

This basically did it for me. But this warning has been unhelpful for me:

%:/var/lib/dpkg/info# grep -A 2 "sysv" *openrc*
openrc.postinst:echo "*** WARNING: if you are replacing sysv-rcby OpenRC, 
then you must ***"
openrc.postinst-echo "*** reboot immediately using the following command:
***"
openrc.postinst-echo 'for file in /etc/rc0.d/K*; do s=`basename $(readlink 
"$file")` ; /etc/init.d/$s stop; done'

...

What this did on my system is: Stop all services and then sit there.


    That's what this long command exactly means: for every init script 
which is to be stopped at shutdown (those with a symlink with a K 
prefix), execute the stop command. There's just an error in the postinst 
message, because it says that would also perform the reboot.

  It
did not reboot. I asked a co-worker to reboot the machine via the
hypervisor and it worked.


    You could as well send the command 'reboot'

        Didier


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

Re: [DNG] Switching to OpenRC

[Hector Gonzalez]

On 05/15/2018 06:23 AM, Martin Steigerwald wrote:


This basically did it for me. But this warning has been unhelpful for me:

%:/var/lib/dpkg/info# grep -A 2 "sysv" *openrc*
openrc.postinst:echo "*** WARNING: if you are replacing sysv-rc by OpenRC, 
then you must ***"
openrc.postinst-echo "*** reboot immediately using the following command:
***"
openrc.postinst-echo 'for file in /etc/rc0.d/K*; do s=`basename $(readlink 
"$file")` ; /etc/init.d/$s stop; done'

(Devuan Ascii with sysvinit-core, systemd package already purged)

What this did on my system is: Stop all services and then sit there. It
did not reboot. I asked a co-worker to reboot the machine via the
hypervisor and it worked.



This happens because runlevel 0 ends with "K12halt", so the warning is 
wrong, if you want to reboot you should use runlevel 6, the last command 
it runs is "K12reboot".


--
Héctor González
ca...@genac.org

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

Re: [DNG] Switching to OpenRC

[Martin Steigerwald]

wirelessd...@gmail.com - 14.05.18, 02:52:
> I’ve read that the ascii RC has optional support for OpenRC. How can I
> switch to this on an existing system to try it out?
> 
> Is it simply a matter of running “apt-get install openrc”?

This basically did it for me. But this warning has been unhelpful for me:

%:/var/lib/dpkg/info# grep -A 2 "sysv" *openrc*
openrc.postinst:echo "*** WARNING: if you are replacing sysv-rc by 
OpenRC, then you must ***"
openrc.postinst-echo "*** reboot immediately using the following 
command:***"
openrc.postinst-echo 'for file in /etc/rc0.d/K*; do s=`basename 
$(readlink "$file")` ; /etc/init.d/$s stop; done'

(Devuan Ascii with sysvinit-core, systemd package already purged)

What this did on my system is: Stop all services and then sit there. It
did not reboot. I asked a co-worker to reboot the machine via the
hypervisor and it worked.

openrc 0.23-1+b1 on my first ever Devuan server :)

> If I switch, will I have to create new service definition files for
> each existing daemon in /etc/init.d or can it read and reuse those
> files automatically?

I didn´t do anything except installing openrc and rebooting.

Thanks,
-- 
Martin


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

Re: [DNG] Switching to OpenRC, including respawn

[Steve Litt]

One property of OpenRC is it has no facility to respawn a daemon when
the old daemon crashes. Some folks like it this way, some don't, but
it's a fact of OpenRC. Except...

There are two ways to have OpenRC respawn. Way 1 is to run the daemon
from /etc/inittab, with the "respawn" flag. Remember, OpenRC doesn't
have its own PID1, and traditionally uses sysvinit's PID1.

Way 2 is to have OpenRC run either runit or s6 from /etc/inittab with
"respawn", and then to put all respawnable daemons in runit or s6.
Running either runit or s6 *as a supervisor rather than an init* is
dead-bang easy. Since about 2010 I've been doing something similar: I
ran daemontools on top of sysvinit, and it always worked out great for
me.

SteveT


On Mon, 14 May 2018 02:33:21 -0400
chill...@protonmail.com wrote:

> Afaik openrc is compatible with the init scripts used by all
> packages. Installing it and rebooting should be enough to start using
> openrc. It worked OK for me when I tested it.
> 
> This is probably possible on Jessie as well but I haven't tested that.
> 
> ​Cheers,
> 
> chillfan
> 
> ‐‐‐ Original Message ‐‐‐
> 
> On May 14, 2018 1:52 AM,  wrote:
> 
> > I’ve read that the ascii RC has optional support for OpenRC. How
> > can I switch to this on an existing system to try it out?
> > 
> > Is it simply a matter of running “apt-get install openrc”?
> > 
> > If I switch, will I have to create new service definition files for
> > each existing daemon in /etc/init.d or can it read and reuse those
> > files automatically?
> > 
> > Are there any good tutorials out there on using it, aside from the
> > Gentoo documentation?
> > 
> > Thanks
> > 
> > —Tom
> > 
> > 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] Switching to OpenRC

[chillfan]

Afaik openrc is compatible with the init scripts used by all packages. 
Installing it and rebooting should be enough to start using openrc. It worked 
OK for me when I tested it.

This is probably possible on Jessie as well but I haven't tested that.

​Cheers,

chillfan

‐‐‐ Original Message ‐‐‐

On May 14, 2018 1:52 AM,  wrote:

> I’ve read that the ascii RC has optional support for OpenRC. How can I switch 
> to this on an existing system to try it out?
> 
> Is it simply a matter of running “apt-get install openrc”?
> 
> If I switch, will I have to create new service definition files for each 
> existing daemon in /etc/init.d or can it read and reuse those files 
> automatically?
> 
> Are there any good tutorials out there on using it, aside from the Gentoo 
> documentation?
> 
> Thanks
> 
> —Tom
> 
> 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] Switching

[Rick Moen]

Elaborating on something I wrote, for completeness's sake:

> There is a small chance that Weaver's homedir dotfiles / dotfile
> directory contents from Sid might have problems on Devuan Ascii, 
> because of the effect of back-revving some codebases.  For example, in
> my experience GNOME's dotfiles / dotfile directories have poor backwards
> compatibility (something my employer found out the hard way in the 2000s
> when it tried to use GNOME Desktop with /home as an autofs network
> share).  It doesn't seem likely, but in the event of problems, (1)
> crosscheck using a new test user, and if that user has no problems
> but your regular user does, then (2) try again with the various dotfiles
> and dotfile directories in ~ renamed to *.backup. 

I don't have GNOME on any system so cannot say this is current, but 
in the past these have included:

.gconf
.gnome2
.gnome2_private
.gconf.path.defaults
.gconf.path.mandatory
.gconf.xml.defaults
.gconf.xml.mandatory
.config

The contents of various of these have been known to wreck backwards
compatibility badly enough that a user can no longer login on a host
with a slightly older GNOME revision once a newer GNOME host has touched
the home directory's dotfiles (a situation arising if /home is moved
between distributions or shared via autofs, etc.).  If you encounter
that, either blow away the dotfiles or mv them out of the way.

(And then, I'd personally advise taking off and nuking GNOME from orbit.
It's the only way to be sure.  ;-> )

-- 
Cheers,   « Certainement qui est en droit de vous rendre absurde est
Rick Moen endroit de vous rendre injuste. »  ("Certainly, any one 
r...@linuxmafia.com   who has the power to make you believe absurdities has the 
McQ! (4x80)   power to make you commit injustices.")   -- Voltaire 
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Switching

[Weaver]

On 2017-08-06 08:36, Rick Moen wrote:
> Quoting Joachim Fahrner (j...@fahrner.name):
> 
>> Am 2017-08-05 11:28, schrieb Weaver:
>>
>> >Currently running Debian SID, with separate /, swap, and /home
>> >partitions.
>> >I don't suppose switching is as easy as simply replacing the /
>> >partition
>> >with a new install, preserving the old data?
>>
>> Yes it is easy. Choose the same partition layout in the installer,
>> but only format the root partition. Disable formatting on the home
>> partition. After installation create the users as before, and all
>> should work again as before.
> 
> I second this excellent advice, except Weaver should carefully examine
> the filesystems to be blown away, to spot any exceptions, which is to
> say things that he might wish to preserve.
> 
> When I was relatively new to Debian, I discovered that my server
> installation included a few surprising directory locations, e.g.:
> 
> 1.  /usr/lib included critical GNU Mailman state files, the Apache 
> httpd's CGI-BIN directory, and a number of other such things
> in addition to system libraries.
> 2.  /var included yet more critical GNU Mailman files, MySQL files, etc.
> 
> It's accordingly well worth spending some time exploring the system
> before accidentally blowing away something you might later miss.
> 
> 
> There is a small chance that Weaver's homedir dotfiles / dotfile
> directory contents from Sid might have problems on Devuan Ascii, 
> because of the effect of back-revving some codebases.  For example, in
> my experience GNOME's dotfiles / dotfile directories have poor backwards
> compatibility (something my employer found out the hard way in the 2000s
> when it tried to use GNOME Desktop with /home as an autofs network
> share).  It doesn't seem likely, but in the event of problems, (1)
> crosscheck using a new test user, and if that user has no problems
> but your regular user does, then (2) try again with the various dotfiles
> and dotfile directories in ~ renamed to *.backup.

Thanks to all for different advices, and it would appear that there are
enough differences to employ one of the many different drives I have
lying round to do a separate install, with system wide, readable
directories, then just transfer whichever files I want, being the easier
option.
Thanks to all for time and trouble.

-- 
"It is the duty of the patriot to protect his country from its 
government."
 -- Thomas Paine

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

Re: [DNG] Switching

[Steve Litt]

On Sat, 5 Aug 2017 08:50:29 -0400
Hendrik Boom  wrote:

> On Sat, Aug 05, 2017 at 09:28:02AM +, Weaver wrote:
> > Greetings.
> > Currently running Debian SID, with separate /, swap, and /home
> > partitions.
> > I don't suppose switching is as easy as simply replacing the /
> > partition with a new install, preserving the old data?  
> 
> When I do anything like that I usually copy the system partitions on 
> to now areas of the hard drive, edit /etc/fstab, and make sure both 
> sets of partitions boot properly.
> 
> Then if anything goes wrong with a dist-upgrade, I have an untouched 
> bootable set of partitions to reboot to and use as a fully
> functioning base for recovery.
> 
> And of course, start by backing up your data.  Just in case.
> 
> -- hendrik

I'd start with whatever package manager command lists the packages
I've installed myselfself (rather than having been installed to fulfill
dependencies). I'd put the list in your home directory. Also in my home
directory, I'd put up to the minute copies of /etc/fstab, the output of
the mount command, the output of cat /proc/partitions, a copy of `ip
addr`, a copy of the disk's MBR or UID or whatever it's called, a
copy of /etc/sudoers, and a tarball of /etc, all somewhere under my
home directory..

Then I'd make off-disk backups of /home, and of every other data
directory (stuff I've made or collected myself rather than OS/program
stuff). After that I'd make an off-disk backup of the entire filesystem
starting at /.

Then I'd entirely wipe the disk and perform a brand new install of the
sought version.

Then I'd either mount or create my old /home as /oldhome.

Using the list of manually installed packages from the old install, I'd
make some shellscripts to install the necessary packages. I'd copy all
data directories except /home to the same directory names or
mountpoints. If there are parts of my old home directory that are
obviously data rather than config info, I'd copy those over.

I would NOT copy over old config info. Doing so is how you get ghosts
of operating systems past, complete with bizarre and intermittent
behavior. If I needed to change configs on the new setup, I'd diff them
with the old configs, think about what's going on, and manually make
the changes.

Is my way more work? Heckyeah (as long as the dist-upgrade doesn't
trash everything). Does my way leave me in a situation where every day
for the first month, I'm finding and modifying little things in order
that things work my way? Abso-lutely! Do I take a lot of grief from
people when I articulate my method? You'd better believe it.

But as an elder in the Church of the Known State, I view a from-scratch
install as spring cleaning. I can throw out all those configs and
caches that have been uselessly (and we hope harmlessly) hanging around
since VA Linux was the stock to buy. I consider the fresh install to be
one of the greatest gifts bestowed by non-rolling-release Linuxes.

One more thing: I love almost all aspects of POSIX, but the use of
one's home directory to hold both one's data and one's config is, in my
opinion, a mistake. And it's a mistake unfortunately reenforced by
application defaults concerning where to read and write content.
Because I use my computer as a genuine *personal* computer, I just
store all my content in a tree called /d (sorry LFS). If it were
multiuser, I'd have various names off of /d for this purpose, and tell
people nothing in their /home tree is backed up.

If I absolutely *had to* use /home/slitt for data, I'd put all my data
under /home/slitt/d/, so that I could quickly transfer my genuine data,
while leaving the config stuff where it belongs: On the backup.

After a few days, the tarball of /etc/fstab and /etc/sudoers and other
sensitive backup stuff get erased from /oldhome. I generally
keep /oldhome around until the next fresh install, at which time
this /home because the current /oldhome, and the old /oldhome gets
dropped.
 
SteveT

Steve Litt 
July 2017 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] Switching

[Rick Moen]

Quoting Joachim Fahrner (j...@fahrner.name):

> Am 2017-08-05 11:28, schrieb Weaver:
> 
> >Currently running Debian SID, with separate /, swap, and /home
> >partitions.
> >I don't suppose switching is as easy as simply replacing the /
> >partition
> >with a new install, preserving the old data?
> 
> Yes it is easy. Choose the same partition layout in the installer,
> but only format the root partition. Disable formatting on the home
> partition. After installation create the users as before, and all
> should work again as before.

I second this excellent advice, except Weaver should carefully examine
the filesystems to be blown away, to spot any exceptions, which is to
say things that he might wish to preserve.

When I was relatively new to Debian, I discovered that my server
installation included a few surprising directory locations, e.g.:

1.  /usr/lib included critical GNU Mailman state files, the Apache 
httpd's CGI-BIN directory, and a number of other such things
in addition to system libraries.
2.  /var included yet more critical GNU Mailman files, MySQL files, etc.

It's accordingly well worth spending some time exploring the system
before accidentally blowing away something you might later miss.


There is a small chance that Weaver's homedir dotfiles / dotfile
directory contents from Sid might have problems on Devuan Ascii, 
because of the effect of back-revving some codebases.  For example, in
my experience GNOME's dotfiles / dotfile directories have poor backwards
compatibility (something my employer found out the hard way in the 2000s
when it tried to use GNOME Desktop with /home as an autofs network
share).  It doesn't seem likely, but in the event of problems, (1)
crosscheck using a new test user, and if that user has no problems
but your regular user does, then (2) try again with the various dotfiles
and dotfile directories in ~ renamed to *.backup. 



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

Re: [DNG] Switching

[Hendrik Boom]

On Sat, Aug 05, 2017 at 09:28:02AM +, Weaver wrote:
> Greetings.
> Currently running Debian SID, with separate /, swap, and /home
> partitions.
> I don't suppose switching is as easy as simply replacing the / partition
> with a new install, preserving the old data?

When I do anything like that I usually copy the system partitions on 
to now areas of the hard drive, edit /etc/fstab, and make sure both 
sets of partitions boot properly.

Then if anything goes wrong with a dist-upgrade, I have an untouched 
bootable set of partitions to reboot to and use as a fully functioning 
base for recovery.

And of course, start by backing up your data.  Just in case.

-- hendrik
 
> 
> -- 
> "It is the duty of the patriot to protect his country from its 
> government."
>  -- Thomas Paine
> 
> Registered Linux User: 554515
> ___
> 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] Switching

[Dave Turner]

On 05/08/17 10:39, Joachim Fahrner wrote:

Am 2017-08-05 11:28, schrieb Weaver:


Currently running Debian SID, with separate /, swap, and /home
partitions.
I don't suppose switching is as easy as simply replacing the / partition
with a new install, preserving the old data?


Yes it is easy. Choose the same partition layout in the installer, but 
only format the root partition. Disable formatting on the home 
partition. After installation create the users as before, and all 
should work again as before.


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


Changing from debian sid to devuan jessie or ascii might leave you with 
one or two 'interesting' problems to fix. Most packages in debian sid 
are at a higher version number than packages in devuan jessie or ascii. 
The .config and other setup files you have in ~/ might not work with the 
'down-graded' version of the package you are about to install.


As you are used to the occasional problems we get when running sid I'm 
sure you'll be able to cope!


DaveT

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

Re: [DNG] Switching

[Antony Stone]

On Saturday 05 August 2017 at 11:28:02, Weaver wrote:

> Greetings.
> Currently running Debian SID, with separate /, swap, and /home
> partitions.
> I don't suppose switching is as easy as simply replacing the / partition
> with a new install, preserving the old data?

Depends what you mean by "replacing with a new install".

If you mean "install Devuan on a new partition, change grub and fstab to mount 
that partition under /, and then reboot", then all your data in /home will be 
as it was, certainly - no problems there - however you'll need to reconfigure 
anything/everything you had in /etc and so on.

Personally I would take a backup of / and then try doing a dist-upgrade on it; 
if that works you've kept all your application configs etc; if it almost works 
you might be able to do a bit of manual hacking to sort out a small number of 
packages which didn't quite understand what was happening to them; if it 
really doesn't work then you still have your backup and can revert to that and 
think again.

Please let us know what you do and how it goes.

Welcome to Devuan :)


Antony.

-- 
"It is easy to be blinded to the essential uselessness of them by the sense of 
achievement you get from getting them to work at all. In other words - and 
this is the rock solid principle on which the whole of the Corporation's 
Galaxy-wide success is founded - their fundamental design flaws are completely 
hidden by their superficial design flaws."

 - Douglas Noel Adams

   Please reply to the list;
 please *don't* CC me.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Switching

[Joachim Fahrner]

Am 2017-08-05 11:28, schrieb Weaver:


Currently running Debian SID, with separate /, swap, and /home
partitions.
I don't suppose switching is as easy as simply replacing the / 
partition

with a new install, preserving the old data?


Yes it is easy. Choose the same partition layout in the installer, but 
only format the root partition. Disable formatting on the home 
partition. After installation create the users as before, and all should 
work again as before.


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