[DNG] problem installing postgresql

2017-04-18 Thread Hendrik Boom 
In the middle of installing several packages using
apt-get install postgresql ruby-sass
I get a message.

Setting up postgresql-common (165+deb8u2) ...
supported-versions: WARNING! Unknown distribution: devuan
/usr/share/postgresql-common/supported-versions: 64: 
/usr/share/postgresql-common/supported-versions: ID_LIKE: parameter not set
/usr/share/postgresql-common/supported-versions: 67: 
/usr/share/postgresql-common/supported-versions: ID_LIKE: parameter not set
Please submit this as a bug report to your distribution.
Adding user postgres to group ssl-cert

Evidently postgresql doesn't know about devuan.
Could it be because I don't have a /etc/debian_version file, but only 
a /etc/devuan_version file?  Or does it discover I'm using devuan by 
other means?

-- 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]

2017-04-18 Thread KatolaZ 
On Tue, Apr 18, 2017 at 11:10:24PM +0200, Alessandro Selli wrote:
> On 18/04/2017 at 19:01, KatolaZ wrote:
> > On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote:
> >
> > [cut]
> >
> >>> There is really no other reasonable alternative, IMVHO.
> >>   Yes, there is.  It's called a good compromise.  Then, outside of it,
> >> you find the purists and the extremists.
> >>
> > We have seen what an irresistible avalanche of compromises has created
> > in the systemd camp.
> 
>   Today I read someone (perhaps Enrico Weigelt) stating that one of
> systemd's
> pitfalls is wanting to be the perfect init.  I agree.  systemd does not
> compromise, it wants thing to be done the way it wants, it forces all
> userland to comply to it's dictates.  systemd is the opposite of compromise,
> it's dictatorial.
> 
> > It turns out that I am a purist. And an extremist.
> 
>   This is one of the best recipies for failure.
> 

It would be very good if you would like to actually contribute to
Devuan :) There are lots of thigs to do, besides deciding who will
fail and who will succeed. 

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  ]


signature.asc
Description: Digital signature
___
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]

2017-04-18 Thread Alessandro Selli 
On 18/04/2017 at 19:01, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 06:48:31PM +0200, Alessandro Selli wrote:
>
> [cut]
>
>>> There is really no other reasonable alternative, IMVHO.
>>   Yes, there is.  It's called a good compromise.  Then, outside of it,
>> you find the purists and the extremists.
>>
> We have seen what an irresistible avalanche of compromises has created
> in the systemd camp.

  Today I read someone (perhaps Enrico Weigelt) stating that one of
systemd's
pitfalls is wanting to be the perfect init.  I agree.  systemd does not
compromise, it wants thing to be done the way it wants, it forces all
userland to comply to it's dictates.  systemd is the opposite of compromise,
it's dictatorial.

> It turns out that I am a purist. And an extremist.

  This is one of the best recipies for failure.

>  And I am not at all
> interested in blurry concepts like "market shares",

  If this feeling is shared by over 25% of Devuan's managers and
developers, it's going to be the 1000th distribution so nice, so good, so
"perfect" it's going to starve out of it's own failure to gain any
significant foothold into the marketplace.  You might dislike the market as
much as you can, but that's what feeds projects and keeps distributions
alive.  Voluntary donations might get you started, but will not prop you up
indefinitely into a viable OS capable of sustaining itself.

>  since the quest to
> let Linux conquest "new market shares" has only brought problems and
> created monsters. Get your conclusions.

  The quest to get Linux into as many lucrative markets as possible has made
it what it is, that is a success, unlike worthy, perfectionist projects that
failed nonetheless, like Plan9 or many of the successors to OpenSolaris.
Who mentioned GNU?


-- 
Alessandro Selli 
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] tiny service state api [WAS: Fwd: init system agnosticism]

2017-04-18 Thread Alessandro Selli 
On 18/04/2017 at 16:16, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote:
>> kato...@freaknet.org writes:
>>> Unfortunately we are already paying the consequences of badly-written
>>> software implementing oddly-designed solutions to non-existing
>>> problems...
>> Indeed. But what's your point?
>>
> Oh, you are right, I didn't make it explicit: my humble opinion is
> that the whole thread is not particularly interesting or useful in
> this context, since all this fuss about monitoring/supervision boils
> down to two alternative options:
>
>   a) you *really* need *strict* monitoring/supervsion. In this case,
>   you *don't* use a unix-like operating system, since you are always
>   left at least with the problem of monitoring the monitor (or
>   supervising the supervisor). But this is not a real problem, since
>   in those environments where *strict* supervision/monitoring is
>   *really* necessary, unix-like systems are rarely used, if ever, and
>   the scheduler also acts as a monitor/supervisor. So if you need
>   *real* *strict* monitoring, the whole topic is off-topic here.

  I do not agree, as Linux systems are employed both in real-time
scenarios (though I admit this is a really niche use case) and in High
Availability infrastructures.

>   b) you need *loose* monitoring/supervision. In this case, you pick
>   and choose among what is available, or write your own. In any case,
>   you get a monitor/supervisor running as a user process on top of any
>   general-purpose operating system, possibly a unix-like one, and your
>   applications must still be able to deal with faults,
>   inconsistencies, delays, and other issues. And sometimes you will
>   still need manual intervention nonetheless. The "everything will be
>   all right" theme is just dust in your eyes, because things are never
>   going to be all right all the time.

  This is an argument that sounds as an excuse to me: "Since you'll
never get perfection, just do nothing."  Everyone knows that even top500
supercomputers do need some manual intervention from time to time.  This
is not a good reason to put the sysadmin in charge of manually managing
all the processes and events that they produce.  Some OS could go this
way, of course, free to.  But you know very well that such an OS, though
philosophically and academically fine and technically elegantly
constructed, is not going to win any significant market share, as today
everywhere the utmost of automation is a prime requirement.

> There is really no other reasonable alternative, IMVHO.

  Yes, there is.  It's called a good compromise.  Then, outside of it,
you find the purists and the extremists.


Alessandro

___
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]

2017-04-18 Thread Alessandro Selli 
On 18/04/2017 at 14:46, k...@aspodata.se wrote:

[...]

> Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in
> either camp, end case.

  This is well *if* the daemon has -f and does daemon().  I know the
only programs that do not do it are those that were not intended to be
run as daemons, still from time to time people do that, with netcat for
instance.

> Why srvmgt_droppriv(), either accept that the process set's it itself
> or force it to some uid:gid, what is it more to it ?

  "What if you do not trust the program?" (quote)

  Then you answered yourself already: "force it to some uid:gid": this
is the monitor's job.  One of them.

> Why srvmgt_report_state(), just do a normal query to the process and
> you'll know if it is ready to serve you or not,

  This way you only know that the process is up, not that "it is ready
to serve you or not".  I'm sure you've had experiences of processes that
are running but are not delivering the services you expected from them.

>  if you want to know
> if it is up to speed, do a benchmark, if you want to test the 
> integrity, do a regression test; what is it more to it ?

  Knowing if it is ready to serve you or not", for instance.  Learning
if it got stuck on something, if that is temporary or definitive, if
it's best to kill it or maybe raise it's allotted max number of open
files.  Or just write a line in the logs and let the sysadmin pick it up
and see for himself what to do.

  If you want an init that only launches programs and daemons and as
soon forgets all about them, fine.  I'm not in principle against such a
minimalistic init.  Just don't call it a monitor thought, 'cause it ain't.


Alessandro

___
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]

2017-04-18 Thread Alessandro Selli 
On 18/04/2017 at 16:42, k...@aspodata.se wrote:
> Alessandro:
>> On 18/04/2017 at 15:11, k...@aspodata.se wrote:
>>> Alessandro Selli:
>>> ...
 And
 what I don't like of Karl Aspo's idea is that it takes any instrument of
 policy checking and enforcing out of the monitor, which ends up not
 being able to monitor anything, it becomes just a shell: fire and forget.
>>> I honestly do not understand what I have written which gives you that idé.
>> Your many lines that the monitor is not to do any monitoring.  Like:
>> "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,".
> You cut out the thing after the "," which makes that a question for 
> someone else to fill in the blanks, the things that's not obvious
> to me.

  I got you had a question, I did understand you had no idea why would
"any monitor program need to know if the program has detached or not". 
Again I quote myself:

«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.»

  It's been obvious to all Unix sysadmins for thirty sound years, if
it's still not clear to you I think I must give up.

> If a process knows the pid of another process and have sufficient 
> rights, can it not manage that process or is there anything else it 
> needs to know, what am I missing ?

  It manages them based on what?  Local config files, events
transmitted, signals?  You're missing the whole "monitoring" and
policing the monitor does besides launching the daemon.


Alessandro

___
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]

2017-04-18 Thread karl 
Alessandro:
> On 18/04/2017 at 15:11, k...@aspodata.se wrote:
> > Alessandro Selli:
> > ...
> >> And
> >> what I don't like of Karl Aspo's idea is that it takes any instrument of
> >> policy checking and enforcing out of the monitor, which ends up not
> >> being able to monitor anything, it becomes just a shell: fire and forget.
> > I honestly do not understand what I have written which gives you that idé.
> Your many lines that the monitor is not to do any monitoring.  Like:
> "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,".

You cut out the thing after the "," which makes that a question for 
someone else to fill in the blanks, the things that's not obvious
to me.

If a process knows the pid of another process and have sufficient 
rights, can it not manage that process or is there anything else it 
needs to know, what am I missing ?

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
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]

2017-04-18 Thread karl 
Katola2:
> On Tue, Apr 18, 2017 at 03:11:51PM +0200, k...@aspodata.se wrote:
...
> > If I can get a value from the kernel instead of from the process,
> > I'd take the kernel value.
> > 
> > Why do a process have to query the kernel to get a value and then 
> > sending it to a monitor over a communication link; why don't the
> > monitor query the kernel itself, saving one step.

> I genuinely don't understand why the kernel should know about the
> internals of running processes, or get notified if a process is
...

What is the problem with you guys, I did write "if". That "if" applies 
to thing like PID, uid, gid and such of processes, not wheter they are 
in some sense ready or not. Please, don't continously misinterpret me.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
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]

2017-04-18 Thread KatolaZ 
On Tue, Apr 18, 2017 at 02:48:54PM +0100, Arnt Gulbrandsen wrote:
> kato...@freaknet.org writes:
> >Unfortunately we are already paying the consequences of badly-written
> >software implementing oddly-designed solutions to non-existing
> >problems...
> 
> Indeed. But what's your point?
> 

Oh, you are right, I didn't make it explicit: my humble opinion is
that the whole thread is not particularly interesting or useful in
this context, since all this fuss about monitoring/supervision boils
down to two alternative options:

  a) you *really* need *strict* monitoring/supervsion. In this case,
  you *don't* use a unix-like operating system, since you are always
  left at least with the problem of monitoring the monitor (or
  supervising the supervisor). But this is not a real problem, since
  in those environments where *strict* supervision/monitoring is
  *really* necessary, unix-like systems are rarely used, if ever, and
  the scheduler also acts as a monitor/supervisor. So if you need
  *real* *strict* monitoring, the whole topic is off-topic here.

  b) you need *loose* monitoring/supervision. In this case, you pick
  and choose among what is available, or write your own. In any case,
  you get a monitor/supervisor running as a user process on top of any
  general-purpose operating system, possibly a unix-like one, and your
  applications must still be able to deal with faults,
  inconsistencies, delays, and other issues. And sometimes you will
  still need manual intervention nonetheless. The "everything will be
  all right" theme is just dust in your eyes, because things are never
  going to be all right all the time.

There is really no other reasonable alternative, IMVHO. But I am not
an expert in the field (though I am quite happy about not being an
expert, having seen what the "experts in the field" have been able to
come up with in the last couple of years...)

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  ]


signature.asc
Description: Digital signature
___
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]

2017-04-18 Thread Alessandro Selli 


On 18/04/2017 at 15:11, k...@aspodata.se wrote:
> Alessandro Selli:
> ...
>> And
>> what I don't like of Karl Aspo's idea is that it takes any instrument of
>> policy checking and enforcing out of the monitor, which ends up not
>> being able to monitor anything, it becomes just a shell: fire and forget.
> I honestly do not understand what I have written which gives you that idé.

  Your many lines that the monitor is not to do any monitoring.  Like:
"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,".

>> I was also been ironic on Aspo, as many times he can only counter
>> another person's ideas asking "What if  cannot be trusted?",
>> as if this constitutes a valid argument against being able to set
>> policies for the monitor to enforce on the daemons it runs.
> If I can get a value from the kernel instead of from the process,
> I'd take the kernel value.

  What value?  Of course there are values that are set and managed by
the kernel, not by the process, and are thus most dependable when
extracted from the kernel itself.  However other values are specific to
the daemon and the kernel doesn't care/know anything of, like what
virtual domains the webserver is handling, of how many domains the DNS
server is master.  Anyway, this has very little (if anything) to do with
the monitor's need to be able to... monitor the processes it launches,
set them to the wanted user:group and the daemons knowing whether they
are to detach from the controlling terminal or not.

> Why do a process have to query the kernel to get a value and then 
> sending it to a monitor over a communication link; why don't the
> monitor query the kernel itself, saving one step.

  Where did Enrico Weigelt write the monitor should get it's child PID
from the process itself?  This subthread started from these lines:

>> * 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 ?


>>  In this
>> case, asking "why should a program/daemon care if it has a monitor or
>> not ?" is moot, because that the daemon is aware or not that it was
>> launched by a monitor and if so by what monitor, does not change
>> anything about the monitor's functions and duties.  The daemon doesn't
>> care if it's run by a monitor?  The monitor is still there, and it does
>> care about the program.
> It would help my understanding if you simply answered my question.

  An answer to a moot question is Mu!
(https://en.wikipedia.org/wiki/Mu_%28negative%29)
  The only point of any technical interest was already answered:

«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.»

  And again, so long as it's configured the right way, that the daemon
is aware that it is run under a monitor or not is irrelevant: it is the
monitor that need to be aware of it's children processes, their status
and operational parameters, because it is responsible of what they do,
starting from setting the user:group they run under.  Daemons should
behave the same no matter under what monitor they are running under,
they are not to care about this.  This is one of the reasons systemd is
bad.  Still, the monitor does the monitoring.


>> A driver does not care if the traffic light is
>> red or green?  The street police does.
> This is not as a suitable metaphor as you think it is.

  It is, no matter what you think about it.


Alessandro

___
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]

2017-04-18 Thread Arnt Gulbrandsen 

kato...@freaknet.org writes:

Unfortunately we are already paying the consequences of badly-written
software implementing oddly-designed solutions to non-existing
problems...


Indeed. But what's your point?

Arnt
___
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]

2017-04-18 Thread Arnt Gulbrandsen 

kato...@freaknet.org writes:

I genuinely don't understand why the kernel should know about the
internals of running processes, or get notified if a process is
"ready" to do whatever it is supposed to do, or get queried by other
processes which would like to access this kind of information, or
maintain such information in the first instance...


Indeed. Particularly in light of the modern fashion of running things on 
other hosts reachable across the network, perhaps via load balancers that 
complicate the availability state machine.


Arnt
___
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]

2017-04-18 Thread KatolaZ 
On Tue, Apr 18, 2017 at 02:15:38PM +0100, Arnt Gulbrandsen wrote:
> I've read this thread fairly thoroughly, but fail to see much of a use
> case...
> 
> There's hypothetical stuff, what if service x needs service y. Well, what if
> it does. Should it demand that y be running at every moment and on the same
> host? DOES it demand that?
> 

Unfortunately we are already paying the consequences of badly-written
software implementing oddly-designed solutions to non-existing
problems...

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  ]


signature.asc
Description: Digital signature
___
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]

2017-04-18 Thread karl 
Alessandro Selli:
...
> And
> what I don't like of Karl Aspo's idea is that it takes any instrument of
> policy checking and enforcing out of the monitor, which ends up not
> being able to monitor anything, it becomes just a shell: fire and forget.

I honestly do not understand what I have written which gives you that idé.

> I was also been ironic on Aspo, as many times he can only counter
> another person's ideas asking "What if  cannot be trusted?",
> as if this constitutes a valid argument against being able to set
> policies for the monitor to enforce on the daemons it runs.

If I can get a value from the kernel instead of from the process,
I'd take the kernel value.

Why do a process have to query the kernel to get a value and then 
sending it to a monitor over a communication link; why don't the
monitor query the kernel itself, saving one step.

>  In this
> case, asking "why should a program/daemon care if it has a monitor or
> not ?" is moot, because that the daemon is aware or not that it was
> launched by a monitor and if so by what monitor, does not change
> anything about the monitor's functions and duties.  The daemon doesn't
> care if it's run by a monitor?  The monitor is still there, and it does
> care about the program.

It would help my understanding if you simply answered my question.

> A driver does not care if the traffic light is
> red or green?  The street police does.

This is not as a suitable metaphor as you think it is.

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
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

2017-04-18 Thread Didier Kryn 

Le 17/04/2017 à 16:54, Enrico Weigelt, metux IT consult a écrit :

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 ;-)



Busybox isn't a monolithic system you need to link applications 
against, nor does it force you to depend on it. It *can* be built as a 
single executable, as a conveniency for those who don't want to have 
dynamic libraries in their way. Busybox provides its own init, which is 
not systemd, and it does not force you to use it. You build your own 
Busybox implementing the apps you want and only them.


I guess you didn't intend to introduce any confusion, but it might 
arise from your last sentence.


Cheers.
Didier

___
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]

2017-04-18 Thread karl 
Allesandro, I'm not interested in a debate (people talking past each 
other), I'm interested in understanding why the proposed library and
it function calls are such a good idé, since I don't think it is.

Wheter to run a monitor or not is a different question, which I 
consider is up to the local admin.

Why srvmgt_daemonize(), use -f and daemon() and you'd be fine in
either camp, end case.

Why srvmgt_droppriv(), either accept that the process set's it itself
or force it to some uid:gid, what is it more to it ?

Why srvmgt_report_state(), just do a normal query to the process and
you'll know if it is ready to serve you or not, if you want to know
if it is up to speed, do a benchmark, if you want to test the 
integrity, do a regression test; what is it more to it ?
(And, yes, a monitoring program can do the above for you.)

I don't get the point of all this, can you explain ?

Regards,
/Karl Hammar

---
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57


___
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]

2017-04-18 Thread Adam Borowski 
On Tue, Apr 18, 2017 at 11:32:00AM +0100, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote:
> >   Why should a car driver care if the traffic light has the red or the
> > green light turned on?
> >   Why should a sysadmin care if the OS he uses runs systemd or not?
> 
> This is a totally wrong assumption. Being a sysadmin is all about
> setting and implementing *policies*. And the choice between systemd or
> anything else is exactly a matter of policy. So yes, a sysadmin *must*
> care if the OS he/she uses runs systemd or anything else.

I don't care whether the OS runs systemd, sysv-rc, openrc or an enslaved
young boy sitting at the console and starting daemons by hand.  What I do
care about is whether it:
* implements standard interfaces
* is correct while doing so

My beef with systemd is that it has egregious bugs (some due to mistakes,
some due to intentional brain damage), and that working around bugs or
places where it doesn't meet your particular use case is a matter of a
single line of shell on sysv-rc but on systemd it's a hopeless case of
digging through a giant blob of spaghetti code.


A sample openrc (init script?) bug:

[ ok ] Asking all remaining processes to terminate...done.
Currently running processes (pstree):
init-+-2*[nbd-client]
 `-rc---openrc---openrc-run---sendsigs---pstree
[FAIL] Killing all remaining processes...failed.
Stopping NBD client process: 
disconnect, [17892.932316] block nbd0: NBD_DISCONNECT
sock, [17892.937274] block nbd0: shutting down sockets
done
disconnect, [17892.951774] block nbd1: NBD_DISCONNECT
sock, [17892.956734] block nbd1: shutting down sockets
done
rmmod: ERROR: Module nbd is in use
nbd-client.
[warn] not deconfiguring network interfaces: network devices still mounted. ... 
(warning).
[info] Saving the system clock.
[info] Hardware Clock updated to Tue Apr 18 13:18:23 CEST 2017.
[ ok ] Deactivating swap...done.
[] Unmounting local filesystems...[17896.568144] block nbd0: Attempted send 
on invalid socket
[17896.573501] blk_update_request: I/O error, dev nbd0, sector 4257856
[17896.579804] block nbd0: Attempted send on invalid socket
[17896.585125] blk_update_request: I/O error, dev nbd0, sector 4258112
[17896.591402] BTRFS error (device nbd0): bdev /dev/nbd0 errs: wr 1, rd 0, 
flush 0, corrupt 0, gen 0
[17896.600422] block nbd0: Attempted send on invalid socket
[17896.605741] blk_update_request: I/O error, dev nbd0, sector 4262496
[17896.612018] block nbd0: Attempted send on invalid socket

A sysadmin who doesn't know the proper way to fix this can still trivially
deal with the issue.  Don't know how to make nbd-client stop _after_ network
filesystems are unmounted?  Just plop in a manual unmount somewhere.  Here,
your system is fixed, you can then learn when you got a bit of time.


A sample systemd bug:

A common way to backup/search/etc a filesystem that has something mounted in
random subdirectories is to "mount --bind / /mnt/ref/rootfs; mount --bind
/home /mnt/ref/home" and so on, so you don't risk a naive script getting
into a loop.  Except, systemd sometimes decides to convert that --bind into
a --rbind (specifically what you wanted to avoid!); it might happen a
fraction of second after the mount, several minutes or apparently never.  So
you can't even rely on that bug happening or not.  It will also sometimes
decide to _unmount_ what you just mounted (most often on a degraded raid).
Now try to work around this...

-- 
⢀⣴⠾⠻⢶⣦⠀ Meow!
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Collisions shmolisions, let's see them find a collision or second
⠈⠳⣄ preimage for double rot13!
___
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]

2017-04-18 Thread Alessandro Selli 


On 18/04/2017 at 12:32, KatolaZ wrote:
> On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote:
>
> [cut]
>
>>>  And why should a program/daemon care if
>>> it has a monitor or not ?
>>   Why should a car driver care if the traffic light has the red or the
>> green light turned on?
>>   Why should a sysadmin care if the OS he uses runs systemd or not?
> This is a totally wrong assumption. Being a sysadmin is all about
> setting and implementing *policies*. And the choice between systemd or
> anything else is exactly a matter of policy. So yes, a sysadmin *must*
> care if the OS he/she uses runs systemd or anything else.

  Which is exactly my point.  I am not advocating in favor of systemd
any more than I'm advocating letting drivers ignore traffic lights.  And
what I don't like of Karl Aspo's idea is that it takes any instrument of
policy checking and enforcing out of the monitor, which ends up not
being able to monitor anything, it becomes just a shell: fire and forget.
I was also been ironic on Aspo, as many times he can only counter
another person's ideas asking "What if  cannot be trusted?",
as if this constitutes a valid argument against being able to set
policies for the monitor to enforce on the daemons it runs.  In this
case, asking "why should a program/daemon care if it has a monitor or
not ?" is moot, because that the daemon is aware or not that it was
launched by a monitor and if so by what monitor, does not change
anything about the monitor's functions and duties.  The daemon doesn't
care if it's run by a monitor?  The monitor is still there, and it does
care about the program.  A driver does not care if the traffic light is
red or green?  The street police does.


Alessandro

___
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]

2017-04-18 Thread Ron 
On Tue, 18 Apr 2017 11:32:00 +0100
KatolaZ  wrote:

> >   Why should a car driver care if the traffic light has the red or the
> > green light turned on?
> >   Why should a sysadmin care if the OS he uses runs systemd or not?
> >   
> 
> This is a totally wrong assumption. Being a sysadmin is all about
> setting and implementing *policies*. And the choice between systemd or
> anything else is exactly a matter of policy. So yes, a sysadmin *must*
> care if the OS he/she uses runs systemd or anything else.

He should care, as he has to know whether it is a unix/linux system or a 
systemd system, the two being rather different in their management...
 
Cheers,
 
Ron.
-- 
   Eat drink and be merry,
  for tomorrow we may diet.

   -- http://www.olgiati-in-paraguay.org --
 
___
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]

2017-04-18 Thread KatolaZ 
On Tue, Apr 18, 2017 at 12:21:05PM +0200, Alessandro Selli wrote:

[cut]

> 
> >  And why should a program/daemon care if
> > it has a monitor or not ?
> 
>   Why should a car driver care if the traffic light has the red or the
> green light turned on?
>   Why should a sysadmin care if the OS he uses runs systemd or not?
> 

This is a totally wrong assumption. Being a sysadmin is all about
setting and implementing *policies*. And the choice between systemd or
anything else is exactly a matter of policy. So yes, a sysadmin *must*
care if the OS he/she uses runs systemd or anything else.

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  ]


signature.asc
Description: Digital signature
___
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]

2017-04-18 Thread Alessandro Selli 
On 18/04/2017 at 10:35, k...@aspodata.se wrote:
> 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.
> A daemon from a daemon ?

  Isn't init a daemon?  Isn't inetd/xinetd a daemon?

>>  The monitor and the
>> daemon must coordinate each other about who's doing the detach to avoid
>> launch time failures.
> The program to become the daemon, how does it knows if it has a monitor 
> or not ?

  In the case of init being the monitor, it can check if it's parent has
PID 1.  The classical approach is to configure the daemon to do the
right thing, i.e. to do the detach himself when run with the --daemon
switch or when the config file has a similar item configured, to let the
monitor do it otherwise or if explicitly told not to daemonize (some
programs have a --no-daemon or --foreground or --debug switch to
override the config file settings).  This is old-school Unix, classical
Unix daemon have had these items (switches and config files) for many
ten years...  the modern approach in Linux entails IPC, dbus, sockets to
have messages passed from the monitor to daemons and back.

>  And if it doesn't know, how can one demand that it should
> coordinate with something unknown ?

  Config files, command line switches.

>  And why should a program/daemon care if
> it has a monitor or not ?

  Why should a car driver care if the traffic light has the red or the
green light turned on?
  Why should a sysadmin care if the OS he uses runs systemd or not?

 * 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.
> I don't follow you. If the monitor shouldn't know much about the child
> as stated by someone somewhere else in this thread, why should the 
> monitor need to know user:group ?

  Again, as far as I understood what Enrico Weigelt wrote, the monitor
does not want to know the user:group the daemons runs under, it needs to
*set* them to the appropriate values when it launches the daemon to have
them reflect config file settings or local policies.

>  And if it should know it, why trust 
> the monitored program when the kernel can give you the info ?

  Again, the relevant info is supposed to be set in config files.  The
user:group the daemon must run under is not up to the daemon itself,
they are set in config files, either the deamon's or the monitor's.

>>> 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.
> Or, rather, the user is responsible for the config file, not the program
> reading it, so yes the program generally trusts the config file "since I
> demand it". And what is your point ?

  That the relevant info is set in the config files, they are not made
up by the program itself and trusted by the monitor.  The trust is
placed into the 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.
> It seems you have the view that a monitor has to police a program.

  Many monitor also do this, some are setup mainly for this reason. 
Xinetd has several config items related to security or resource
policing: some "flags" (like IDONLY and INTERCEPT), the "user" and
"group" settings, "libwrap", "only_from", "no_access", "access_times",
"redirect", "bind", "per_source", "cps" (connections per second),
"max_load", "umask", "rlimit_(as|cpu|data|rss|stack)", "passenv",
"deny_time".  It's good they are available, that you use them or don't.

> I don't think one should have such a strict view.

  If you don't want them, don't use them.  Let other people decide
otherwise, though.  There is not a single use case that

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

2017-04-18 Thread karl 
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.

A daemon from a daemon ?

>  The monitor and the
> daemon must coordinate each other about who's doing the detach to avoid
> launch time failures.

The program to become the daemon, how does it knows if it has a monitor 
or not ? And if it doesn't know, how can one demand that it should
coordinate with something unknown ? And why should a program/daemon care if
it has a monitor or not ?

> > > * 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.

I don't follow you. If the monitor shouldn't know much about the child
as stated by someone somewhere else in this thread, why should the 
monitor need to know user:group ? And if it should know it, why trust 
the monitored program when the kernel can give you the info ?

> > 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.

Or, rather, the user is responsible for the config file, not the program
reading it, so yes the program generally trusts the config file "since I
demand it". And what is your point ?

> > > * 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.

It seems you have the view that a monitor has to police a program.
I don't think one should have such a strict view.

> > >  --> 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.
...

Why, the monitor is not a firewall. It seems you and I have different
views about what a monitor is and should/shouldn't do.

> > 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?

Then I wouldn't run it, would you ?

> What do you mean by what you wrote?  How do you think you can teach a
> monitor if some program can be trusted?
...

The monitor doesn't have to trust a specific program if it can get the
the wanted info from the kernel. If I can get the info I want from the 
kernel, why should I ask the program ? If the kernel say something 
and the program something else, which one do you trust more ?

> > 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?

First off, we seems to have

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

2017-04-18 Thread KatolaZ 
On Tue, Apr 18, 2017 at 03:36:09AM -0400, Steve Litt wrote:
> On Mon, 17 Apr 2017 10:09:02 +0200
> exha...@posteo.net wrote:
> 
> > in the same way that there's not a perfect graphical desktop for all
> > the people,
> 
> Quoted for truth!
> 
> You can't *download* or *install* the perfect GUI desktop, you must
> construct the GUI desktop that's best for you. And that requires
> interchangeable parts.
> 
> I sense a theme here.
>  


The theme is quite easy to spot, and has been around for the best part
of the last 50 years: small, reusable, interchangeable components,
each providing a single, atomic, simple mechanism, avoiding to mess up
with policies (which are for the perusal of humans, not
machines...). This is what KISS is all about.

We have always needed and will always need more software. But never
"more standard policies" or "unique and perfect solutions" for each
problem. Those are quests for fools.


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  ]


signature.asc
Description: Digital signature
___
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]

2017-04-18 Thread Steve Litt 
On Mon, 17 Apr 2017 10:09:02 +0200
exha...@posteo.net wrote:

> in the same way that there's not a perfect graphical desktop for all
> the people,

Quoted for truth!

You can't *download* or *install* the perfect GUI desktop, you must
construct the GUI desktop that's best for you. And that requires
interchangeable parts.

I sense a theme here.
 
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