Re: [DNG] systemd and ssh-server
Quoting Alessandro Selli (alessandrose...@linux.com): [supporting what you said] > What could they possibly do of any harm to your system systemd unit > files, that is plain ASCII config files? I've said it before: If worried about such detritus files (or about libsystemd0), any sysadmin is perfectly free to set up a monthly cron job to set them to chmod 0. And: > Yeah, that's the spirit: patch up and contribute, maybe we'll end up > having a totaly Debian- and systemd-independed distribution and lots of > people would be grateful. > > But if you don't, at least please stop the whining. What _you_ said. -- Cheers, Luftputebåten min er full av ål. Rick Moen r...@linuxmafia.com McQ! (4x80) ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Am 11. Oktober 2018 15:21:17 MESZ schrieb Alessandro Selli : > And I wish we were living in a world where the > only struggle was advancing science, > knowledge, free software and landing on far > away planets and explore the galaxy. Reality > is quite a different story, though, and it's not > the Free Software people's fault. ...just for the quote (and an overdue hello!) libre Grüße, Florian -- [message sent mobile] ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 10/10/18 at 15:23, Enrico Weigelt, metux IT consult wrote: > On 25.07.2018 10:20, Joel Roth wrote: > > Hi, > >> Most of those "alarming" files are just systemd units files, put there> by >> daemons/packages/utilities who "also" support systemd in a way or another. >> So they are not alarming but just *totally* *harmless* if you >> don't have a running systemd as PID 1, since only systemd understands >> and can run them. > At least that's the theory. Actually, that's a fact. > I'm waiting for some yerk upstreams coming > around and doing some other silly things with them. Yes: in Lennartware > world, I've learned to expect those things :o What could they possibly do of any harm to your system systemd unit files, that is plain ASCII config files? >> It would be *totally* *useless* (and utterly> *stupid* IMHO) to fork, >> rebuild, >> and maintain a few more hundred packages only because they happen to provide >> a >> systemd unit file for those systems where systemd is used. > I don't think so. I agree that this eats resources with minimal gain. [alessandro@wksrn05 ~]$ du -sh /etc/systemd /lib/systemd/system/ 44K /etc/systemd 464K /lib/systemd/system/ [alessandro@wksrn05 ~]$ That's the *huuge* ammount os "system resources" they occuply on Ascii (Devuan 2.0). How does this compare with forking and maintaining hundreds of packages just to have them not install those files? >> BTW: we don't need to do that for all at once. Start with picking a few >> important packages and then learn how to handle that really efficiently. Everyone busy maintainig and developing Devuan already knows how that's to be done. They already did it for a lot of packages to take away more than just systemd unit files. Of course you're always welcome to step in to do the gritty work and take maintainership of a few, important packages to take away those "dangerous" unit files. >> My wish is having a (technical and organisational) infrastructure which >> allows us to quickly/easily fork and maintain any package. (on distro >> side as well as individual operator). Certainly, we'd have to learn a >> lot for that, but IMHO a good thing. And I wish we were living in a world where the only struggle was advancing science, knowledge, free software and landing on far away planets and explore the galaxy. Reality is quite a different story, though, and it's not the Free Software people's fault. >> libsystemd0 is used by some daemons to verify if systemd is running or >> not. If it's not, libsystemd is *totally* *harmless*. > I haven't read the code for quite some time, so I'm not trusting it. How much did you read of the code of the packages you have installed in your system? How can you be sure the only piece of software that's not to be trusted is systemd0, where does this obsession come from? > Too much happened in that area. I just don't want that code anywhere > near to any of my systems, I couldn't sleep well. I would have to > carefully review the code w/ my own eyes, but then I could also > patch out the systemd dependencies. Yeah, that's the spirit: patch up and contribute, maybe we'll end up having a totaly Debian- and systemd-independed distribution and lots of people would be grateful. But if you don't, at least please stop the whining. -- Alessandro Selli VOIP SIP: dhatarat...@ekiga.net Chiave firma e cifratura PGP/GPG signing and encoding key: BA651E4050DDFC31E17384BABCE7BD1A1B0DF2AE signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 25.07.2018 10:20, Joel Roth wrote: Hi, > Most of those "alarming" files are just systemd units files, put there> by > daemons/packages/utilities who "also" support systemd in a way or> another. So they are not alarming but just *totally* *harmless* if you> don't have a running systemd as PID 1, since only systemd understands> and can run them. At least that's the theory. I'm waiting for some yerk upstreams coming around and doing some other silly things with them. Yes: in Lennartware world, I've learned to expect those things :o > It would be *totally* *useless* (and utterly> *stupid* IMHO) to fork, > rebuild, and maintain a few more hundred> packages only because they happen to provide a systemd unit file for> those systems where systemd is used. I don't think so. I agree that this eats resources with minimal gain. BTW: we don't need to do that for all at once. Start with picking a few important packages and then learn how to handle that really efficiently. My wish is having a (technical and organisational) infrastructure which allows us to quickly/easily fork and maintain any package. (on distro side as well as individual operator). Certainly, we'd have to learn a lot for that, but IMHO a good thing. > libsystemd0 is used by some daemons to verify if systemd is running or > not. If it's not, libsystemd is *totally* *harmless*. I haven't read the code for quite some time, so I'm not trusting it. Too much happened in that area. I just don't want that code anywhere near to any of my systems, I couldn't sleep well. I would have to carefully review the code w/ my own eyes, but then I could also patch out the systemd dependencies. --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 25.07.2018 09:11, Hleb Valoshka wrote: > It's required just to notify systemd that sshd is running, so in > systemd-less system it's nop. So mostly libsystemd0 is harmless. Is it that the original libsystemd0, which tries to talk to systemd via desktop-bus ? Or is it a patched version, where functions like sd_notify() are really noop ? > Currently Devuan team doesn't have enough man power to fork every > single package just to cleanup its dependencies. Just had a quick look at the deb src. It's just a simple patch added by debian. Shouldn't be a big deal to fix that. The only thing, IMHO, we need to do is monitoring new deb releases (eg. some automatic notification), re-apply our systemd-removal package and rebuild that thing. Am I missing something ? --mtx ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Am Freitag, 27. Juli 2018 schrieb KatolaZ: > On Fri, Jul 27, 2018 at 11:37:57AM +0200, Dr. Nikolaus Klepp wrote: > [...] > > Well, yes, but the wole point of removing libsystemd0 would be to get rid > > of anything systemd, not to magle the systemd sources to do nothing (which > > would be a futile efford). SSHD is happy with "sd_notify", cups needs > > "sd_listen_fds", "sd_journal_print", "sd_journal_printv", "sd_journal_send" > > but is happy with dummy functions. Xorg wants only "sd_listen_fds" ... and > > so on. Virtualy all binaries on my system are happy with just a hand full > > of systemd functions. > > > I must admit I am lost :) > > The whole point of having a nooped version of libsystemd0 is to *not* > have anything systemd at all running in your system (unless you are > also scared of the function signatures defined by the systemd crew, > since those are basically the only piece of code that would remain > from the original systemd code in a nooped library...). > > The alternative is to fork any package that links libsystemd0, remove > the dependenc *if at all possible*, and *keep it updated with > upstream*, which means also removing any further dependencies, and > keeping track of all the patches included by the corresponding Debian > maintainer. > > We have tried the latter alternative first, and it does not work very > well, unless you have a relatively large number of *maintainers*. I > need to specify here that a *maintainer* is a person who follows the > changes happening upstream to the packages he/she is maintaining on a > daily basis, and rebuilds those packages as necessary, keeping them > updated. And commits herself to do so at least for an entire release > cycle. > > Unfortunately, most of the great people that helped stripping > libsystemd deps in Jessie, just disappeared soon after (also due to > the relatively steep learning curve of the Devuan building pipeline, > which has been lately somehow simplified by d1h and other tools). > > This is not maintaining a package, and this is not helping Devuan in > the long run. It's relatively easy to strip the deps in a single > package, and then abandon it in the hope that "others" will take care > of it in future releases. Almost anybody can do that. The real burden > is committing to maintaining those changes at least for an entire > release cycle, better if more than that. That's what a *maintainer* > should do. > > If we don't have enough maintainers, we'll do without, and a nooped > version of libsystemd looks pretty much like the path of least > resistance, having the greatest impact with a relatively smaller > effort. Ok, here's the part that I do not understand: Why nooping libsystemd (and try to understand that mess) instead of building a minimal (functionless) dummy? There are just a handful of programs (like elogind) that make extensive use of libsystemd and need extra care. The other stuff just uses a minimal set of functions - most just for logging. nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 2018-07-27 05:18, Lars Noodén wrote: On 07/27/2018 01:00 PM, KatolaZ wrote: [...] I need to specify here that a *maintainer* is a person who follows the changes happening upstream to the packages he/she is maintaining on a daily basis, and rebuilds those packages as necessary, keeping them updated. And commits herself to do so at least for an entire release cycle. Unfortunately, most of the great people that helped stripping libsystemd deps in Jessie, just disappeared soon after (also due to the relatively steep learning curve of the Devuan building pipeline, which has been lately somehow simplified by d1h and other tools). [...] The real burden is committing to maintaining those changes at least for an entire release cycle, better if more than that. That's what a *maintainer* should do. [...] The Devuan site [1] is quite clean but as a side effect lacks a direct link to the new, more simplified build process, and says to ask via mail. A direct link to the d1h instructions can be found on devuan.org from the Development tab on the nav bar about halfway down the page. Is that not the logical place to put it? https://devuan.org/os/development Help resources are listed in this order on the site's index page. The mail list is the last option: dev1galaxy.org (where the d1h thread is stickied under Documentation) #devuan IRC channel DNG golinux ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Fri, 27 Jul 2018 12:00:05 +0200 KatolaZ wrote: > Unfortunately, most of the great people that helped stripping > libsystemd deps in Jessie, just disappeared soon after One of the tricks is to get a disliked project up and running to make it the de facto alternative, then either pulling out to let it rot, or setting up to make/slow decision making, allowing the liked project to become the de facto popular/better project in comparison. But I'm just thinking out loud.. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Fri, Jul 27, 2018 at 01:18:41PM +0300, Lars Noodén wrote: [cut] > > Can you please (re-)post the link to the new Devuan build process? > Dear Lars, it's under "Deveopment": https://devuan.org/os/development and the relevant link is the fourth one: https://dev1galaxy.org/viewtopic.php?pid=1110#p1110 The manual of d1h, the Devuan packaging helper will help you build Devuan packages for Devuan or at home for your own use. Please feel free to ask if you need. Please also consider that the current version of d1h has a problem with the "cache" function, which I have to update to use the new salsa.debian.org. Sorry for the inconvenience. HTH KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 07/27/2018 01:00 PM, KatolaZ wrote: > [...] I need to specify here that a *maintainer* is a person who > follows the changes happening upstream to the packages he/she is > maintaining on a daily basis, and rebuilds those packages as > necessary, keeping them updated. And commits herself to do so at > least for an entire release cycle. > > Unfortunately, most of the great people that helped stripping > libsystemd deps in Jessie, just disappeared soon after (also due to > the relatively steep learning curve of the Devuan building pipeline, > which has been lately somehow simplified by d1h and other tools). > > [...] The real burden is committing to maintaining those changes at > least for an entire release cycle, better if more than that. That's > what a *maintainer* should do. [...] The Devuan site [1] is quite clean but as a side effect lacks a direct link to the new, more simplified build process, and says to ask via mail. Back in the Red Hat 5.2 days, OpenSSH was one of the packages where I rolled my own RPMs. APT is different but, famous last words, how much harder could it be once one gets going? I can probably follow a recipe reasonably well, and the second or third time should be easy, but would be constrained somewhat if a dedicated development machine is needed locally. So I would be interested in seeing how feasible it would be to maintain that package. Some preliminary searching turns up nothing about Devuan's build process. Can you please (re-)post the link to the new Devuan build process? /Lars [1] https://devuan.org/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Fri, Jul 27, 2018 at 11:37:57AM +0200, Dr. Nikolaus Klepp wrote: > Am Freitag, 27. Juli 2018 schrieb KatolaZ: > > On Fri, Jul 27, 2018 at 12:05:54AM +0200, Dr. Nikolaus Klepp wrote: > > > Sorry, this may break the thread but I already deleted the original > > > message. > > > > > > To make things short: this a minimal "libnosystemd" for sshd on ascii. It > > > basicly does nothing at all. To be more specific, it does exactly the > > > same that libsystemd0 does, which is nothing. > > > > > > Unpack where you like, compile and copy the resulting library to > > > /lib/x86_64-linux-gnu/libsystemd.so.0.17.0 (it might be a good idea to > > > backup the original). "service ssh stop; service ssh start" and oh magic > > > sshd is up and running without libsystemd0 - that is all it does. Good > > > enough for me as a proof of concept :-) > > > > > > Nik > > > > It's not that easy since already understanding how to build libsystemd > > alone and what should be nooped is not a trivial task (at least for > > me). Especially because they have recently abandoned autotools for > > ninja. > > Well, yes, but the wole point of removing libsystemd0 would be to get rid of > anything systemd, not to magle the systemd sources to do nothing (which would > be a futile efford). SSHD is happy with "sd_notify", cups needs > "sd_listen_fds", "sd_journal_print", "sd_journal_printv", "sd_journal_send" > but is happy with dummy functions. Xorg wants only "sd_listen_fds" ... and so > on. Virtualy all binaries on my system are happy with just a hand full of > systemd functions. I must admit I am lost :) The whole point of having a nooped version of libsystemd0 is to *not* have anything systemd at all running in your system (unless you are also scared of the function signatures defined by the systemd crew, since those are basically the only piece of code that would remain from the original systemd code in a nooped library...). The alternative is to fork any package that links libsystemd0, remove the dependenc *if at all possible*, and *keep it updated with upstream*, which means also removing any further dependencies, and keeping track of all the patches included by the corresponding Debian maintainer. We have tried the latter alternative first, and it does not work very well, unless you have a relatively large number of *maintainers*. I need to specify here that a *maintainer* is a person who follows the changes happening upstream to the packages he/she is maintaining on a daily basis, and rebuilds those packages as necessary, keeping them updated. And commits herself to do so at least for an entire release cycle. Unfortunately, most of the great people that helped stripping libsystemd deps in Jessie, just disappeared soon after (also due to the relatively steep learning curve of the Devuan building pipeline, which has been lately somehow simplified by d1h and other tools). This is not maintaining a package, and this is not helping Devuan in the long run. It's relatively easy to strip the deps in a single package, and then abandon it in the hope that "others" will take care of it in future releases. Almost anybody can do that. The real burden is committing to maintaining those changes at least for an entire release cycle, better if more than that. That's what a *maintainer* should do. If we don't have enough maintainers, we'll do without, and a nooped version of libsystemd looks pretty much like the path of least resistance, having the greatest impact with a relatively smaller effort. HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Am Freitag, 27. Juli 2018 schrieb KatolaZ: > On Fri, Jul 27, 2018 at 12:05:54AM +0200, Dr. Nikolaus Klepp wrote: > > Sorry, this may break the thread but I already deleted the original message. > > > > To make things short: this a minimal "libnosystemd" for sshd on ascii. It > > basicly does nothing at all. To be more specific, it does exactly the same > > that libsystemd0 does, which is nothing. > > > > Unpack where you like, compile and copy the resulting library to > > /lib/x86_64-linux-gnu/libsystemd.so.0.17.0 (it might be a good idea to > > backup the original). "service ssh stop; service ssh start" and oh magic > > sshd is up and running without libsystemd0 - that is all it does. Good > > enough for me as a proof of concept :-) > > > > Nik > > It's not that easy since already understanding how to build libsystemd > alone and what should be nooped is not a trivial task (at least for > me). Especially because they have recently abandoned autotools for > ninja. Well, yes, but the wole point of removing libsystemd0 would be to get rid of anything systemd, not to magle the systemd sources to do nothing (which would be a futile efford). SSHD is happy with "sd_notify", cups needs "sd_listen_fds", "sd_journal_print", "sd_journal_printv", "sd_journal_send" but is happy with dummy functions. Xorg wants only "sd_listen_fds" ... and so on. Virtualy all binaries on my system are happy with just a hand full of systemd functions. The two exceptions are "/usr/bin/elogind-inhibit" and "/usr/bin/loginctl" which make heavy use of sd_*. Nik > > And IMHO it's not gonna happen for ascii but for ceres first and then > percolate to beowulf. It could be backported to ascii though. > > We must keep developing Devuan by looking *forward*, not *backward* ;) > > HND > > KatolaZ > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Fri, Jul 27, 2018 at 12:05:54AM +0200, Dr. Nikolaus Klepp wrote: > Sorry, this may break the thread but I already deleted the original message. > > To make things short: this a minimal "libnosystemd" for sshd on ascii. It > basicly does nothing at all. To be more specific, it does exactly the same > that libsystemd0 does, which is nothing. > > Unpack where you like, compile and copy the resulting library to > /lib/x86_64-linux-gnu/libsystemd.so.0.17.0 (it might be a good idea to backup > the original). "service ssh stop; service ssh start" and oh magic sshd is up > and running without libsystemd0 - that is all it does. Good enough for me as > a proof of concept :-) > > Nik It's not that easy since already understanding how to build libsystemd alone and what should be nooped is not a trivial task (at least for me). Especially because they have recently abandoned autotools for ninja. And IMHO it's not gonna happen for ascii but for ceres first and then percolate to beowulf. It could be backported to ascii though. We must keep developing Devuan by looking *forward*, not *backward* ;) HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Am Freitag, 27. Juli 2018 schrieb Dr. Nikolaus Klepp: > Sorry, this may break the thread but I already deleted the original message. > > To make things short: this a minimal "libnosystemd" for sshd on ascii. It > basicly does nothing at all. To be more specific, it does exactly the same > that libsystemd0 does, which is nothing. > > Unpack where you like, compile and copy the resulting library to > /lib/x86_64-linux-gnu/libsystemd.so.0.17.0 (it might be a good idea to backup > the original). "service ssh stop; service ssh start" and oh magic sshd is up > and running without libsystemd0 - that is all it does. Good enough for me as > a proof of concept :-) > > Nik > > oops, wrong filename. should be "libnosystemd.tar.xz" instead of "libnosystemd.tar.gz". -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... libnosystemd.tar.xz Description: application/txz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Sorry, this may break the thread but I already deleted the original message. To make things short: this a minimal "libnosystemd" for sshd on ascii. It basicly does nothing at all. To be more specific, it does exactly the same that libsystemd0 does, which is nothing. Unpack where you like, compile and copy the resulting library to /lib/x86_64-linux-gnu/libsystemd.so.0.17.0 (it might be a good idea to backup the original). "service ssh stop; service ssh start" and oh magic sshd is up and running without libsystemd0 - that is all it does. Good enough for me as a proof of concept :-) Nik -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... libnosystemd.tar.gz Description: application/tgz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Quoting Luciano Mannucci (luci...@vespaperitivo.it): > Wasn't there something called uselessd that had this very goal some > time ago? It was promising but died, I don't know why ... The anonymous author felt his initial versions (through 2014's uselessd-8) had successfully made his point -- that with minimal effort systemd's codebase could be made modular, unintrusive, and devoid of extraneous junk -- and the only reason it wasn't is that the author/maintaners prefer the horrific mess that systemd is and remains. Someone named Tarnyko purported to take over maintenance of uselessd in early 2015, but with no results so far. (https://github.com/Tarnyko/uselessd) Meanwhile, the anonymous original author claimed he'd shifted to work designing/implementing some truly heterodox init system, but again nothing's yet been seen. And, in the meantime, there's Luke Shumaker's notsystemd, extremely similar in spirit to uselessd: https://lists.parabola.nu/pipermail/dev/2018-July/006882.html ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Steve Litt wrote on 26.07.2018 18:17: > On Thu, 26 Jul 2018 13:17:21 +0200 > Irrwahn wrote: >> What's more, I'd >> go even further and say I wouldn't mind at all if every daemon >> package came with support for all init systems in current use >> (rc-style sysv|openrc, runit, ... , systemd), as that would make >> switching init systems in an already installed system much, much less >> of a pain in the rear. Why would I care about a few dozen tiny >> innocuous unused files on a system that per default install is >> already cluttered with literally thousands of files I'm never going >> to use in any way. > > I write my own daemons. There may come a time when I put a free > software license on one of them and distribute it to the world. If I > did so, I might (or might not) include the runit run script I use to > run it. If I were feeling particularly nice that day, I might also > supply an s6 run script, because s6 run scripts are almost 1 to 1 > translations from runit. > > But there's no way I'd ever take the time to supply facilities for > startup in sysvinit, OpenRC, systemd or busybox. **Not my job!** While writing I was thinking more about package maintainers, not necessarily the author of a piece of software, though there will always be some considerable overlap between those groups of people. >> That'd be what I'd call "init freedom". It's very unlikely to happen >> in the foreseeable future though, as it would require cooperative >> effort of hundreds of individuals to include and maintain those init >> support files in the respective packages. > > Now it sounds like you're talking about something else. It now sounds > like you're talking about a group of init experts making startup > facilities for programs using various inits. This is a good idea. A > systemd unit file, or an s6 or runit run script offer excellent > documentation for how to configure the application for just about any > init system. Again, as above, I was thinking more about distribution package maintainers. Though it would obviously be of great help if patches were submitted by "init experts", without giving much thought to the question what traits would characterize such an "expert". By "cooperative effort" I meant that the maintainers of _all_ the daemon packages present in a distribution would have to provide and/or maintain init facilities for all supported init systems, as otherwise the whole endeavor would fail. > > sysvinit and OpenRC typically have init scripts tens or hundreds of > lines, making init integration of an application seem like an arcane > art. What are they thinking? IMHO these immense and unfathomable init > scripts are what opened the door for systemd. > I rarely write init scripts from scratch, and when I have to edit one I count myself lucky if it's just some posix shell script that, while admittedly not being exactly elegant, is in most parts comprehensible to me without in-depth study of some init system manual. Hence, I for one am content with the imperfect well-hung sysv-rc init. I'd however never try to force that attitude onto other people. (Not implying you did, mind you, just generally speaking here.) Each to their own, I'd say. While I agree that a lot of rc-style scripts look quite messy, at least these are plain shell scripts, giving full control over as much minutiae of daemon behavior as is conceivably possible, as the author is provided with virtually unrestricted access to the complete toolbox of standard unix utilities to pick from in order to accomplish his task. On the other hand, concise configuration files as used by many non-rc-style init systems have their own charm, but this gain in elegance comes at the expense of handing over a lot of fine grained control specifics to (a set of more or less integrated) binaries that behave to at least some degree opaque to the casual observer. This offloading of nitty-gritty specifics can come as either a blessing or a curse, depending on the case at hand. In the big picture, rc-style init systems constitute (almost) one extreme of the spectrum, while systemd is the perfect example for the other extreme, i.e. what happens when scope creep takes the alleged simplification more than a few steps too far by basically building a shadow OS, epitomized as a nightmarish hairball of elements that each are individually inferior compared to their "do one thing" unixish counterparts in the actual OS. Somewhere among this vast spectrum between spaghetti script and three-liners consumed by incomprehensible pseudo-modular binary monsters there should be something suitable for virtually anybody. And that is what makes me buy into the notion of init freedom as a declared objective of Devuan. As always this post is worth what you paid for it, YMMV, etc. Regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list
Re: [DNG] systemd and ssh-server
On Thu, 26 Jul 2018 13:17:21 +0200 Irrwahn wrote: > Hendrik Boom wrote on 26.07.2018 12:35: > > On Wed, Jul 25, 2018 at 06:50:43PM +0200, Irrwahn wrote: > >> Hendrik Boom wrote on 25.07.2018 17:59: > >> [cut] > >>> Package dependencies are of the form > >>> Install X if Y is installed > >>> Too bad it doesn't handle > >>> Install X it Y and Z are installed. > >>> I suspect, though, we don't wand to have to embed a SAT solver > >>> into the package manager. It's already complicated enough. > >> > >> Hi Hendrik, > >> > What's more, I'd > go even further and say I wouldn't mind at all if every daemon > package came with support for all init systems in current use > (rc-style sysv|openrc, runit, ... , systemd), as that would make > switching init systems in an already installed system much, much less > of a pain in the rear. Why would I care about a few dozen tiny > innocuous unused files on a system that per default install is > already cluttered with literally thousands of files I'm never going > to use in any way. I write my own daemons. There may come a time when I put a free software license on one of them and distribute it to the world. If I did so, I might (or might not) include the runit run script I use to run it. If I were feeling particularly nice that day, I might also supply an s6 run script, because s6 run scripts are almost 1 to 1 translations from runit. But there's no way I'd ever take the time to supply facilities for startup in sysvinit, OpenRC, systemd or busybox. **Not my job!** > That'd be what I'd call "init freedom". It's very unlikely to happen > in the foreseeable future though, as it would require cooperative > effort of hundreds of individuals to include and maintain those init > support files in the respective packages. Now it sounds like you're talking about something else. It now sounds like you're talking about a group of init experts making startup facilities for programs using various inits. This is a good idea. A systemd unit file, or an s6 or runit run script offer excellent documentation for how to configure the application for just about any init system. sysvinit and OpenRC typically have init scripts tens or hundreds of lines, making init integration of an application seem like an arcane art. What are they thinking? IMHO these immense and unfathomable init scripts are what opened the door for systemd. SteveT Steve Litt Author: The Key to Everyday Excellence http://www.troubleshooters.com/key Twitter: http://www.twitter.com/stevelitt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Thu, 26 Jul 2018 16:45:29 +0200 info at smallinnovations dot nl wrote: > systemd is in principle > nothing new in functionality but provides an uniform API for some > information you otherwise have to program yourself. We can serve them > the same information without serving systemd this way. And as a start > just supporting the most used API calls instead of the whole API. Wasn't there something called uselessd that had this very goal some time ago? It was promising but died, I don't know why ... Luciano. -- /"\ /Via A. Salaino, 7 - 20144 Milano (Italy) \ / ASCII RIBBON CAMPAIGN / PHONE : +39 2 485781 FAX: +39 2 48578250 X AGAINST HTML MAIL/ E-MAIL: posthams...@sublink.sublink.org / \ AND POSTINGS/ WWW: http://www.lesassaie.IT/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 26-07-18 16:34, Steve Litt wrote: > On Thu, 26 Jul 2018 12:45:53 +0200 > info at smallinnovations dot nl wrote: >> >> Of course does the libsystemd API not provide it, but we can. First >> call to libsystemd API == systemd installed? If no, call to >> libnosystemd API which init system == installed? Or something like >> that. But put in place a mechanism that allows to shell out the calls >> to libsystemd functions to a set of scripts with pre-defined names >> would make libnosystemd far more useful imo. Especially for >> developers. > How would you like to be the maintenance programmer in charge of such > shelled out code? Are we not, at this point, reinventing the complexity > that was systemd? > > SteveT > > > Steve Litt > Author: The Key to Everyday Excellence > http://www.troubleshooters.com/key > Twitter: http://www.twitter.com/stevelitt That depends: from a developers point of view systemd is in principle nothing new in functionality but provides an uniform API for some information you otherwise have to program yourself. We can serve them the same information without serving systemd this way. And as a start just supporting the most used API calls instead of the whole API. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Thu, 26 Jul 2018 12:45:53 +0200 info at smallinnovations dot nl wrote: > On 26-07-18 12:15, KatolaZ wrote: > > > > The libsystemd API does not provide any way to check *which* init > > system is running (ehm...for "obvious" reasons, right?). But we > > could put in place a mechanism that allows to shell out the calls to > > libsystemd functions to a set of scripts with pre-defined names. > > Then, the system administrator or the packagers can put whatever > > they want in those scripts, or even remove them altogether. > > > > This would in principle allow people to "catch" systemd-related > > events and "translate" them to events for any other init system, > > using a simple mechanism. Or just plainly ignore them, if they > > like... > > > > My2Cents > > > > KatolaZ > > > Of course does the libsystemd API not provide it, but we can. First > call to libsystemd API == systemd installed? If no, call to > libnosystemd API which init system == installed? Or something like > that. But put in place a mechanism that allows to shell out the calls > to libsystemd functions to a set of scripts with pre-defined names > would make libnosystemd far more useful imo. Especially for > developers. How would you like to be the maintenance programmer in charge of such shelled out code? Are we not, at this point, reinventing the complexity that was systemd? SteveT Steve Litt Author: The Key to Everyday Excellence http://www.troubleshooters.com/key Twitter: http://www.twitter.com/stevelitt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Thu, 26 Jul 2018 12:15:13 +0200 KatolaZ wrote: > This would in principle allow people to "catch" systemd-related events > and "translate" them to events for any other init system, using a > simple mechanism. Sounds like a great idea. The daemon phones home to what it thinks is systemd to day "I'm functional", and that info is given to runit. Cool! And then I begin to think some more. That notification is given via dbus. And what, runit must *listen for* this event? With what daemon? And how do we know that the daemon defines "functional" the same way we do? What if the daemon chooses to call itself functional when it achieves a network link, whereas the admin considers it functional only when it can ping http://www.troubleshooters.com? > Or just plainly ignore them, if they like... Upon further consideration, ignoring it sounds like a great idea. SteveT Steve Litt Author: The Key to Everyday Excellence http://www.troubleshooters.com/key Twitter: http://www.twitter.com/stevelitt ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Do den 26. Jul 2018 um 14:23 schrieb Lars Noodén: > Looking at the DSC files, it seems that the culprit is either gnome or > ssh-askpass-gnome or both. > > Is there an alternative ssh-askpass-* graphical utility likely to be > more portable which can replace it? Well, I use gpg-agent instead of ssh-agent. That is a better way to handle keys and allows more control for about how long you allow the keys/pass to get cached. And gpg-agent uses pinentry that is available in many flavours. 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/UMJJLQEpnwKsYAZ9qwFAltZzDIACgkQpnwKsYAZ 9qyPwAwAo2lVEwrIAUK07cHvz6B/XcTBrc1yC6/qYZZjofb78MUz6nN+NfZz9kwP 1YZZMRMmVUn4H4Ek4RxKoi6jm2ZanbA/oWxwA5ATdMF7QlJeErNnExqA9BYQTYv8 Ur8uqRtyg4BJp38R2W95ru0M44jjYxARYgg87pI7twc14qy/SCc4MG2d9xnr7vBb Rc0dANwHS+6gv6gKWbF52ZrQxqQMTvDL4OFXluqZ/GxLcdDw5vYMR3zrc6gvNuar 4jX4lWJj1bhQ3ndEe3HFld0MAvtgHubNsxekaqNsnxoXfbTyRiN9MGFCDdvL6zhc ZwDgTlhmWtrNY89aTb0ME9WlVGtSj+XkctLb3kwtnTSbsNzN52+mHRFCiQkr8iJ+ Z1Uoskxux9ORFnt8A4MCfuPdXVamxONlM8lFgWIbXikKqFSuv3gjRwYoW1wN28PE WpeK6iN6/oL3gxzHdVITqj2hcW7zZAo6C3kKqHv7dgXCupIpyctPep/PK8Bhu6zv sdpgEszO =+QjX -END PGP SIGNATURE- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 07/26/2018 04:01 PM, Klaus Ethgen wrote:> Hi, > > Am Mo den 23. Jul 2018 um 14:24 schrieb Rolf Schmidt: >> I would ask, if it is true, that the openssh-server still needs >> libsystemd0 in ascii? > >> Can I expect e fix? > > If you trust me ( :-D ) you can use my package[0].[snip] Looking at the DSC files, it seems that the culprit is either gnome or ssh-askpass-gnome or both. Is there an alternative ssh-askpass-* graphical utility likely to be more portable which can replace it? /Lars ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi, Am Mo den 23. Jul 2018 um 14:24 schrieb Rolf Schmidt: > I would ask, if it is true, that the openssh-server still needs > libsystemd0 in ascii? > > Can I expect e fix? If you trust me ( :-D ) you can use my package[0]. It is the debian package cleaned from systemd, the disastrous patch introduced by debian to lower security (user-group-patch) and two other small patches that are not accepted upstream. The most active dist is sid and ceres but I also have 1:7.4p1-11+securityfix1 for ascii and stretch. Regards Klaus [0] deb ftp://ftp.ethgen.ch/pub/debian-security sid unofficial-secured - -- 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/UMJJLQEpnwKsYAZ9qwFAltZxgoACgkQpnwKsYAZ 9qynIwwAszwMF1AJ7F81nP205pvCSgN3mCPGKKQin8gDNhy2ltQonhB8QT85yUk5 XBe8S7Aqz5OgIByriBoe7if2xX2uWTVDLsFni5MJD2BYTwX8kG77ksYnXx7MhLFd RFNNK6JTKcYMMZqniDI4LSAu6WdlHS0Kqw6Lxw6FOZz7Qrh7vanj+elW3ncQGL/I aDaBLG/BnO5mfrdszMMPKDcdOkcwTeBjALXqppNzXkFrvGLiOu0roMWTsrEzxEYB ym9PX3tiSxp0K0aUyZ3L0fFpTN7+0QADrTLp03PaeFR4WgRsW8qF2CktKbQq0srF gmnz5DyVjgnTn8NfoPrdgbfhaZhulc8UIbtNPncvLdFNxvdDsH5CO0W27LqsLObW Rn+ockWovVCXlOscs4EescBKoRAbbONDO8KsIciiXCQhfLvDBARnHTG/2zxXv6Hx BeNfSvCVzCt1Jbt+X3W7xlQN9Fk8nFk30CsoPJn8ugFsNJzkzAOhC8vsLtVSDbcr nl+GzVao =YKjn -END PGP SIGNATURE- ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Hi, KatolaZ writes: > On Thu, Jul 26, 2018 at 12:45:53PM +0200, info at smallinnovations dot nl > wrote: >> On 26-07-18 12:15, KatolaZ wrote: >> > >> > The libsystemd API does not provide any way to check *which* init >> > system is running (ehm...for "obvious" reasons, right?). But we could >> > put in place a mechanism that allows to shell out the calls to >> > libsystemd functions to a set of scripts with pre-defined names. Then, >> > the system administrator or the packagers can put whatever they want >> > in those scripts, or even remove them altogether. >> > >> > This would in principle allow people to "catch" systemd-related events >> > and "translate" them to events for any other init system, using a >> > simple mechanism. Or just plainly ignore them, if they like... >> > >> Of course does the libsystemd API not provide it, but we can. First call >> to libsystemd API == systemd installed? If no, call to libnosystemd API >> which init system == installed? Or something like that. But put in place >> a mechanism that allows to shell out the calls to libsystemd functions >> to a set of scripts with pre-defined names would make libnosystemd far >> more useful imo. Especially for developers. >> > But that would entail forking and patching all the packages which use > libsystemd to force them to check if systemd is available... which is > exactly what we are trying to avoid by nooping libsystemd0... :P Exactly. Any package that Provides: libsystemd0 is *not* at liberty to change that library's documented API. No matter how much you may dislike that API and whatever it stands for, you either provides an API compliant replacement OR you end up forking every package that depends on libsystemd0. 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] systemd and ssh-server
Hi, Joel Roth writes: > Katolaz wrote on March 2, 2018: > >> leloft wrote: > >> >> I issued $locate systemd >> and got 200 lines of output, including >> /etc/systemd/system/* (23 files) >> /lib/systemd/system/* (60 files) >> /lib/x86_64-linux-gnu/libsystemd.so.0 (and 0.17.0) >> /usr/lib/systemd (25 files) >> /usr/bin/deb-systemd-helper ((and deb-systemd-invoke) >> /var/lib/systemd/deb-systemd-helper-enabled/* (68 files) >> /var/lib/dpkg/info/libsystemd):amd64* (5 files) >> >> This seems a lot to me. Please could you confirm that an ascii >> installation should contain 200 systemd files as part of a normal >> ascii installation. Sorry to trouble you if these are trivial >> questions, but they feel far from that. >> Many thanks >> leloft > > Most of those "alarming" files are just systemd units files, put there > by daemons/packages/utilities who "also" support systemd in a way or > another. So they are not alarming but just *totally* *harmless* if you > don't have a running systemd as PID 1, since only systemd understands > and can run them. It would be *totally* *useless* (and utterly > *stupid* IMHO) to fork, rebuild, and maintain a few more hundred > packages only because they happen to provide a systemd unit file for > those systems where systemd is used. Actually, you can keep these files off your systems fairly easily without the need to fork, rebuild and maintain piles of packages. The idea is to exploit the power of dpkg's --path-exclude option. Please note that the dpkg(1) manual page says Warning: take into account that depending on the excluded paths you might completely break your system, use with caution. So if you try this and stuff breaks you get to keep the pieces ;-/ You can add a /etc/dpkg/dpkg.cfg.d/systemd-razor file that contains path-exclude globs for all the systemd files you want to get rid of like so path-exclude=*systemd* path-include=/etc/dpkg/dpkg.cfg.d/systemd-razor although you might just want to be a bit more subtle ;-) # See dpkg.cfg(5) for (scant) details. The above prevents installation of any new "offending" files (while keeping the systemd-razor file installed, doh). To get rid of files already installed, you can retro-actively apply the above on what's installed already like so-ish find / -name '*systemd*' ! -name systemd-razor -delete with appropriate privileges, i.e. as root. Please adjust if you used a more (set of) exclude patterns. People that want to do so can do this themselves rightaway and Devuan *could* add this dpkg.cfg.d file to a suitable package (and the find invocation in that package's postinst). The latter only after a good deal of testing of course. Disclaimer: None of the above has been tested (although I do use this approach to clean out /usr/share/doc in my devuan/slim Docker images, see https://gitlab.com/paddy-hack/devuan). 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] systemd and ssh-server
On Thu, Jul 26, 2018 at 12:45:53PM +0200, info at smallinnovations dot nl wrote: > On 26-07-18 12:15, KatolaZ wrote: > > > > The libsystemd API does not provide any way to check *which* init > > system is running (ehm...for "obvious" reasons, right?). But we could > > put in place a mechanism that allows to shell out the calls to > > libsystemd functions to a set of scripts with pre-defined names. Then, > > the system administrator or the packagers can put whatever they want > > in those scripts, or even remove them altogether. > > > > This would in principle allow people to "catch" systemd-related events > > and "translate" them to events for any other init system, using a > > simple mechanism. Or just plainly ignore them, if they like... > > > > My2Cents > > > > KatolaZ > > > Of course does the libsystemd API not provide it, but we can. First call > to libsystemd API == systemd installed? If no, call to libnosystemd API > which init system == installed? Or something like that. But put in place > a mechanism that allows to shell out the calls to libsystemd functions > to a set of scripts with pre-defined names would make libnosystemd far > more useful imo. Especially for developers. > But that would entail forking and patching all the packages which use libsystemd to force them to check if systemd is available... which is exactly what we are trying to avoid by nooping libsystemd0... :P HND KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Hendrik Boom wrote on 26.07.2018 12:35: > On Wed, Jul 25, 2018 at 06:50:43PM +0200, Irrwahn wrote: >> Hendrik Boom wrote on 25.07.2018 17:59: >> [cut] >>> Package dependencies are of the form >>> Install X if Y is installed >>> Too bad it doesn't handle >>> Install X it Y and Z are installed. >>> I suspect, though, we don't wand to have to embed a SAT solver into the >>> package manager. It's already complicated enough. >> >> Hi Hendrik, >> >> I'm not entirely sure I correctly understand what you think that could >> accomplish. In case you meant it the way I _think_ you did, this would >> be my two cents worth of comment: >> >> It wouldn't help a bit, at least in the case at hand. The package >> dependency exists to make sure a library (here: libsystemd.so.0) the >> application (here: sshd) was linked against is present on the system, >> as otherwise the application would simply fail to start, which is >> undesirable. > > I was thinking about package Y, which has systemd init script in package Xd, > depend on package Xd only if systemd is present. > > No linking involved. > > But I agree that adding such a mechanism would greaty complicate the > package manager, likely beyond feasibility. Not worth it if it's only > to avoid a few small files that may never be used. > Oh, you were talking about init scripts and unit files and the like, so I did get you wrong after all. I agree it's not worth it, for the reasons you gave. What's more, I'd go even further and say I wouldn't mind at all if every daemon package came with support for all init systems in current use (rc-style sysv|openrc, runit, ... , systemd), as that would make switching init systems in an already installed system much, much less of a pain in the rear. Why would I care about a few dozen tiny innocuous unused files on a system that per default install is already cluttered with literally thousands of files I'm never going to use in any way. That'd be what I'd call "init freedom". It's very unlikely to happen in the foreseeable future though, as it would require cooperative effort of hundreds of individuals to include and maintain those init support files in the respective packages. Regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 26-07-18 12:15, KatolaZ wrote: > > The libsystemd API does not provide any way to check *which* init > system is running (ehm...for "obvious" reasons, right?). But we could > put in place a mechanism that allows to shell out the calls to > libsystemd functions to a set of scripts with pre-defined names. Then, > the system administrator or the packagers can put whatever they want > in those scripts, or even remove them altogether. > > This would in principle allow people to "catch" systemd-related events > and "translate" them to events for any other init system, using a > simple mechanism. Or just plainly ignore them, if they like... > > My2Cents > > KatolaZ > Of course does the libsystemd API not provide it, but we can. First call to libsystemd API == systemd installed? If no, call to libnosystemd API which init system == installed? Or something like that. But put in place a mechanism that allows to shell out the calls to libsystemd functions to a set of scripts with pre-defined names would make libnosystemd far more useful imo. Especially for developers. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Wed, Jul 25, 2018 at 06:50:43PM +0200, Irrwahn wrote: > Hendrik Boom wrote on 25.07.2018 17:59: > [cut] > > Package dependencies are of the form > > Install X if Y is installed > > Too bad it doesn't handle > > Install X it Y and Z are installed. > > I suspect, though, we don't wand to have to embed a SAT solver into the > > package manager. It's already complicated enough. > > Hi Hendrik, > > I'm not entirely sure I correctly understand what you think that could > accomplish. In case you meant it the way I _think_ you did, this would > be my two cents worth of comment: > > It wouldn't help a bit, at least in the case at hand. The package > dependency exists to make sure a library (here: libsystemd.so.0) the > application (here: sshd) was linked against is present on the system, > as otherwise the application would simply fail to start, which is > undesirable. I was thinking about package Y, which has systemd init script in package Xd, depend on package Xd only if systemd is present. No linking involved. But I agree that adding such a mechanism would greaty complicate the package manager, likely beyond feasibility. Not worth it if it's only to avoid a few small files that may never be used. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Thu, Jul 26, 2018 at 12:01:54PM +0200, info at smallinnovations dot nl wrote: > On 26-07-18 10:00, KatolaZ wrote: > > > > The main problem is that those packages need to be maintained, and not > > just stripped of the libsystemd0 dependency once, and then forgotten, > > which is what happened with most of the Jessie packages that were > > forked for that reason. > > > > The medium-term plan is to replace libsystemd0 with a libnosystemd > > which Provides: libsystemd0 and noops everything, with the possibility > > of shelling-out some actions, if the admin wants so. We will get > > there. > > > > My2Cents > > > > KatolaZ > > > > Main question is which direction do we go with libsystemd0. Creating a > libnosystemd sounds like a good idea to me. Too bad i do not have > developer skills in that area. But i cloned the git repo to take a look > at it and i wonder if there is a way to supply certain information from > daemons if installed to make better use of it. Better in the way that it > not only tells no systemd installed but make some information available > like which init system is installed. Or other useful information. The libsystemd API does not provide any way to check *which* init system is running (ehm...for "obvious" reasons, right?). But we could put in place a mechanism that allows to shell out the calls to libsystemd functions to a set of scripts with pre-defined names. Then, the system administrator or the packagers can put whatever they want in those scripts, or even remove them altogether. This would in principle allow people to "catch" systemd-related events and "translate" them to events for any other init system, using a simple mechanism. Or just plainly ignore them, if they like... My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 26-07-18 10:00, KatolaZ wrote: > > The main problem is that those packages need to be maintained, and not > just stripped of the libsystemd0 dependency once, and then forgotten, > which is what happened with most of the Jessie packages that were > forked for that reason. > > The medium-term plan is to replace libsystemd0 with a libnosystemd > which Provides: libsystemd0 and noops everything, with the possibility > of shelling-out some actions, if the admin wants so. We will get > there. > > My2Cents > > KatolaZ > Main question is which direction do we go with libsystemd0. Creating a libnosystemd sounds like a good idea to me. Too bad i do not have developer skills in that area. But i cloned the git repo to take a look at it and i wonder if there is a way to supply certain information from daemons if installed to make better use of it. Better in the way that it not only tells no systemd installed but make some information available like which init system is installed. Or other useful information. Another item: is there a resource (preferred text) how to maintain a package? I would not mind to maintain 1 or 2 packages but i do not have a clue how to do that. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Simon Hobson wrote on 25.07.2018 23:25: > KatolaZ wrote: > >> Replace 'links2' with 'openssh-server' and 'libfbdirect' with >> 'libsystemd0', and you should see what I mean. Most of the De??an >> installations actually have tons of libraries that are never used, or >> are just used to probe for a certain functionality that is not >> available. This happens all the time, under the hood. > > Well yyeee, and no. > AIUI it is **possible** to write your program with functionality along the > lines of : > - test if libx is available > - if so > -- load libx > -- call function y to see if facility z is available And there's also the option of linking statically at build time. Please note I'm mentioning this only for completeness' sake, not that I actually propose to descend to that ring of hell. (Except for the few and far between well defined cases where this is actually a reasonable thing to do.) Static linking: After shooting your foot you rebuild the world to recover. Dynamic linking: You shoot everyone's foot at once in a single shot. Moral of the story: There is no silver bullet. Regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Wed, Jul 25, 2018 at 10:25:32PM +0100, Simon Hobson wrote: > KatolaZ wrote: > > > Replace 'links2' with 'openssh-server' and 'libfbdirect' with > > 'libsystemd0', and you should see what I mean. Most of the De??an > > installations actually have tons of libraries that are never used, or > > are just used to probe for a certain functionality that is not > > available. This happens all the time, under the hood. > > Well yyeee, and no. > AIUI it is **possible** to write your program with functionality along the > lines of : > - test if libx is available How do you do that at runtime, exactly, and in a portable way? The only way would be using libdl, but that's a pretty shitty way of using libraries, if you have to use that all the time. > - if so > -- load libx > -- call function y to see if facility z is available > > > But that's a fair bit more work than just : > (assume libx is present, link to libx when building binary) > - call function y and let the system take care of loading libx > > Certainly when I raised a bug report against clamav the response was a "quite > emphatic" "that's how it works, if libsystemd0 isn't present then your system > is broken because that's now Debian policy". It's clear that libsystemd > linkage is here to stay in Debian packaging, and it's equally clear that > rebuilding **LOTS** of packages *just* to remove that one call to find out > that systemd isn't present would not be a good use of the limited developer > time & skills available. The main problem is that those packages need to be maintained, and not just stripped of the libsystemd0 dependency once, and then forgotten, which is what happened with most of the Jessie packages that were forked for that reason. The medium-term plan is to replace libsystemd0 with a libnosystemd which Provides: libsystemd0 and noops everything, with the possibility of shelling-out some actions, if the admin wants so. We will get there. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
KatolaZ wrote: > Replace 'links2' with 'openssh-server' and 'libfbdirect' with > 'libsystemd0', and you should see what I mean. Most of the De??an > installations actually have tons of libraries that are never used, or > are just used to probe for a certain functionality that is not > available. This happens all the time, under the hood. Well yyeee, and no. AIUI it is **possible** to write your program with functionality along the lines of : - test if libx is available - if so -- load libx -- call function y to see if facility z is available But that's a fair bit more work than just : (assume libx is present, link to libx when building binary) - call function y and let the system take care of loading libx Certainly when I raised a bug report against clamav the response was a "quite emphatic" "that's how it works, if libsystemd0 isn't present then your system is broken because that's now Debian policy". It's clear that libsystemd linkage is here to stay in Debian packaging, and it's equally clear that rebuilding **LOTS** of packages *just* to remove that one call to find out that systemd isn't present would not be a good use of the limited developer time & skills available. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Wed, Jul 25, 2018 at 11:59:06AM -0400, Hendrik Boom wrote: > On Tue, Jul 24, 2018 at 10:20:56PM -1000, Joel Roth wrote: > > > Katolaz wrote on March 2, 2018: > > > > > > > Most of those "alarming" files are just systemd units files, put there > > by daemons/packages/utilities who "also" support systemd in a way or > > another. So they are not alarming but just *totally* *harmless* if you > > don't have a running systemd as PID 1, since only systemd understands > > and can run them. It would be *totally* *useless* (and utterly > > *stupid* IMHO) to fork, rebuild, and maintain a few more hundred > > packages only because they happen to provide a systemd unit file for > > those systems where systemd is used. > > Package dependencies are of the form > Install X if Y is installed > Too bad it doesn't handle > Install X it Y and Z are installed. > I suspect, though, we don't wand to have to embed a SAT solver into the > package manager. It's already complicated enough. > Nope. Package dependencies are in the form: X needs Y You have no way of specifying: X needs Y only of Z is present otherwise it needs W especially because Z can be added or removed at a later time. Also, packages ship binaries, and binaries are already compiled, so if your binary was linked against libfbdirect, you need libfbdirect to be able to run it, even if you'll never use the capabilities of libfbdirect. The example of the libfbdirect dependency I have in mind is that of links2: the dep is there even if you will always use links2 only in a virtual terminal, i.e. not in a framebuffer, and links2 will never call any of those libfbdirect functions. Or, it will just call one of them, realise that a framebuffer is not available, and signal it to the user, and/or abort execution with an error. Replace 'links2' with 'openssh-server' and 'libfbdirect' with 'libsystemd0', and you should see what I mean. Most of the De??an installations actually have tons of libraries that are never used, or are just used to probe for a certain functionality that is not available. This happens all the time, under the hood. The alternative to this is to use something like gentoo. Or Linux From Scratch. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: PGP signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
Hendrik Boom wrote on 25.07.2018 17:59: [cut] > Package dependencies are of the form > Install X if Y is installed > Too bad it doesn't handle > Install X it Y and Z are installed. > I suspect, though, we don't wand to have to embed a SAT solver into the > package manager. It's already complicated enough. Hi Hendrik, I'm not entirely sure I correctly understand what you think that could accomplish. In case you meant it the way I _think_ you did, this would be my two cents worth of comment: It wouldn't help a bit, at least in the case at hand. The package dependency exists to make sure a library (here: libsystemd.so.0) the application (here: sshd) was linked against is present on the system, as otherwise the application would simply fail to start, which is undesirable. Regards, Urban -- Sapere aude! signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Tue, Jul 24, 2018 at 10:20:56PM -1000, Joel Roth wrote: > Katolaz wrote on March 2, 2018: > > > Most of those "alarming" files are just systemd units files, put there > by daemons/packages/utilities who "also" support systemd in a way or > another. So they are not alarming but just *totally* *harmless* if you > don't have a running systemd as PID 1, since only systemd understands > and can run them. It would be *totally* *useless* (and utterly > *stupid* IMHO) to fork, rebuild, and maintain a few more hundred > packages only because they happen to provide a systemd unit file for > those systems where systemd is used. Package dependencies are of the form Install X if Y is installed Too bad it doesn't handle Install X it Y and Z are installed. I suspect, though, we don't wand to have to embed a SAT solver into the package manager. It's already complicated enough. -- hendrik ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On Wed, Jul 25, 2018 at 02:41:52AM -0500, goli...@dyne.org wrote: > On 2018-07-25 02:11, Hleb Valoshka wrote: > > On 7/23/18, Rolf Schmidt wrote: > > > > > I would ask, if it is true, that the openssh-server still needs > > > libsystemd0 in ascii? > > > > Yes. > > > > > Can I expect e fix? > > > > It's required just to notify systemd that sshd is running, so in > > systemd-less system it's nop. So mostly libsystemd0 is harmless. > > > > Currently Devuan team doesn't have enough man power to fork every > > single package just to cleanup its dependencies. > > ___ > > > > According to KatolaZ libsystemd is "*totally* *harmless* if you > don't have a running systemd as PID 1". It is however annoying to have to > see it though. > > https://dev1galaxy.org/viewtopic.php?pid=7853#p7853 > > Unfortunately the archive of that post has been corrupted and is no longer > available. Katolaz wrote on March 2, 2018: > leloft wrote: > > I issued $locate systemd > and got 200 lines of output, including > /etc/systemd/system/* (23 files) > /lib/systemd/system/* (60 files) > /lib/x86_64-linux-gnu/libsystemd.so.0 (and 0.17.0) > /usr/lib/systemd (25 files) > /usr/bin/deb-systemd-helper ((and deb-systemd-invoke) > /var/lib/systemd/deb-systemd-helper-enabled/* (68 files) > /var/lib/dpkg/info/libsystemd):amd64* (5 files) > > This seems a lot to me. Please could you confirm that an ascii > installation should contain 200 systemd files as part of a normal > ascii installation. Sorry to trouble you if these are trivial > questions, but they feel far from that. > Many thanks > leloft Most of those "alarming" files are just systemd units files, put there by daemons/packages/utilities who "also" support systemd in a way or another. So they are not alarming but just *totally* *harmless* if you don't have a running systemd as PID 1, since only systemd understands and can run them. It would be *totally* *useless* (and utterly *stupid* IMHO) to fork, rebuild, and maintain a few more hundred packages only because they happen to provide a systemd unit file for those systems where systemd is used. libsystemd0 is used by some daemons to verify if systemd is running or not. If it's not, libsystemd is *totally* *harmless*. HND KatolaZ P.S.: I guess we should consider including the last two paragraphs above on www.devuan.org, or put it in the mailing list signature... -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 2018-07-25 02:11, Hleb Valoshka wrote: On 7/23/18, Rolf Schmidt wrote: I would ask, if it is true, that the openssh-server still needs libsystemd0 in ascii? Yes. Can I expect e fix? It's required just to notify systemd that sshd is running, so in systemd-less system it's nop. So mostly libsystemd0 is harmless. Currently Devuan team doesn't have enough man power to fork every single package just to cleanup its dependencies. ___ According to KatolaZ libsystemd is "*totally* *harmless* if you don't have a running systemd as PID 1". It is however annoying to have to see it though. https://dev1galaxy.org/viewtopic.php?pid=7853#p7853 Unfortunately the archive of that post has been corrupted and is no longer available. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] systemd and ssh-server
On 7/23/18, Rolf Schmidt wrote: > I would ask, if it is true, that the openssh-server still needs > libsystemd0 in ascii? Yes. > Can I expect e fix? It's required just to notify systemd that sshd is running, so in systemd-less system it's nop. So mostly libsystemd0 is harmless. Currently Devuan team doesn't have enough man power to fork every single package just to cleanup its dependencies. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
