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] [OT] Restricting user capabilities after ssh login
On 10/10/18 at 22:33, Alessandro Selli wroe: > Il 10/10/18 18:51, Lars Noodén ha scritto: >> On 10/10/18 7:30 PM, Alessandro Selli wrote: >>> Works for me: >> ...> [root@wrkstn02 ~]# lsb_release -d ; uname -r >>> Description: Devuan GNU/Linux 2.0 (ascii) >>> 4.18.0-0.bpo.1-amd64 >> Hmmm. I'm using just the stock kernel. Maybe that is the difference: >> >> $ lsb_release -d; uname -r >> Description:Devuan GNU/Linux 2.0 (ascii) >> 4.9.0-8-amd64 > > Could be. Mine in from the backports. But I also use custom kernels, > and my own 4.9.131 kernel works, too. Well no, I remembered wrong, my 4.9.* custom kernels cannot start Apparmor, they fail with the same error as the stock 4.9 kernel. > I should install the > linux-image-4.9.0-8-amd64 package and try that to make sure. I might do > that, but now now. I did the test. this is what happens: [alessandro@wksrn05 ~]$ /etc/init.d/apparmor status [info] AppArmor not available as kernel LSM.. failed! [alessandro@wksrn05 ~]$ lsb_release -d ; uname -r Description: Devuan GNU/Linux 2.0 (ascii) 4.9.0-8-amd64 [alessandro@wksrn05 ~]$ i take it LSM is the Linux Security Model kernel config option, CONFIG_SECURITY. This makes the error message strange, as the option is set in the distribution's config file: [alessandro@wksrn05 ~]$ grep -E 'CONFIG_SECURITY(|_APPARMOR)=' /boot/config-4.9.0-8-amd64 CONFIG_SECURITY=y CONFIG_SECURITY_APPARMOR=y [alessandro@wksrn05 ~]$ The error message "AppArmor not available as kernel LSM" shows up also as root, so it's not a permission issue. This must mean current version of AppArmor is not compatible with 4.9 kernels, and that you have to install the backports one in order to have AppArmor support on Devuan Ascii. Alessandro -- 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
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] Fwd: Re: Fwd: Re: GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
On Wed, Oct 10, 2018 at 09:22:19PM +0100, Rowland Penny wrote: > On Wed, 10 Oct 2018 13:13:57 -0700 > Bruce Perens wrote: > > > I think this discussion is now so astronomically far from the purpose > > of DNG that it serves no further purpose. Perhaps moderation is > > called for? > > It never was on topic, but then many posts aren't ;-) What it really needs is for the subject line to start with OT. -- hendrik > > I gave up on it when I decided the OP was an idiot. > > Rowland > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Audio woes in Ascii - speakers but no headphones
Today when I plugged in external speakers or earbuds into the audio jack on my notebook, the sound no longer transfers from the built-in speakers to the jack. The sound stops in the built-in speakers as expected but it is not transferred to the jack. If I run pavucontrol and choose "playback" I can see the volume meter hopping around as the sounds are processed. Strangely, if I choose "output devices, port: speakers (unavilable)" I can also see the volume meter being active and if I choose "output devices, port: headphones (plugged in)" then the volume meter goes completely motionless after zeroing out. This is the opposite of what I expect. I had expected that when I plug in the headphones to the audio jack that the sound activity would be shown there. I booted Linux Mint 19's Live image and the audio jack functions as normal there so the problem seems to be with Devuan. I am open for ideas about how to resolve this so that the audio jack may be used again. /Lars $ lsb_release -d; uname -r; Description:Devuan GNU/Linux 2.0 (ascii) 4.9.0-8-amd64 ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
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] Audio woes in Ascii - speakers but no headphones
On Thu, 11 Oct 2018 21:00:40 +0300, Lars wrote in message <08a8e443-ae0f-6857-18d7-48c58df46...@gmail.com>: > Today when I plugged in external speakers or earbuds into the audio > jack on my notebook, the sound no longer transfers from the built-in > speakers to the jack. The sound stops in the built-in speakers as > expected but it is not transferred to the jack. > > If I run pavucontrol and choose "playback" I can see the volume meter > hopping around as the sounds are processed. Strangely, if I choose > "output devices, port: speakers (unavilable)" I can also see the > volume meter being active and if I choose "output devices, port: > headphones (plugged in)" then the volume meter goes completely > motionless after zeroing out. This is the opposite of what I > expect. I had expected that when I plug in the headphones to the > audio jack that the sound activity would be shown there. > > I booted Linux Mint 19's Live image and the audio jack functions as > normal there so the problem seems to be with Devuan. I am open for > ideas about how to resolve this so that the audio jack may be used > again. ..tried alsamixer? ..disclaimer: I run alsa-1.1.3-1 on vdev-0.1.2, not eudev nor systemd-udev etc. Description:Devuan GNU/Linux 2.0 (ascii) + ascii-backports + experimental 4.18.0-0.bpo.1-rt-amd64 -- ..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] Audio woes in Ascii - speakers but no headphones
On Thu, Oct 11, 2018 at 09:00:40PM +0300, Lars Noodén wrote: > I booted Linux Mint 19's Live image and the audio jack functions as > normal there so the problem seems to be with Devuan. I am open for > ideas about how to resolve this so that the audio jack may be used again. I can suggest using a big hammer: apt-get remove pulseaudio > /Lars > > $ lsb_release -d; uname -r; > Description: Devuan GNU/Linux 2.0 (ascii) > 4.9.0-8-amd64 > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Joel Roth ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: Re: Fwd: Re: GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
Quoting Hendrik Boom (hend...@topoi.pooq.com): > What it really needs is for the subject line to start with OT. And for the content to be sung in the shower instead of posted to Dng. ;-> -- 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] Audio woes in Ascii - speakers but no headphones
On 11/10/18 at 21:44, Joel Roth wrote: > On Thu, Oct 11, 2018 at 09:00:40PM +0300, Lars Noodén wrote: >> I booted Linux Mint 19's Live image and the audio jack functions as >> normal there so the problem seems to be with Devuan. I am open for >> ideas about how to resolve this so that the audio jack may be used again. > I can suggest using a big hammer: > > apt-get remove pulseaudio I'd go for the sledgehammer: apt-get -y purge pulseaudio -- 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] Fwd: Re: Fwd: Re: GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
On 11/10/18 at 23:36, Rick Moen wrote: > Quoting Hendrik Boom (hend...@topoi.pooq.com): > >> What it really needs is for the subject line to start with OT. > And for the content to be sung in the shower instead of posted to Dng. ;-> > 😅 -- 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] Fwd: Re: Fwd: Re: GPL version 2 is a bare license. Recind. (Regarding (future) linux Code of Conduct Bannings).
On Wed, 10 Oct 2018 13:01:42 +0200 "Enrico Weigelt, metux IT consult" wrote: > I've seen a lot of self-declared 'social justice warriors', who > finally did more harm than anything useful. Those who really did many > good things, tend to not calling themselves that way. You just couldn't let it rest, could you? > These CoC issues remind me to things happening in other (eg. the > political) field. For example here in Germany (in other European > countries, too) certain movements try to establish certain CoCs to > most areas of daily life, that just shall prohibit them from speaking > their mind, eg.: > > * people against abortion shall be banned/silenced, as they're > discriminating women. > * people against gay marriage shall be banned/silenced, as they're > discriminating gays. > * people against child marriage shall be banned/silenced, as they're > discriminating certain religions / cultures. > * people who speak about crimal immigrants or refugees shall be > banned/ silenced, as they're discriminating them > * people who speak about costs of immigration shall be banned/silenced > as they're discriminating immigrants > * people who differenciate between immigrants and refugees shall be > banned/silenced, as they're discriminating refuguees > > Those demands usually come from 'leftist' groups (mostly beaurocrats, Oh, I get it. You're one of these guys who's just dying to let everyone know how "conservative" you are, even if it means writing offtopic (left vs right) on a thread that *had* been dead for 9 days. Fine. Don your red MAGA hat, and join an anti-immigrant vigilante group. Walk into Starbucks toting your tacticool AR-15 and a strap of 40 round mags. But next time, why don't you post this krap on whatever extreme-right group's mailing lists you frequent, and keep it off technical sites? SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] OpenRC and Runit without SysVinit packages
This is a "remail" of what I sent Daniel about a month ago for others on the mailing list to see with a few changes and added details. First of all, I want to thank the developers for the efforts to continue debian without "systemd creep". I've experimented with the distribution on and off, but there's one big turnoff for me currently that I don't think would take an enormous amount of effort to change: sysvinit. While it does work perfectly fine on its own, I prefer openrc, and runit even more so. While they do work in Devuan, they require sysvinit as a "backend". In Devuan ceres and up, openrc 0.25 provides openrc-init and no longer relies on sysvinit-core. In fact, it can be removed entirely (I have an addiction to removing everything I don't want to use). However, openrc-init boots openrc directly and skips the /etc/inittab file, so it won't start the gettys. All that would be needed to fix this is a separate getty service package. Runit is a different story, since its initialization and shutdown stages rely heavily on sysv-rc scripts (/etc/rc*.d). These scripts can be completely avoided by using an implementation similar to how Void Linux does it. In fact, I did some tweaking with https://github.com/cloux/aws-devuan (https://github.com/cloux/aws-devuan) and https://gitea.artixlinux.org/artix/runit-rc (https://gitea.artixlinux.org/artix/runit-rc). I was able to get a fully booting devuan install without any initscripts. However, these aren't officially supported in Devuan, and should thus not be considered permanent solutions. With that in mind, what would be a permanent solution? I proposed two: 1. Split the runit package into separate packages with alternate stage files. 2. Provide a configuration file for how runit should act. For instance, if openrc or sysvinit is installed, runit can depend on /etc/init.d and /etc/rc*.d scripts for booting. Daniel in response proposed: For your runit proposal we could probably modify or provide a runit source that builds binaries that have the needed changes for each init system it runs alongside - ie runit-sysvinit, runit-openrc, runit-init etc. We can build these from the same source package and just provide the alternate stage files. This makes it also extensible to other init systems down the track. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] OpenRC and Runit without SysVinit packages
This is a "remail" of what I sent Daniel about a month ago for others on the mailing list to see with a few changes and added details. First of all, I want to thank the developers for the efforts to continue debian without "systemd creep". I've experimented with the distribution on and off, but there's one big turnoff for me currently that I don't think would take an enormous amount of effort to change: sysvinit. While it does work perfectly fine on its own, I prefer openrc, and runit even more so. While they do work in Devuan, they require sysvinit as a "backend". In Devuan ceres and up, openrc 0.25 provides openrc-init and no longer relies on sysvinit-core. In fact, it can be removed entirely (I have an addiction to removing everything I don't want to use). However, openrc-init boots openrc directly and skips the /etc/inittab file, so it won't start the gettys. All that would be needed to fix this is a separate getty service package. Runit is a different story, since its initialization and shutdown stages rely heavily on sysv-rc scripts (/etc/rc*.d). These scripts can be completely avoided by using an implementation similar to how Void Linux does it. In fact, I did some tweaking with https://github.com/cloux/aws-devuan (https://github.com/cloux/aws-devuan) and https://gitea.artixlinux.org/artix/runit-rc (https://gitea.artixlinux.org/artix/runit-rc). I was able to get a fully booting devuan install without any initscripts. However, these aren't officially supported in Devuan, and should thus not be considered permanent solutions. With that in mind, what would be a permanent solution? I proposed two: 1. Split the runit package into separate packages with alternate stage files. 2. Provide a configuration file for how runit should act. For instance, if openrc or sysvinit is installed, runit can depend on /etc/init.d and /etc/rc*.d scripts for booting. Daniel in response proposed: For your runit proposal we could probably modify or provide a runit source that builds binaries that have the needed changes for each init system it runs alongside - ie runit-sysvinit, runit-openrc, runit-init etc. We can build these from the same source package and just provide the alternate stage files. This makes it also extensible to other init systems down the track. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Runit without SysVinit packages
On Fri, 12 Oct 2018 03:24:44 + alecfeld...@disroot.org wrote: > 1. Split the runit package into separate packages with alternate > stage files. > > 2. Provide a configuration file for how runit should act. For > instance, if openrc or sysvinit is installed, runit can depend > on /etc/init.d and /etc/rc*.d scripts for booting. On a related note, I think the best way of acquiring runit run files is to install Void Linux on a VM, install all the various daemons, and then view the run files in /etc/sv/$daemonname/run. Void has had enough time supporting runit that most of their run files work great. The exceptions usually assume device names that shouldn't be assumed. Devuan could thus acquire a whole bunch of run scripts and not have to beg the upstreams to do it. SteveT Steve Litt September 2018 featured book: Quit Joblessness: Start Your Own Business http://www.troubleshooters.com/startbiz ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] OpenRC and Runit without SysVinit packages
Quoting alecfeld...@disroot.org (alecfeld...@disroot.org): > First of all, I want to thank the developers for the efforts to > continue debian without "systemd creep". I've experimented with the > distribution on and off, but there's one big turnoff for me currently > that I don't think would take an enormous amount of effort to change: > sysvinit. While it does work perfectly fine on its own, I prefer > openrc, and runit even more so. While they do work in Devuan, they > require sysvinit as a "backend". In Devuan ceres and up, openrc 0.25 > provides openrc-init and no longer relies on sysvinit-core. In fact, > it can be removed entirely (I have an addiction to removing everything > I don't want to use). However, openrc-init boots openrc directly and > skips the /etc/inittab file, so it won't start the gettys. All that > would be needed to fix this is a separate getty service package. You're right, of course. (For clarification purposes, I'm not a Devuan project spokesperson of any kind, just another interested user and longtime sysadmin.) It would be cool if that were done, and maybe the maintainers will figure out the best way to do that. Part of the point I wanted to make, here (bearing in mind that I'm speaking only my own view), is that Devuan needs to be mindful of priorities and has necessarily limited volunteer effort. For better or worse, _if_ I understand correctly, for now Devuan's primary delivery target for current and future releases involves SysVInit. As it hapens, I personally share your liking for OpenRC over SysVInit, and respect runit based on readings but haven't experimented with it as Steve Litt has. But my point is that, if I guess correctly, in the short term there may not be enough time/effort available to build in fully packaged, optimally architected implementations of those two init systems. The other immediate thought I had, and I'll just throw this out as a slightly rhetorical question: Is it so bad to retain the PID1-process fragment of SysVinit, e.g., as what runs the OpenRC init system? Seems to me, it's the part of SysVinit nobody has any significant problem with. It's not unreasonably complex, it's not notably buggy, and it's certainly not overfeatured. I note with interest and appreciation your suggestions about how runit might be provided in better built packaging, but will leave it to others (such as my friend Steve Litt) to comment. Daniel's wording about a way to extend these ideals into a framework for other init systems is particularly cheering, so thanks for posting that. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
