Re: [DNG] Conversion script: was Formail for managing digests
On Mon, 2 Dec 2019 10:13:01 +0100 Edward Bartolo via Dng wrote: > Dear All, > > Inits need to understand unit files, give them that functionality. > That is far more efficient compared to what you are doing. > > Pseudo Code: > 1) check for the presence of a unit file > 2) if it exists > a) branch to function to read unit file and run daemon > b) if NOT execute shell script to run daemon > > Programming allows to create a configuration text file which tells an > init to be aware of the existence of unit files. This can be used to > minimize the incidence of bugs for cases where no unit files are used. > The extra functionality can be debugged in separate functions. IMHO the preceding is complexity you don't need, at least if I read you correctly and you're suggesting non-systemd inits process Unit Files at boot time. The startup files, be they init scripts, run scripts or Epoch .conf files, can be done offline using a conversion plus testing and touchup, and then used at boot time. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Tue, 3 Dec 2019 09:02:14 +0100 Denis Roio wrote: > On Sat, 30 Nov 2019, Hendrik Boom wrote: > > > On Fri, Nov 29, 2019 at 07:21:54PM +0100, Massimo Coppola wrote: > > > > > > > > If (assuming that) we are going to lose the source of init scripts > > > upstream, then it's the only way forward. (For those who consider > > > recognizing the unit files as a valid source a defeat: I may agree > > > with you, but sometimes a strategic retreat can lead to victory). > > > > > > > If we are worried about losing init scripts upstream, I suggest we > > maintain a version-controlled collection if initscripts somewhere so > > that if one disappears from a package we can restore it. > > This is what I'm really unsure of, so far. Every time I tried to > debate this with someone knowing Debian better than I do, we ended in > disagreement. > > My opinion however is this: maintaining a *unique package* of version > controlled init scripts in Devuan is much, much easier than > maintaining a sysvinit script in each different package, forking it. You'll get no arguments from me. From the very beginning, I didn't think either "upstreams" or daemon package maintainers should be responsible for init scripts, run scripts, or Epoch conf files. It was this responsibility and the burden thereof that caused the DSs to support systemd and *only* systemd: They were tired of supporting sysvinit scripts, which I think we all admit are atrocities. But to a person familiar with sysvinit, they're probably all similar. Run the dependencies, then run the daemon. Kill means kill the daemon, and then if the dependencies are dependencies only of the daemon, kill them. Reload means sending the proper signal, and restart means stop then start. There are also a few logging issues. I'm not sure why this adds up to more than 200 lines in so many cases, and maybe if we had professional sysvinit init script maintainers, it wouldn't. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script for maintainers
On Tue, 3 Dec 2019 23:04:56 + s@po wrote: > > I believe you are talking about Situation 1)( Give SysVInit the > Knowledge about SystemD unitFiles.. )? I thought this was settled law. Debian has sysvinit scripts, dropped ones can be gotten from Wheezy, and in other cases there exists a conversion script that seems mighty thorough. I thought therefore that nobody in Devuan would need to create sysvinit scripts. Now if you're talking about s6, runit, Epoch and OpenRC, yes, script maintainers should be given knowledge of Unit Files. SteveT Steve Litt December 2019 featured book: Rapid Learning for the 21st Century http://www.troubleshooters.com/rl21 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script for maintainers
Hello all,
>Date: Mon, 2 Dec 2019 10:13:01 +0100
>From: Edward Bartolo via Dng
>Dear All,
>
>Inits need to understand unit files, give them that functionality.
>That is far more efficient compared to what you are doing.
>
>Pseudo Code:
>1) check for the presence of a unit file
>2) if it exists
>a) branch to function to read unit file and run daemon
>b) if NOT execute shell script to run daemon
>
>Programming allows to create a configuration text file which tells an
>init to be aware of the existence of unit files. This can be used to
>minimize the incidence of bugs for cases where no unit files are used.
>The extra functionality can be debugged in separate functions.
I believe you are talking about Situation 1)( Give SysVInit the Knowledge about
SystemD unitFiles.. )?
Indeed it seems more eficient, at Same time, it could be more dificult, than
what we think of..
I think it will have to "be the future..", at uncertain time.. Or Debian
Understands the mistake they are doing..
But there are there good reasoning responses to this thread..to name a few,
Massimo Coppola, Denis Roio,Hendrik Boom..
There are also( as a short time response.. ) , a option to maintain a colection
of Scripts in the repos, by Arnt Karlsen, and Dimitris..
Taking Massimo Coppola, Dimitris Observations, and others by new order of
priority,
1) Maintain a copy of all init Files in theDevuan repos, just in Case.. asked
by Arnt Karlsen, and Dimitris..
2) Develop a Translation of UnitFiles from SystemD to SysvInit( This proces is
already Ongoing by viverna ? ), and generally accepted by all, including me..
Test it, optimize it, and understand deep, the pros and cons, of porting,
and translating of unit files..
When process working like we like, step into 3).. Generally supported by
Massimo Coppola, Denis Roio, Hendrik Boom, and myself, maybe more even..?
3) Depending of the knowledge acquired in 2),
Implement that into SysVinit, the translation, or Interpretation, of the
UnitFiles..
Turn SysVInit capable to launch SystemD daemons, control them..
Associate each "Runlevel type, etc" of SystemD, and translate them to
{0..6..1} of SysVInit( So that Devuan could be resilient to InitChanges.. ).
-> Add: At Same time, when this infraestructure will be created into
SysVInit,
**Make it Generic**, and capable to accept more Init Systems,let's
say Abstract, or Generic..
Intermediate Language( IR ) ?
Like LSB Scripts Headers( proposed by William (Bill) Moss ), or a
refinement of it.. ?
In This process, at least, I would need to go into references made by Denis
Roio, quoting bellow,
a) a DSL parser for the conversion of unitfiles to shell scripts
say "systemd2sysv".
b) an easy way to test the shell scripts generated, which is also
crucial to the task: the quality of the testing environment.
c) optionally, a way to repackage and test semi-automatically an
existing deb package undergoing this conversion.
I have experience writing DSL parsers and recommend using either:
d) stb_c_lexer by Sean Barrett, part of the STB C lib collection
e) libhammer by Meredith Patterson, part of langsec.org
more complex, but way more secure, not sure if this level of
security is needed however
I don't know if this is the correct order or priority..
Some of them could even be developed at the same time( in parallel ),
At least at some extent, then 3) needs to wait feedback from 2) ( observed by
Massimo Coppola ).
--
Best Regards,
tux
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On 12/3/19 10:02 AM, Denis Roio wrote: > My opinion however is this: maintaining a *unique package* of version > controlled init scripts in Devuan is much, much easier than > maintaining a sysvinit script in each different package, forking it. > > I'm not sure about pressing counter-arguments against this. maybe i'm wrong, but what if this unique package turns into a single point of failure for all running daemons (?) haven't given it much thought, just sayin'. d. signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script for maintainers
On Tue, Dec 03, 2019 at 08:58:10AM +0100, Denis Roio wrote: > I wholeheartedly agree with all your reasoning, quoted below. I don't > think that converting automatically at init or at package install is a > good idea: we need to keep this process under scrutiny by maintainers, > hoping more people will help Devuan, at least on converting scripts > for important packages, and make life easier for them. I agree. It needs to be under scrutiny by maintainers. And a maintianer might well prefer to use the upstream init anyway. Don't Debian source packages have aa pristine copy of upstream and a set of patches? If that's so, the upstream init scripts should be available, and we might even be able to have a script that extracts the upstream init or removes the patch that removes it. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [OT] reboot did not work on Systemd based system
Had to reboot a Debian based system this weekend to apply kernel patches but it would not reboot. All commands (poweroff -p, reboot, init 6) would return with this error message or similar: Failed to start reboot.target: Transaction is destructive. See system logs and 'systemctl status reboot.target' for details. Systemctl produced no useful details whatsoever and only reiterated the command line error in more verbosity. The only recourse was to power cycle the system after a umount of the major filesystems. Thank you Devuan for providing a stable and re-bootable system. The bar continues to be lowered. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to change the action of the computer's power button?
On Mon, 2 Dec 2019 16:32:59 +0100, Stephane wrote in message : > Le 02/12/2019 à 16:03, Mark Hindley a écrit : > > Did you mean no you don't have elogind installed? > > It's in status "p" in Dpkg > > > > If so, what are you using? pm-utils? > > Apparently yes > For example, "pm-suspend" works ..my favorite is "pm-suspend-hybrid", works "right out of the box" both with vdev and eudev IME without any configuration on my part. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] How to change the action of the computer's power button?
Stephane Ascoet writes: > Le 02/12/2019 à 15:23, Mark Hindley a écrit : >> Are you using elogind? If so you can change the defaults in >> /etc/elogind/logind.conf. > > Thanks for the answer but no, and it happens even in TTYs, so I assume > it's the set at a low-level in system Hmm, also happens at TTYs you say ... I was thinking the pf, pn and po settings in /etc/inittab might be involved but I can't seem to find the /etc/init.d/powerfail script these want to invoke ... Neither does apt-file search, on ascii at least. Really low-level, something in your BIOS settings perhaps. Hope this helps, -- Olaf Meeuwissen, LPIC-2FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Softwarehttps://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script for maintainers
On Tue, 3 Dec 2019 08:58:10 +0100, Denis wrote in message <20191203075810.twxmme6ayyccbftf@reflex>: > > dear Massimo, > > you are very welcome :^) I'm happy to see here a fellow VUA :^D > > down to business ..thanks for talking good sense here, Denis and Massimo. :o) > > > If (assuming that) we are going to lose the source of init scripts > > upstream, then it's the only way forward. (For those who consider > > recognizing the unit files as a valid source a defeat: I may agree > > with you, but sometimes a strategic retreat can lead to victory). > > I agree, but more than a defeat, this is a repairing strategy against > an hostile move. Those involved in Debian and SPI should acknowledge > they are being hostile to the UNIX community at large. > > About having "an Interpreter, for the UnitFiles, that then internally > do things as SysVInit does": I have privately experimented with this > for a while now and there are corner-cases, but it is feasible, if > such cases can be taken care of. > > You adress very well this issue with your reasoning: > > > My impression is that it is viable building a batch init script > > generator, where package maintainers are able to check and validate > > the newly generated init scripts *in the maintainer test system*, as > > well as take care of any peculiar bug of the translation, or quirky > > behaviour of the unit files. > > This would mean having two things at least: > > 1. a DSL parser for the conversion of unitfiles to shell scripts >say "systemd2sysv". > > 2. an easy way to test the shell scripts generated, which is also >crucial to the task: the quality of the testing environment. > > 3. optionally, a way to repackage and test semi-automatically an >existing deb package undergoing this conversion. > > I have experience writing DSL parsers and recommend using either: > > 1. stb_c_lexer by Sean Barrett, part of the STB C lib collection > > 2. libhammer by Meredith Patterson, part of langsec.org >more complex, but way more secure, not sure if this level of >security is needed however > > Assuming of course whoever writes this likes to make it in C, which > I'd recommend. > > I wholeheartedly agree with all your reasoning, quoted below. I don't > think that converting automatically at init or at package install is a > good idea: we need to keep this process under scrutiny by maintainers, > hoping more people will help Devuan, at least on converting scripts > for important packages, and make life easier for them. > > > As it's systemd we are talking about, I wouldn't ever place a bet on > > stable and documented behaviour on its part. Otherwise we wouldn't > > be here on devuan ML, after all. When new peculiar behaviour is > > discovered, we can adapt the initscript generator. This would mean a > > huge effort on repacking debian packages, or having blanket-like > > packages with init"scripts" for SysV/openrc/any_init that provide > > the init support to all/groups of debian packages, possibly synced > > with major revisions of devuan. ..my observation from the few .src.deb and .deb packages I've looked into, is we have 2 kindsa DDs, our friendly DDs keep upstream init scripts intact in their src.debs and builds their .debs according to the current Debian doctrine, some even allow in the upstream or debianised init scripts to try support alternative init systems in Debian, while the systemd crowd throws out all non-systemd upstream init system support to make both their .src.deb and .deb packages, systemd-only. Some of these systemd folks may be doing the tactical thing of keeping the upstream init support appearance. ..bottom line is, we need to look upstream. ..another tool we have, is alien, that could use some TLC, allows us to look sideways to e.g. good old Slackware.com ;o) > > On the other hand, a unitfile *interpreter* is a different story, > > I'm not sure this is viable as of now, and the risks look greater to > > me in this case. IMO there are two scenarios. > > > > > > 1) the interpreter is external to SysVinit/any_init init and is > > called after each package update (by means of apt ?). Still, any > > bug that creeps through by leveraging unexpected unit file behaviour > > will risk of breaking the interpreter *in the devuan user system*, > > and this would negatively affect devuan reliability. Imagine the > > backfire of a situation where the interpreter fails after a security > > update for some obscure change in a unit file, so at service > > start/stop or at next reboot the system goes astray. > > > > 2) the interpreter is run by the init process (bound to it some > > way) and used each time a script is accessed. I'd rather not see > > this, more complexity of this kind in the init process is bad for > > system health. > > > > I agree the interpreter idea is technically intriguing, but bot > > scenarios are a bit too close to reimplementing systemd, IMO. I'd > > rather develop something useful to
Re: [DNG] Conversion script for maintainers
dear Massimo, you are very welcome :^) I'm happy to see here a fellow VUA :^D down to business > If (assuming that) we are going to lose the source of init scripts > upstream, then it's the only way forward. (For those who consider > recognizing the unit files as a valid source a defeat: I may agree > with you, but sometimes a strategic retreat can lead to victory). I agree, but more than a defeat, this is a repairing strategy against an hostile move. Those involved in Debian and SPI should acknowledge they are being hostile to the UNIX community at large. About having "an Interpreter, for the UnitFiles, that then internally do things as SysVInit does": I have privately experimented with this for a while now and there are corner-cases, but it is feasible, if such cases can be taken care of. You adress very well this issue with your reasoning: > My impression is that it is viable building a batch init script > generator, where package maintainers are able to check and validate > the newly generated init scripts *in the maintainer test system*, as > well as take care of any peculiar bug of the translation, or quirky > behaviour of the unit files. This would mean having two things at least: 1. a DSL parser for the conversion of unitfiles to shell scripts say "systemd2sysv". 2. an easy way to test the shell scripts generated, which is also crucial to the task: the quality of the testing environment. 3. optionally, a way to repackage and test semi-automatically an existing deb package undergoing this conversion. I have experience writing DSL parsers and recommend using either: 1. stb_c_lexer by Sean Barrett, part of the STB C lib collection 2. libhammer by Meredith Patterson, part of langsec.org more complex, but way more secure, not sure if this level of security is needed however Assuming of course whoever writes this likes to make it in C, which I'd recommend. I wholeheartedly agree with all your reasoning, quoted below. I don't think that converting automatically at init or at package install is a good idea: we need to keep this process under scrutiny by maintainers, hoping more people will help Devuan, at least on converting scripts for important packages, and make life easier for them. > As it's systemd we are talking about, I wouldn't ever place a bet on > stable and documented behaviour on its part. Otherwise we wouldn't > be here on devuan ML, after all. When new peculiar behaviour is > discovered, we can adapt the initscript generator. This would mean a > huge effort on repacking debian packages, or having blanket-like > packages with init"scripts" for SysV/openrc/any_init that provide > the init support to all/groups of debian packages, possibly synced > with major revisions of devuan. > > On the other hand, a unitfile *interpreter* is a different story, > I'm not sure this is viable as of now, and the risks look greater to > me in this case. IMO there are two scenarios. > > > 1) the interpreter is external to SysVinit/any_init init and is > called after each package update (by means of apt ?). Still, any > bug that creeps through by leveraging unexpected unit file behaviour > will risk of breaking the interpreter *in the devuan user system*, > and this would negatively affect devuan reliability. Imagine the > backfire of a situation where the interpreter fails after a security > update for some obscure change in a unit file, so at service > start/stop or at next reboot the system goes astray. > > 2) the interpreter is run by the init process (bound to it some > way) and used each time a script is accessed. I'd rather not see > this, more complexity of this kind in the init process is bad for > system health. > > I agree the interpreter idea is technically intriguing, but bot > scenarios are a bit too close to reimplementing systemd, IMO. I'd > rather develop something useful to the mantainers now, and keep the > option to turn it into a package for the end user later on. So I'd > first go with 1) the offline translation, 2) get it stable enough > that it can run automatically on any debian package updates, 3) > monitor the amount of bugs and manual corrections needed, then 4) > enable the initscript to be automatically generated and added to > packages in devuan, 5) monitor again for errors 6) consider putting > the interpreter in the final system. > > We can have both solutions along this path but I think the solution > with shorter development time and biggest advantage to maintainers > should be prioritary. many thanks ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Conversion script: was Formail for managing digests
On Sat, 30 Nov 2019, Hendrik Boom wrote: > On Fri, Nov 29, 2019 at 07:21:54PM +0100, Massimo Coppola wrote: > > > > > If (assuming that) we are going to lose the source of init scripts > > upstream, then it's the only way forward. (For those who consider > > recognizing the unit files as a valid source a defeat: I may agree > > with you, but sometimes a strategic retreat can lead to victory). > > If we are worried about losing init scripts upstream, I suggest we > maintain a version-controlled collection if initscripts somewhere so > that if one disappears from a package we can restore it. This is what I'm really unsure of, so far. Every time I tried to debate this with someone knowing Debian better than I do, we ended in disagreement. My opinion however is this: maintaining a *unique package* of version controlled init scripts in Devuan is much, much easier than maintaining a sysvinit script in each different package, forking it. I'm not sure about pressing counter-arguments against this. ciao ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
