Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[exhaust]

In my opinion, this is the best that has been written about init or 
supervisor,


(I'm absolutely agree with this)

"There's no need to search for the perfect init or supervisor. Long ago
we got a bunch of them that are all good enough, and can be combined to
fill almost any need. This continuing search for a perfect init is just
wheel spinning, or perhaps an excuse for profit-driven complexification"


the search for the perfect dictator is not the great idea, at least 
that's what I think


in the same way that there's not a perfect graphical desktop for all the 
people, is sure that there's not a perfect init system for all the 
situations in which you can use a computer


the init system must be something that the people can change in an easy 
way, and so, choose between different options for different situations


sometimes I think that the people that is focused in develop software 
quickly, is the people that search for a perfect init system, so they 
can develop fast software


but fast software is like fast food,

I think that freedom is better that fast software


José María Ávila

On 17.04.2017 03:57, Steve Litt wrote:

On Sun, 16 Apr 2017 19:22:36 -0400
Hendrik Boom  wrote:


On Sun, Apr 16, 2017 at 05:04:18PM -0400, Hendrik Boom wrote:
> On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT
> consult wrote:



> > By the way: maybe we should write an RFC draft for the whole
> > issue ...
>
> Looked for a relevant RFC.  But found only this:
> https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html
> [RFC] [PATCH] notify init daemon when children are reparented to it
>
> But this doesn't seem to be quite what we want, and I can't say I
> have enough context to understand it.

That so-calledRFC seems to be very much in the style of
requiring the init process to be intimately involved in process
supervision actions, which is a strong constraint on what init
systems can be chosen.  And, I suspect, an init system that is so
involved is a potential tool to gradually take over the entire OS, as
systemd has done.


And, in fact, being written in 2008, that so called rfc might have been
either the excuse or the inspiration for systemd.

The "rfc" suffers from a perfectionism related to bikeshedding. Heaven
forbid there's ever a zombie or a process with a 'T' in the ps status
field! We simply MUST make a perfect init or supervisor system: Nothing
less will do. And while we're indulging our perfection, it's important
to remember that simplicity not be a priority at all. We will remain
oblivious to the fact that complexity and lack of encapsulation
creates flaws far worse than the flaws we're moving heaven and earth
to get rid of. And for gosh sakes, let's forget the facts:

THE FACTS

* sysvinit is perfectly workable for the vast majority of users, or at
  least it was until the systemd people influenced the "upstreams" to
  build in code to fail with sysvinit.

* sysvinit plus daemontools is perfectly workable for almost all users
  who are capable of writing a short run file and creating a symlink.
  Daemontools suffers from none of the problems hand-wrung by the
  "rfc", and indeed in a daemontools world (or at least as a runit
  world which I assume is the same), the only process whose parent is
  PID1 is runsvdir (equivalent of daemontools svscanboot). On my
  computer, the executables reparented to PID1 are all stuff spawned by
  dmenu or UMENU, as well as the gvim executable, which doubleforks
  itself automatically. More on this later...

* sysvinit plus OpenRC is perfectly workable for most users who don't
  want daemon respawning.

* sysvinit plus OpenRC plus daemontools is perfectly workable for users
  who want some daemons respawnable.

* A PID1 consisting of an rc file that somehow respawns the virtual
  terminals, background-runs any daemons necessary, and then ends in a
  loop that listens for and handles signals to PID1, is perfectly
  workable for a person operating a small, special purpose computer. If
  I knew how to respawn virtual terminals I'd do just that as a
  demonstration, but respawning gettys is incredibly difficult: It
  often kills the process that tried to respawn it.

* The 83 line Suckless Init spawning an rc file is perfectly workable
  for someone wanting simplicity and the ultimately simple PID1.

Bottom line, all this bikeshedding perfectionism is unnecessary unless
you're a big commercial company trying to turn Free Software into a
cash cow by complexifying it. All the problems were solved long ago, or
are easily solvable by simple, user space addons needing no
modification to the likes of sysvinit, daemontools, runit, s6, Epoch,
OpenRC and the like.

For instance, I have a real problem with zombies and T status processes
created by my use of dmenu and UMENU. It wouldn't be particularly
difficult for me to build a userspace daemontools analog, where one
process parented to PID1 (my analog of svscanboot) would 

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[marc]

> OK, I completely understand. It makes sense. It's pretty slick, too. I
> never would have thought of it.
> 
> Being a daemontools enthusiast, I still don't see fork_parent() as an
> asset in late boot. But I have a feeling it, or something similar,
> could be an asset in different contexts. As a matter of fact, in my
> UMENU program, I might change my backgrounding code to incorporate
> that, and perhaps in doing so eliminate some sleep kludges.

Yay. I am glad that the explanation was helpful. 

regards

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

[DNG] Why I don't want to have Pöttersoft on my system

[Klaus Ethgen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

https://github.com/systemd/systemd/issues/5644

No further comment needed.

Have fun reading. (Found on popular fefe blog)

Regards
   Klaus
- -- 
Klaus Ethgen   http://www.ethgen.ch/
pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
-BEGIN PGP SIGNATURE-
Comment: Charset: ISO-8859-1

iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlj0iFIACgkQpnwKsYAZ
9qzKJQv/a3Z7bcm+omXOwzIcE14U0Xz98RFWKm3Rgqwxva+Y2DmIQHTNjrFkQz8x
MJrYyjydiasRQ2F9/JoJVw9TkWNM+v/t9K394KzN7rQth/5eBawpiAeCgbPaHEE0
W4ambK5j/ZydsH+lzLpPVsrtzbpzK9fe5/Xr3+KUrrF626CnsjbwGqX4a+Gfj2aL
dLOqKA38inyeeodiha0VCIIRWNSxHtv2SGGcf28Pq89U2PGN/NImymPzn6RVN7am
CGksBg+m0nPPgAE+BlAqb74HEOwCKiYZRQATNpvBG0dbbmqqPKoob61Hf2+DSwEs
nms+W7+0nmW8VoKf+gORPScqh2hF6AqImr6qYTo7lXGZga2+iz+EbntB1VI0jZc0
GWTBm7FISc3TccaCw8mQAPAcLPmSZzilVu9j/3DYzLs12ISd4vNYDcDl2XPm0cNe
xZzqseh0YCuCmYOlpoQP+LmDeCe+h/CTp/Wmu4NbzbnXh5fOyVPjhGZ1LWoRkxZW
V0TaOAeg
=7Cfl
-END PGP SIGNATURE-
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Enrico Weigelt, metux IT consult]

On 17.04.2017 16:37, Joachim Fahrner wrote:
> Am 2017-04-17 11:18, schrieb Klaus Ethgen:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> https://github.com/systemd/systemd/issues/5644
>>
>> No further comment needed.
>>
>> Have fun reading. (Found on popular fefe blog)
> 
> ROTFL
> 
> Stupid question: why does systemd implement a rm command? They sold us
> systemd as an init sytem.

Maybe they should just merge in busybox ;-)


--mtx

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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[golinux]

On 2017-04-17 04:18, Klaus Ethgen wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

https://github.com/systemd/systemd/issues/5644

No further comment needed.

Have fun reading. (Found on popular fefe blog)

Regards
   Klaus





The best response submitted to this bug has been removed but I saved it 
and posted to #devuan.  Poster was Buzzsomething:


 "maybe handover dev of this toy to someone with unix experience"

LOL!

golinux

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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[Hendrik Boom]

On Mon, Apr 17, 2017 at 12:33:06PM +0200, marc wrote:
> the kernel thesedays
> allows one to delegate the "default-child-collector" function of 
> init to other processes - that is what the container infrastructure uses.

Which seems to be an effective rebuttal against the argument for systemd 
being a universal service supervisor as pid 1.

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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Joachim Fahrner]

Am 2017-04-17 11:18, schrieb Klaus Ethgen:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

https://github.com/systemd/systemd/issues/5644

No further comment needed.

Have fun reading. (Found on popular fefe blog)


ROTFL

Stupid question: why does systemd implement a rm command? They sold us 
systemd as an init sytem.


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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Steve Litt]

On Mon, 17 Apr 2017 16:37:29 +0200
Joachim Fahrner  wrote:

> Am 2017-04-17 11:18, schrieb Klaus Ethgen:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > https://github.com/systemd/systemd/issues/5644
> > 
> > No further comment needed.
> > 
> > Have fun reading. (Found on popular fefe blog)  
> 
> ROTFL
> 
> Stupid question: why does systemd implement a rm command? They sold
> us systemd as an init sytem.
> 
> Jochen

I don't mean to seem conceited (actually I'm proud to be conceited),
but I answered this question in June 2016, in a private email to two
individuals. Here's the relevant part that answers your question:

==
What's next? Nobody knows, but it will be something, because
they won't quit until the cat command is dependent on systemd.
==
 
SteveT

Steve Litt 
April 2017 featured book: Troubleshooting Techniques
 of the Successful Technologist
http://www.troubleshooters.com/techniques
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[Didier Kryn]

Le 14/04/2017 à 10:57, Enrico Weigelt, metux IT consult a écrit :

* srvmgt_report_state(...)
   --> report the service state to the supervisor
   --> states could be eg.
* SRVMGT_STATE_STARTUP -- still within the startup phase
* SRVMGT_STATE_READY_LOCAL -- ready for local clients only
* SRVMGT_STATE_READY_ALL   -- ready for all clients
* SRVMGT_STATE_BUSY-- too busy to process new requests
* SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing
   queued requests
* SRVMGT_STATE_DEFERRED-- temporarily can't accept new
   requests (eg. overload)
* SRVMGT_STATE_WAITING -- wait for resource (eg. printer
   needs paper or ink)
* SRVMGT_STATE_OFFLINE -- completely offline (eg. due some
   fatal error)



Reporting state is usefull, but this could be achieved by writing 
the state in plain text to stdout. It is up to the supervisr to 
establish a pipe between itself and the daemon's stdout. If there isn't 
a supervisor, then writing to /dev/null doesn't harm. Or why not write 
to a file in /run? Anyway, I don't think it deserves to link to a 
library to perform such a simple thing.


Didier


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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Aldemir Akpinar]

On 17 April 2017 at 12:18, Klaus Ethgen  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> https://github.com/systemd/systemd/issues/5644
>
> No further comment needed.
>
> Have fun reading. (Found on popular fefe blog)
>
> Regards
>Klaus
> - --
> Klaus Ethgen   http://www.ethgen.ch/
> pub  4096R/4E20AF1C 2011-05-16Klaus Ethgen 
> Fingerprint: 85D4 CA42 952C 949B 1753  62B3 79D0 B06F 4E20 AF1C
> -BEGIN PGP SIGNATURE-
> Comment: Charset: ISO-8859-1
>
> iQGzBAEBCgAdFiEEMWF28vh4/UMJJLQEpnwKsYAZ9qwFAlj0iFIACgkQpnwKsYAZ
> 9qzKJQv/a3Z7bcm+omXOwzIcE14U0Xz98RFWKm3Rgqwxva+Y2DmIQHTNjrFkQz8x
> MJrYyjydiasRQ2F9/JoJVw9TkWNM+v/t9K394KzN7rQth/5eBawpiAeCgbPaHEE0
> W4ambK5j/ZydsH+lzLpPVsrtzbpzK9fe5/Xr3+KUrrF626CnsjbwGqX4a+Gfj2aL
> dLOqKA38inyeeodiha0VCIIRWNSxHtv2SGGcf28Pq89U2PGN/NImymPzn6RVN7am
> CGksBg+m0nPPgAE+BlAqb74HEOwCKiYZRQATNpvBG0dbbmqqPKoob61Hf2+DSwEs
> nms+W7+0nmW8VoKf+gORPScqh2hF6AqImr6qYTo7lXGZga2+iz+EbntB1VI0jZc0
> GWTBm7FISc3TccaCw8mQAPAcLPmSZzilVu9j/3DYzLs12ISd4vNYDcDl2XPm0cNe
> xZzqseh0YCuCmYOlpoQP+LmDeCe+h/CTp/Wmu4NbzbnXh5fOyVPjhGZ1LWoRkxZW
> V0TaOAeg
> =7Cfl
> -END PGP SIGNATURE-
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>



It also has the grand finale:

poettering  locked and limited conversation
to collaborators 2 hours ago


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

[DNG] Manjaro dropping consolekit

[Adam]

FYI, for those that are following the non-systemd distros, it seems that
manjaro is dropping support for consolekit in its openrc spin, and will
now require you to use elogind...

https://forum.manjaro.org/t/switch-from-consolekit-to-elogind/19412/45

Cheers,

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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[marc]

> > I wonder why that general task of daemonizing cant just be done in a
> > generic separate program and left out of the individual daemons.
> > So, everybody can decide on this own how to actually start/manage
> > the daemons - some use a supervisor, some just call via a daemonizer
> > program from init scripts, etc, etc.

Only the program itself[*] knows when the transition between it being
started and it being ready has happened. If the program daemonises
itself, it can communicate this by having the parent exit at the
correct point. 

[*]For a generic program to understand this, there would have
to be some sort of convention (close stderr seems to be sanest
I could think of). But no convention has been established yet
and we have had some major boneheaded ideas (child processes 
stops itself when ready (WTF!?), write a magic sequence to
stdout (fugly?)). Hiding this behind some library call makes it 
worse, as it ties things to a particular implementation.

The daemontools advocates take the view that this notification
when ready isn't strictly needed, as the dependent tasks should
be smart enough to retry/persist. They have a point, but it can 
mask the actual source of failures and isn't workable for hard
dependencies (fs not mounted).

> > By the way: maybe we should write an RFC draft for the whole issue ...
> 
> Looked for a relevant RFC.  But found only this: 
> https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html
> [RFC] [PATCH] notify init daemon when children are reparented to it
> 
> But this doesn't seem to be quite what we want, and I can't say I have 
> enough context to understand it.

It isn't what we want. Sadly some of the statements are outdated
or something between misleading or incorrect. For example:

*> *but* due to a quirk of POSIX, if it were to be made to open() a tty
*> device, it would end up owning it!  FAIL.

POSIX anticipates this problem and provides a O_NOCTTY to the open
call to prevent this problem happening. So NO FAIL.

*> If there's two apache2 daemons running (in different chroots, or for
*> different IPs or ports?), it [init] doesn't know which of the two died 
*> because the PID that died is unknown to it.

This isn't the case. With a sigaction hander init can retrieve the pid
and uid of the exited process. Also outdated because the kernel thesedays
allows one to delegate the "default-child-collector" function of 
init to other processes - that is what the container infrastructure uses.

> It seems to follow the practice of creating two processes for a 
> daemon, a parent and a child, and then orphaning the child.  
> This is not what we seem to be discussing here, and leads to 
> init having nontrivial ongoing work.

Hmm... it is a bit of a tradeoff. This approach makes it possible
to indicate readiness and thus order the system startup properly. 
It is also needed when random users need to daemonise their
tasks (eg screen). 

On the other hand it makes automated respawning tricky. However it 
is an open question if well written daemons need to ever respawn. 
Respawning a crashed daemon favours availability over all other
considerations. And uncontrolled respawn is a fork bomb, an oracle
for an attacker, a log file filler, a database corruptor, etc, etc.

> And although it says [RFC] in the title, it doesn't seem to be an 
> official RFC.

Anybody can make a Request For Comments :-) (The RFCs of the IETF 
are different, they don't really relate to OS internals)

Anyway here is my request for comments: If you want to signal that
your daemon is ready close stderr, even if you don't do a fork().

Then the proposed generic wrapper can notice that.

regards

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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[Hendrik Boom]

On Sun, Apr 16, 2017 at 09:57:38PM -0400, Steve Litt wrote:
> On Sun, 16 Apr 2017 19:22:36 -0400
> Hendrik Boom  wrote:
> 
> > On Sun, Apr 16, 2017 at 05:04:18PM -0400, Hendrik Boom wrote:
> > > On Sun, Apr 16, 2017 at 09:59:36PM +0200, Enrico Weigelt, metux IT
> > > consult wrote:  
> 
> > > > By the way: maybe we should write an RFC draft for the whole
> > > > issue ...  
> > > 
> > > Looked for a relevant RFC.  But found only this: 
> > > https://lists.ubuntu.com/archives/kernel-team/2008-December/003628.html
> > > [RFC] [PATCH] notify init daemon when children are reparented to it
> > > 
> > > But this doesn't seem to be quite what we want, and I can't say I
> > > have enough context to understand it.  
> > 
> > That so-calledRFC seems to be very much in the style of 
> > requiring the init process to be intimately involved in process 
> > supervision actions, which is a strong constraint on what init
> > systems can be chosen.  And, I suspect, an init system that is so
> > involved is a potential tool to gradually take over the entire OS, as
> > systemd has done.
> 
> And, in fact, being written in 2008, that so called rfc might have been
> either the excuse or the inspiration for systemd.
> 
> The "rfc" suffers from a perfectionism related to bikeshedding. Heaven
> forbid there's ever a zombie or a process with a 'T' in the ps status
> field! We simply MUST make a perfect init or supervisor system: Nothing
> less will do. And while we're indulging our perfection, it's important
> to remember that simplicity not be a priority at all. We will remain
> oblivious to the fact that complexity and lack of encapsulation
> creates flaws far worse than the flaws we're moving heaven and earth
> to get rid of. And for gosh sakes, let's forget the facts:
> 
> THE FACTS
> 
> * sysvinit is perfectly workable for the vast majority of users, or at
>   least it was until the systemd people influenced the "upstreams" to
>   build in code to fail with sysvinit.
> 
> * sysvinit plus daemontools is perfectly workable for almost all users
>   who are capable of writing a short run file and creating a symlink.
>   Daemontools suffers from none of the problems hand-wrung by the
>   "rfc", and indeed in a daemontools world (or at least as a runit
>   world which I assume is the same), the only process whose parent is
>   PID1 is runsvdir (equivalent of daemontools svscanboot). On my
>   computer, the executables reparented to PID1 are all stuff spawned by
>   dmenu or UMENU, as well as the gvim executable, which doubleforks
>   itself automatically. More on this later...
> 
> * sysvinit plus OpenRC is perfectly workable for most users who don't
>   want daemon respawning.
> 
> * sysvinit plus OpenRC plus daemontools is perfectly workable for users
>   who want some daemons respawnable.
> 
> * A PID1 consisting of an rc file that somehow respawns the virtual
>   terminals, background-runs any daemons necessary, and then ends in a
>   loop that listens for and handles signals to PID1, is perfectly
>   workable for a person operating a small, special purpose computer. If
>   I knew how to respawn virtual terminals I'd do just that as a
>   demonstration, but respawning gettys is incredibly difficult: It
>   often kills the process that tried to respawn it.
> 
> * The 83 line Suckless Init spawning an rc file is perfectly workable
>   for someone wanting simplicity and the ultimately simple PID1.
> 
> Bottom line, all this bikeshedding perfectionism is unnecessary unless
> you're a big commercial company trying to turn Free Software into a
> cash cow by complexifying it. All the problems were solved long ago, or
> are easily solvable by simple, user space addons needing no
> modification to the likes of sysvinit, daemontools, runit, s6, Epoch,
> OpenRC and the like.
> 
> For instance, I have a real problem with zombies and T status processes
> created by my use of dmenu and UMENU. It wouldn't be particularly
> difficult for me to build a userspace daemontools analog, where one
> process parented to PID1 (my analog of svscanboot) would spin around
> listening for commands and/or scripts to run in such a way that IT was
> the parent, or perhaps via analogs of svscan that don't respawn. I
> could then modify dmenu and UMENU to message my daemon in order to run
> commands. Notice the idea in this paragraph requires not one
> modification to whatever "init system" you're using. And it's simple
> enough that even I could implement it, given the time.
> 
> There's no need to search for the perfect init or supervisor. Long ago
> we got a bunch of them that are all good enough, and can be combined to
> fill almost any need. This continuing search for a perfect init is just
> wheel spinning, or perhaps an excuse for profit-driven complexification.

Thank you for this eloquent and extensive statement of principle.

-- hendrik
___
Dng mailing list
Dng@lists.dyne.org

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Dan Purgert]

On 04/17/2017 06:59 AM, Dan Purgert wrote:
> bwah!?
> 
> How does one not know that rm will tell you off if you try to do
> something daft like rm -rf  ?
> 
> I mean, yeah, maybe it was a pitfall a few decades ago, when computers
> were handled by "trained professionals" ...
> 
> On 04/17/2017 05:18 AM, Klaus Ethgen wrote:
>> https://github.com/systemd/systemd/issues/5644
>>
>> No further comment needed.
>>
>> Have fun reading. (Found on popular fefe blog)
>>
>> Regards
>>Klaus


Hm, that's interesting, seems I torched some setting in my mail client
and now it's decided to top post.  My apologies for missing that.



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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Dan Purgert]

bwah!?

How does one not know that rm will tell you off if you try to do
something daft like rm -rf  ?

I mean, yeah, maybe it was a pitfall a few decades ago, when computers
were handled by "trained professionals" ...

On 04/17/2017 05:18 AM, Klaus Ethgen wrote:
> https://github.com/systemd/systemd/issues/5644
> 
> No further comment needed.
> 
> Have fun reading. (Found on popular fefe blog)
> 
> Regards
>Klaus
> ___
> Dng mailing list
> Dng@lists.dyne.org
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> 



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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Enrico Weigelt, metux IT consult]

On 17.04.2017 17:11, goli...@dyne.org wrote:

> The best response submitted to this bug has been removed but I saved it
> and posted to #devuan.  Poster was Buzzsomething:
> 
>  "maybe handover dev of this toy to someone with unix experience"

Ah, that explains why lennart closed the comments.

--mtx

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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Arnt Gulbrandsen]

Aldemir Akpinar writes:

It also has the grand finale:

poettering locked and limited conversation to collaborators 2 hours ago


Makes sense. Nothing new was being said, just old stuff repeated, and the 
bug was fixed three weeks ago.


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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[golinux]

On 2017-04-17 11:22, Enrico Weigelt, metux IT consult wrote:

On 17.04.2017 17:11, goli...@dyne.org wrote:

The best response submitted to this bug has been removed but I saved 
it

and posted to #devuan.  Poster was Buzzsomething:

 "maybe handover dev of this toy to someone with unix experience"


Ah, that explains why lennart closed the comments.

--mtx
___


No that explains why he deleted it.  Closing the comments was overkill.  
Pottypoo's first comment received 51 :thumbsdown:  IMO that's a better 
reason to shut things down.  The name of the commenter quoted above was 
in that list - buzztiaan.


golinux

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

Re: [DNG] /etc/debian_version

[Jaromil]

On Mon, 17 Apr 2017, Emiliano Marini wrote:

>Oops, I didn't know that missing /etc/debian_version was a bug
>and sent a PR to certbot on GitHub to support Devuan:
>[1]https://github.com/certbot/certbot/pull/4515

thanks Emiliano! ideally we'd want all sorts of services reading that
file to acknowledge Devuan, since our distro may diverge from Debian
in a somehow far future, so I guess it should be a slow collective
effort to let more projects know the existance of /etc/devuan_version,
which we can anyway symlink as long as there aren't huge differences
with Debian (and who knows... at this pace they may rly go bonkers...)

ciao

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

[DNG] Another minor Debian vestige

[Hendrik Boom]

I just installed lighttpd, and it properly served its front page, 
which tells me I should configure the system to show my web content 
instead of the frot page.

But the front page also says,

> This is a placeholder page installed by the Debian release of the 
> Lighttpd server package.
> 
> This computer has installed the Debian GNU/Linux operating system, but 
> it has nothing to do with the Debian Project. Please do not contact 
> the Debian Project about it.
>
> If you find a bug in this Lighttpd package, or in Lighttpd itself, 
> please file a bug report on it. Instructions on doing this, and the 
> list of known bugs of this package, can be found in the Debian Bug 
> Tracking System. 

This is, of course not quite correct.  My conputer runs Devuan 
GNU/Linux, not Debian. 

It is probably not worth fixing this unless we have other reasons to 
open up lighttpd.

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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[Simon Hobson]

exha...@posteo.net wrote:

> In my opinion, this is the best that has been written about init or 
> supervisor,

+1

> (I'm absolutely agree with this)
> 
> "There's no need to search for the perfect init or supervisor. Long ago
> we got a bunch of them that are all good enough, and can be combined to
> fill almost any need. This continuing search for a perfect init is just
> wheel spinning, or perhaps an excuse for profit-driven complexification"

Absolutely.
And I confess it's something I fall prey to from time to time - seeking to "do 
it right" which sometimes results in not doing it at all. Lets just say there 
was "some disagreement" between myself and SWMBO as to what "decorate the spare 
bedroom" means - though at the end of it (a year per room, two rooms so far !) 
she's been happy with the results :-)

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

Re: [DNG] tiny service state api [WAS: Fwd: init system agnosticism]

[Alessandro Selli]

On Fri, 14 Apr 2017 at 12:06:44 +0200 (CEST)
k...@aspodata.se wrote:

> Enrico Weigelt:
> ...
> > Let's just take some example: libsrvmgt with funcs like that:
> > 
> > * srvmgt_daemonize()  
> >   --> detach from controlling terminal, etc  
>
> Why do any monitor program need to know if the program has detached
> or not, the only thing it needs to know is the pid and the state,
> which would/could be provided by the *_state() functions,
> or am I wrong ?

  All daemons detach from the control terminal.  The monitor and the
daemon must coordinate each other about who's doing the detach to avoid
launch time failures.

> > * srvmgt_droppriv(...)  
> >   --> drop root privileges (if we are still root)
> >   --> several versions, eg. with fetching the target uid/gid from env  
>
> Given the pid, it isn't that hard for a monitor to find the uid/gid of 
> the process, why has this have to go through the monitor ?

  I don't think here the monitor is used to extract process info (such
as user/group it's running under), rather the environment is used to
determine what user:group the daemon must be set to by the monitor.

> Also, given that you can do the above without this lib opens gives the
> program the option too cheat, say, if the monitor wishes to have a
> tight control of the process.

  It depends by where is that environment set.  It might be a config
file.  You're supposed to trust your config files.

[...]

> > * srvmgt_report_state(...)
>   --> report the service state to the supervisor  
> ...
>
> There could be something like *_a_would_like_to_be_monitored() and
> *_I_wish_to_regain_my_free_will().

  The monitor is supposed to implement local security/service
continuity/resource allocation policies the daemon must not be able to
bail itself out of.

> >  --> states could be eg.  
> > * SRVMGT_STATE_STARTUP -- still within the startup phase
> > * SRVMGT_STATE_READY_LOCAL -- ready for local clients only
> > * SRVMGT_STATE_READY_ALL   -- ready for all clients
> > * SRVMGT_STATE_BUSY-- too busy to process new requests
> > * SRVMGT_STATE_SHUTDOWN-- shutting down, still finishing
> >  queued requests
> > * SRVMGT_STATE_DEFERRED-- temporarily can't accept new
> >  requests (eg. overload)
> > * SRVMGT_STATE_WAITING -- wait for resource (eg. printer
> >  needs paper or ink)
> > * SRVMGT_STATE_OFFLINE -- completely offline (eg. due some
> >  fatal error)  
>
> Given the choises given, it seems that the target of the monitor is
> network servers. Couldn't the monitor find out the ready_local,
> ready_all and shutdown by itself by monitoring which ports are open ?

  The monitor is not supposed to always grant any daemon any port it
wishes.  Monitors are there also to prevent daemons to do just as they
will.  One thing is to trust the monitor, another thing is to trust the
whole collection of deamons it manages.

[...]

> ///
>
> And, what if the monitor cannot trust the program it monitors ?
> Given the lib suggestion, it seems that we are trusting the program.

  Well... what if you do not trust the monitor?
What do you mean by what you wrote?  How do you think you can teach a
monitor if some program can be trusted?  I don't think I will love a
monitor that is not going to start, say, the sshd daemon because it
thinks it cannot be trusted. I must know what it means by this (bad to
system security? to the available resourses?), I want to know the
specific reason it believes sshd is bad and I want this behaviour to be
configurable.

> But what if if we don't know if we can trust the walues provided by
> the program, the we have to check what the program is really doing,
> and then the lib have no value, isn't that so ?

  Could you please provide us with an example of untrusted
behaviour/program provided data that the monitor is supposed to detect
and handle accordingly?


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

Re: [DNG] Why I don't want to have Pöttersoft on my system

[Joachim Fahrner]

Am 2017-04-17 17:11, schrieb goli...@dyne.org:


 "maybe handover dev of this toy to someone with unix experience"

LOL!


My favourite rant was from Linus Torvalds:
https://www.theregister.co.uk/2014/04/05/torvalds_sievers_dust_up/

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

Re: [DNG] Manjaro dropping consolekit

[Alessandro Selli]

Il 17/04/2017 15:35, Adam ha scritto:
> FYI, for those that are following the non-systemd distros, it seems that
> manjaro is dropping support for consolekit in its openrc spin, and will
> now require you to use elogind...
>
> https://forum.manjaro.org/t/switch-from-consolekit-to-elogind/19412/45

«I plan a elogind default on openrc instead of consolekit.
This should give working wayland sessions on non systemd.»

  Sounds good, even if I don't know about elogind.



-- 
Alessandro Selli 
Tel. 3701355486
VOIP SIP: dhatarat...@ekiga.net
Chiave PGP/GPG key: B7FD89FD

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

Re: [DNG] /etc/debian_version

[Emiliano Marini]

Oops, I didn't know that missing /etc/debian_version was a bug and sent a
PR to certbot on GitHub to support Devuan:

https://github.com/certbot/certbot/pull/4515

It failed on a fresh Jessie install because it hadn't /etc/debian_version,
and I tought that was right for future releases, so I didn't want to
symlink /etc/devuan_version.

With a little change on certbot-auto I was able to successfuly create a
Let's Encrypt certificate from my Devuan box.

Cheers,
Emiliano.

On Sat, Apr 15, 2017 at 8:06 AM, Jaromil  wrote:

> On Fri, 14 Apr 2017, Gregory Nowak wrote:
>
> > cat: /etc/debian_version: no such file or directory.
> >
> > I can probably put that file back, and all would be good. However,
> > my question is what is still looking for that file during apt-get
> > dist-upgrade, and more to the point, how can I make this message
> > during upgrades stop without bringing back /etc/debian_version?
>
> Devuan does have already its own /etc/devuan_version which can be
> symlinked from /etc/debian_version especially since the correct value
> its jessie for both.
>
> Yet I believe we should file this as a bug as /etc/debian_version is
> not there on new installs. The /etc/debian_version file is checked by
> an enormous quantity of scripts in all sorts of deployements, we have
> encountered this problem also with Vagrant, that I remember. So we
> shall keep that file around and fill it with the Debian version we use
> to fallback packages in each release, that is so far:
>
> Jessie -> Jessie
> Ascii -> Stretch
>
> After Ascii is yet to be seen if we'll keep relying on Debian.
>
> ciao
>
> ___
> 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] tiny service state api [WAS: Fwd: init system agnosticism]

[Alessandro Selli]

On 17/04/2017 at 03:57, Steve Litt wrote:

[...]

> There's no need to search for the perfect init or supervisor. Long ago
> we got a bunch of them that are all good enough, and can be combined to
> fill almost any need. This continuing search for a perfect init is just
> wheel spinning, or perhaps an excuse for profit-driven complexification.

  I fully agree.  Than you for having put down such a good manifesto.



-- 
Alessandro Selli 
Tel. 3701355486
VOIP SIP: dhatarat...@ekiga.net
Chiave PGP/GPG key: B7FD89FD

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