[DNG] Not installing files to /boot Debian discussion
Hi! Not installing files to /boot https://lists.debian.org/debian-kernel/2022/09/msg00062.html I hope this will be rejected by Debian community. EFI has a partition already, why then use FAT filesystem for /boot is beyond me. Especially as EFI should be replaced by something sane anyway. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Another problem you won't have without Systemd (or separate oomd)
Hi! You cannot make this up, can you? Bug 2119518 - GNOME being OOM killed during basic use on VM with 2G of RAM https://bugzilla.redhat.com/show_bug.cgi?id=2119518 It still seems to be that people think adding complexity comes without risk of malfunction. oomd may make sense in certain cloud based workloads, maybe, just maybe. However… on a desktop? You are frigging kidding me, aren't you? Thank you for Devuan! Thank you for some sanity. And yeah, it appears that with Debian oomd is not installed as standard so far, but if its in Fedora, it may come with Debian at some point in time. Or not, after their recent experiences in Fedora :) Maybe people can still learn. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Be prepared for the fall of systemd
Joel Roth via Dng - 05.08.22, 21:56:01 CEST: > On Fri, Aug 05, 2022 at 03:05:54PM +, jkinney23--- via Dng wrote: > > On Thursday, August 4, 2022, 02:53:33 p.m. PDT, Bruce Perens via > > Dng wrote: > > > I haven't followed more modern experimental operating systems. > > > Mostly you don't hear as much about them these days, I think a > > > lot of researchers use an existing Open Source OS as a base for > > > some specific facility.> > > That's a little disheartening to hear. I have been trying to find a > > program in Canada where I can go study operating systems. Is there > > no one anywhere doing serious OS research anymore? ...I guess I > > will stay with Youtube and the Devuan mailing list then :) > > Jöchen Liedke, who died a few years ago, was doing some > interesting work: the L3 operating system, leading > to the L4 microkernel and hypervisor framework. > Looks like Pistachio is the latest, without much > recent activity. > > https://l4ka.org/ > > The L4Linux project is still active: > > https://l4linux.org/ Also Genode and SculptOS are being actively developed. https://genode.org/ https://genode.org/download/sculpt I did not review those yet. They have mailinglists: https://genode.org/community/mailing-lists Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Lennart now working for Microsoft
Peter Duffy - 11.07.22, 11:37:09 CEST: > It's an interesting development, and in a strange way it feels as > though it's been coming. > > IBM owns Redhat and M$ owns systemd (Poettering has said that he's > continuing to work on systemd. Presumably that's not going to be in > his spare time ;) ). I wonder how that's going to play out. Maybe M$ > will make IBM an offer for Redhat. > > It seems to me that at the very least, the fact that systemd is now > M$- tainted is going to make a lot more people start to think about > dropping it. That's probably good news for Devuan, and other distros > that have already eschewed systemd. Thanks for providing that additional insight that Lennart Poettering has said he will continue to work on Systemd. And yeah, the role of Microsoft regarding free software IMHO is not a good one in general. No, they did not change. There are still about creating monopolies. Office 365 shows. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Lennart now working for Microsoft
Hi! How come that I am not surprised? I said it back then already that Systemd adoption followed a similar pattern to Microsoft's "embrace, extend, and extinguish" tactics. (They are still following the very same pattern, this time with Office 365.) Well… I won't miss him. I hope he stops developing for Linux altogether. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Another reason for why I use Devuan
Hi! https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1958377/ comments/13 as in Systemd does not configure the network if the machine has no machine-id. You cannot make this up, or can you? Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] What is your take on finit?
Hi! I saw this coming into Debian Sid, so should be available in Devuan Ceres as well: https://troglobit.com/projects/finit/ Sounds interesting, I'd say. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] merged /usr breakage
k...@aspodata.se - 03.01.22, 18:25:12 CET: > The first one gives me an unbootable system > $ ldd /sbin/init | grep /usr > libpcre2-8.so.0 => /usr/lib/x86_64-linux-gnu/libpcre2-8.so.0 > (0x7f737ba28000) […] > Soo, what can I do to help with that ? https://manpages.debian.org/bullseye/dpkg/dpkg-fsys-usrunmess.8.de.html worked for me. No guarantees from my side. see: https://wiki.debian.org/Teams/Dpkg/MergedUsr Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Ryzen?
Antony Stone - 27.12.21, 18:54:41 CET: > I'm sure I've read somewhere (and not especially recently) that Linux > on AMD Ryzen CPUs can be unreliable and/or surprisingly poor > performance. > > Can anyone comment on current (eg: Beowulf / Chimaera with standard > kernels) operation on such machines? > > If it matters, I'm looking at desktop / tower / server motherboards > and not laptops, and I don't care two hoots about graphics - this > would be for networked machines accessed exclusively remotely. > > Any opinions from personal experience, or pointers to reliable data, > on the topic would be appreciated :) Only experience from laptop. ThinkPad T14 Gen 1 with AMD Ryzen 7 PRO 4750U. Works nicely. I managed to run it below its original specs by compiling a kernel to "powersave" CPU governor as default. But after I corrected that I am very pleased with performance of this 8-core hyper threading CPU. Using "schedutil" governor currently and looking forward to new AMD P-state driver for Zen 2 and Zen 3 CPU. I do not expect the Zen 2 desktop CPU experience to be much different, except for the higher performance of a desktop CPU. Not relevant for server usage: Standby mostly works. Even in Windows mode. Up to kernel 5.15 at least. With 5.16-rc2 I had black screen. Suspend to disk was broken some kernel releases ago. Memory corruption after waking up leading to BTRFS errors. Graphics mostly works with for a laptop GPU impressive enough frame rates at least for not too demanding games. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] installing zoom in Chimaera
Hi. Haines Brown - 04.12.21, 23:08:03 CET: > I downloaded zoom_amd64.deb and placed it in a directory in > /usrlocal/share. In that directory I run: > > # apt install -f ./zoom_amd64.deb > ... > Note, selecting 'zoom' instead of './zoom_amd64.deb' > Some packages could not be installed. This may mean that you have > requested an impossible situation or if you are using the unstable > distribution that some required packages have not yet been created > or been moved out of Incoming. > The following information may help to resolve the situation: > > The following packages have unmet dependencies: >dconf-cli : Depends: libdconf1 (= 0.38.0-2) but 0.40.0-2 is to be > installed E: Unable to correct problems, you have held broken > packages. Actually I install proprietary apps like Zoom as I need them with Flatpak these times. It works perfectly well on Devuan. I use FlatSeal flatpak app to review and possibly restrict access of Zoom and other apps to my home directory. Startup time of Flatpak apps is a bit longer, but… I can shield my data a bit better from access by these apps. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
Steve Litt - 13.11.21, 23:24:51 CET: > By the way, for the person who really wants the usr merge, wouldn't > the conversion from an unmerged system consist of two mass copies and > a few symlinks? No. At least not if you like dpkg to be working fine. As I noted before, see: https://wiki.debian.org/Teams/Dpkg/MergedUsr -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
Didier Kryn - 08.11.21, 13:50:25 CET: > What is called "interpreter" here is the dynamic linker associated to > the shared version of gcc, the Gnu C library. There is practically no > statically linked application in a Debian distribution, except some > part of debootstrap. Well and special packages like bash-static, busybox-static and zsh- static. Nice to have in case you want to do crazy things with your system that might cause interesting breakage like switching a system in place from 32 to 64 bit. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
Harald Arnesen via Dng - 06.11.21, 12:31:16 CET: > william moss via Dng [05/11/2021 22.49]: > > BSD and system V (AT/Bell Labs System Five) switched more than a > > decade ago. > > Certainly not FreeBSD: > > $ uname -or > FreeBSD 13.0-STABLE > > $ ls /bin | wc -l >44 > > $ ls /usr/bin | wc -l > 488 Ah, good that you actually looked :) -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] DMARC/DKIM (was: Re: To cc or not cc.)
Steve Litt - 06.11.21, 03:38:19 CET: > The biggest accomplishment of this DMARC/DKIM thing was to make email > such a mess that it sent even more of the dummy dwobes to Facebook, a > private club having a monopoly over communication. What could POSSIBLY > go wrong? I still did not fully wrap my head around DMARC/DKIM. And I am pretty sure I did not yet get it right. I think I did not even configure DMARC with my mail setup using Postfix, Dovecot and rspamd. I do have some SPF hint… after Google wanted to force me to use that instead of stopping a GMail user from sending mails in my name. But I have relaxed it again already cause it just did not work. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
william moss via Dng - 05.11.21, 22:49:42 CET: > On 11/5/21 4:13 PM, Svante Signell via Dng wrote: > > On Fri, 2021-11-05 at 18:50 +, Alexis PM via Dng wrote: > >> Debian 11 Bullseye is the last Debian release that supports the > >> non- > >> merged-usr layout. It is therefore foreseeable that Devuan 4 > >> Chimaera > >> will also be. > > > > I'm not so sure Devuan has to follow Debian with respect to merged- > > /usr. In my opinion it is more a policy decision to make for the > > project. It is up to discussion though though. > > Comments/arguments/opinions are very welcomed. […] > BSD and system V (AT/Bell Labs System Five) switched more than a > decade ago. Interesting information. I never checked what they do with other Unixes. > The original intent was for a fast disk for root and less expensive > media for all else. > > This was in the days of Lab Version 6 and 7, later system III and BSD > 4.x. A large disk was 100 MB. > > Once large fast disks of 100GB became inexpensive commodities, the > incentive was gone. I know this background. > None the less, from a personal perspective: > I have been using Unix since lab version 6. I have used BSD since > 4.0, Minix, Ultrix, etc. I have no preference and would suggest that > whatever is easiest for the maintainers/developers of Devuan should be > adopted. I do not have a strong preference either. However… if it is for going usrmerge, then for me it is about doing it properly. To me it seems that the arguments of the dpkg maintainer are quite warranted: https://wiki.debian.org/Teams/Dpkg/MergedUsr To me it appears that the current default was quite rushed and adopted without discussing its consequences through to the end: base-installer: Allow installing w/o the broken merged-usr-via-symlinks https://bugs.debian.org/923091 And that is one of the main issues I have with how some Systemd developers and supporters approach adopting their ideas – the idea for merged-/usr for Linux was brought in by Systemd people: They use force, if their arguments do not do the trick. If done right, I could even go along with some of the ideas behind Systemd… but for me Systemd still is much more a social and cultural issue than a technical one. The path of adopting Systemd is accompanied with unparalleled arrogance and ignorance and a lot of power struggles. A pattern I currently see in other parts of society as well. Freedom… especially the right to free speech… is the base for everything else. > When the people fear the government there is > tyranny, when the government fears the people > there is liberty. > John Basil Barnhill Very right and very appropriate to remember this in the current times. (P.S.: I suggest moving off from Google Mail… of course it is entirely your decision, but… Google is… in my opinion is not compatible with above citation. Google extends what they now about us… but does not reveal how they do what they do and what they actually do to a large extent.) Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
Svante Signell via Dng - 05.11.21, 21:13:10 CET: > On Fri, 2021-11-05 at 18:50 +, Alexis PM via Dng wrote: > > Debian 11 Bullseye is the last Debian release that supports the > > non- > > merged-usr layout. It is therefore foreseeable that Devuan 4 > > Chimaera > > will also be. > > I'm not so sure Devuan has to follow Debian with respect to merged- > /usr. In my opinion it is more a policy decision to make for the > project. It is up to discussion though though. > Comments/arguments/opinions are very welcomed. I wonder what Devuan would do, if Debian packages ship all binaries in /usr. It would need quite some patching to undo it. But for all Devuan Beowulf / Chimaera servers it will be no /usr-merge for me. And for my Devuan Ceres laptops it will be like that for as long as possible. I do not find the link at the moment, but I saw a quite good idea for an alternative to the FHS standard. And this was using /command directory for the currently active binaries, symlinked to packages in /package directory where they contain version numbers. And also some provision for documentation. I do not know how libs where handled tough in this scheme. But in the end an alternative would need to provide a real benefit for me, especially if some breakage is to be expected. With merged /usr I get the breakage… but I do not see much of a benefit at least for the way I use Linux. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan with usr merge?
Hi Svante. No need to Cc me. I am subscribed. (I know there are different habits, so just a friendly information.) Svante Signell - 05.11.21, 11:26:52 CET: > On Fri, 2021-11-05 at 10:52 +0100, Martin Steigerwald wrote: > > Debian 11 defaults to usr merge. So the installed system used usr > > merge. > > > > I suppose Devuan is compatible and will remain compatible with that? > > I think it would be necessary as well some users may migrate from > > buster. Or one would have to find a way to undo the merge, but this > > I think is quite error prone. > > Devuan defaults to non-merged-/usr as far as I know. You can always > install with merged-/usr on Devuan too using the expert install > option. (Personally I prefer non-merged-/usr remains to be the > default.) Yeah… I always install Devuan them without merged-/usr. > > I like to avoid breaking the server VM by undoing usr merge, even > > tough I prefer systems without usr merge. It is easy to do with > > systems where I can use a Devuan ISO for installation, but for this > > system I had the Debian Netinstall ISO and it is what it is. > > You can use the dpkg-fsys-usrunmess, with a dpkg release later than or > equal to 1.20.6, see https://wiki.debian.org/Teams/Dpkg/MergedUsr > > "For already installed systems (since dpkg 1.20.6) you can also use > the dpkg-fsys-usrunmess program to revert the breakage from these > systems (but beware that it should not be used in systemd's emergency > mode)." > > (I've used that script on two Debian installations successfully > already.) Splendid. Thanks a lot for this. I hesitated, not wanting to cause any further hassle for the admins of the virtualization infrastructure the server VM runs on, but it indeed worked. It appears that… there is… some… discussion about the merged-/usr approach currently taken in Debian. What a mass. Happy I could undo it, although I am in awe for the developer of dpkg- fsys-usrunmess and it feels like I have used a magic wand of some kind. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Devuan with usr merge?
Hi! I migrated a Debian Buster to Devuan Chimaera by already install runit- init into /target during Debian installation and then switching over sources.list to Chimaera. Debian 11 defaults to usr merge. So the installed system used usr merge. I suppose Devuan is compatible and will remain compatible with that? I think it would be necessary as well some users may migrate from buster. Or one would have to find a way to undo the merge, but this I think is quite error prone. I like to avoid breaking the server VM by undoing usr merge, even tough I prefer systems without usr merge. It is easy to do with systems where I can use a Devuan ISO for installation, but for this system I had the Debian Netinstall ISO and it is what it is. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Awkishness [Was: Re: Steam, Mumble, Valheim, Alsa and shared audio
Dear Erik, dva...@internode.on.net - 24.08.21, 07:25:07 CEST: >I hope that interests someone. It's not often that an > opportunity to espouse the original text Swiss army knife presents > itself. Thanks! Nice one. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] New service manager being developed
Hi! Look at https://skarnet.com/projects/service-manager.html Sounds quite interesting, if you ask me. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Plasma Wayland on Devuan Ceres
Hi! Its running! But with kwin-wayland-backend-drm, not with kwin-wayland-backend-x11 which Apt installs alongside plasma-workspace-wayland by default. See: Bug 439629 - kwin/plasma does not start with wayland x11 backend on Devuan https://bugs.kde.org/439629 I switched two machines, a ThinkPad X1 Gen 2 Tablet and a ThinkPad X260 to Wayland. My main laptop is still on X11. Need to verify whether for example Zoom works with Wayland already¹. Since X Wayland appears to be running alongside of Wayland it may just work. [1] I am aware of privacy issues with Zoom, but I do compromise on that for now. And I see they at least had a good go at improving the situation. I am running Zoom as Flatpak with restricted access to system and occasionally delete all settings in ~/.var/app/us.zoom.Zoom. Also I do not have an account with them. Thanks -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
Olaf Meeuwissen - 05.05.21, 12:04:10 CEST: > No libsystemd0 on my beowulf machine but I did find it on a chimaera > system I installed just a few days ago (using the alpha installer). > > Curiousity peaked, I hunted it down and it turns out that my console > only chimaera system installed it to satisfy Depends: for rsyslog, > lvm2 and liblvm2cmd2.03. The latter two depend on libsystemd0 (>= > 222). > > But wait a sec! I've got lvm2 installed on my beowulf system too and > there's no libsystemd0 to be found there! What gives? > > Turns out that libelogind0 is installed there and that happens to > sport a Provides: libsystemd0 (= 241.4). On chimaera the versioned > dependency equals 246.10 (as of writing). > > So people trying to get rid of the libsystemd0 package might try > > apt install libelogind0 libsystemd0- > > but IIRC (and I'm relying on *very* vague memory here!) not all > desktop environments will work with that. FWIW, my beowulf machine > is running fine with Xfce. Exactly that. I am using elogind with KDE's Plasma. On Devuan Ceres with LVM 2. No libsystemd. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..are we|Devuan safe from this systemd backdoor malware, taking our kernels from Debian?
Hi! goli...@devuan.org - 02.05.21, 22:15:48 CEST: > On 2021-05-02 06:08, terryc wrote: > > Unfortunately there are systemd libraries installed by > > Devuan-beowulf > > desktop installation DVD. > > [snip] > > And they are harmless. > > Why are systemd files present in Devuan? > https://dev1galaxy.org/viewtopic.php?id=1925 No systemd library on my Devuan systems: % dpkg -l | grep systemd [no output] Also none via locate. Using Plasma as desktop together with elogind. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Plasma with Wayland requiring systemd-localed?
Hi!
Anyone ever tried Plasma with Wayland on Devuan?
.local/share/sddm# less wayland-session.log
not a reply org.freedesktop.locale1 QDBusMessage(type=Error,
service="org.freedesktop.DBus", error
name="org.freedesktop.DBus.Error.ServiceUnknown", error message="The
name org.freedesktop.locale1 was not provided by any .service files",
signature="s", contents=("The name org.freedesktop.locale1 was not
provided by any .service files") )
"kwin_wayland_wrapper" ("--xwayland", "/usr/lib/x86_64-linux-gnu/
libexec/startplasma-waylandsession") exited with code 255
Note: I did use Plasma from Debian Experimental tough… In case there is
an Devuan Experimental with the same meaning, I can use that of course.
Using Plasma X11 session for now, which works just fine under Devuan with
Runit as PID 1.
I am willing to report with to upstream. So far, Plasma was always
usable with whatever init system.
Best,
--
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan 3.1 media coverage
Hendrik Boom - 18.02.21, 22:23:54 CET: > On Thu, Feb 18, 2021 at 01:41:52PM +0100, Florian Zieboll via Dng wrote: > > Nice, Devuan made it to the reputable german IT news at heise.de > > (also home of the internet magazine 'telepolis') again: > > > > https://www.heise.de/-5057592 > > Didn't get past the cookie warning. My German wasn't good enough to > figure out the weaselwording. So I couldn't accept without > understanding what I was accepting. uBlock Origin and/or uMatrix is your friend. I do not see those cookie warnings anywhere anymore :) Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Martin Steigerwald - 13.12.20, 16:07:10 CET: > Hendrik Boom - 13.12.20, 15:52:31 CET: > > On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote: > > > I do not care about all the automatic changes by package upgrades. > > > > I care about the automatic changes by package upgrades when they > > conflict with my own. > > Well, dpkg warns me about these. And I forgot: I also see them with bzr / git diff. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Hendrik Boom - 13.12.20, 15:52:31 CET: > On Sun, Dec 13, 2020 at 09:29:26AM +0100, Martin Steigerwald wrote: > > I do not care about all the automatic changes by package upgrades. > > I care about the automatic changes by package upgrades when they > conflict with my own. Well, dpkg warns me about these. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Martin Steigerwald - 13.12.20, 09:29:26 CET: > The history on this laptop dates back till May 2011. And I have older > machines where I used it. It may be that for this laptop I just cloned > the bzr branch of the older laptop, then did a diff to see which > files to adapt and continued with the bzr branch of the older laptop. > I still love to use brz – cause I prefer it usability wise -, but I > probably will switch to git for new machines. On the other hand, it > does not really matter. Lol, now I just read the first changelog entry. And no, I did not copy over the repo, at this time I decided to start from scratch. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Version control /etc (was Re: Ethernet names revisited)
Olaf Meeuwissen via Dng - 13.12.20, 03:48:23 CET: > Hi Hendrik, > > Hendrik Boom writes: > > I wish everything user-configurable under /etc was under revision > > control. then we might even be able to have a vendor branch and a > > local branch. > Have a look at etckeeper. > > I've been using that for several years now on a variety of machines. > The log for the machine I'm writing this on goes back all the way to > its initial install on 2017-01-11 of Devuan's Jessie Official Beta2 > :-) > > You may want to keep your sensitive /etc/ files out of the repository > though, depending on your level of paranoia. I still do not use etckeeper, cause I prefer to just add the files to the repository that I actually change. This way, whenever I like to replicate the config onto another machine or even just look at what I changed, I can just clone the repository and have exactly a tree of those files that I adapted. Of course, Ansible would be also an alternative. I am just not completely sure whether it makes sense with just a few machines. I may start to use it with hosted virtual machines as it eases moving to a different provider if need be. I do not care about all the automatic changes by package upgrades. The history on this laptop dates back till May 2011. And I have older machines where I used it. It may be that for this laptop I just cloned the bzr branch of the older laptop, then did a diff to see which files to adapt and continued with the bzr branch of the older laptop. I still love to use brz – cause I prefer it usability wise -, but I probably will switch to git for new machines. On the other hand, it does not really matter. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Your system is not supported by certbot-auto anymore.
Simon Walter - 08.12.20, 10:16:47 CET: > On 12/8/20 6:02 PM, Martin Steigerwald wrote: > > […] > > > >> Other than a manual install, are there any alternatives? I am > >> interested to hear how others are doing this. > > > > I am still using dehydrated. It is a simple shell script which just > > depends on curl, openssl and ca-certificates. There is an additional > > package for apache2 support, which just contains the site > > configuration for the web challenge thing, and one for DNS > > challenge. > > > > I think there is an alternative to it, called acme.sh. I never > > looked > > into it. > > > > Aside from that there is a huge ton of other ACME clients in various > > programming languages. AFAIR Let's Encrypt web page has a list. > > I found it at: https://letsencrypt.org/docs/client-options/ > > Thank you so much. I actually don't need anything messing with my > Apache configs. I just need automatic renewal. I will study the > various clients on that page. Then just install dehydrated base package. Or use another client of your choice. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Your system is not supported by certbot-auto anymore.
Hi Simon. Simon Walter - 08.12.20, 09:41:15 CET: > It is nice to see that there is instructions for Devuan at > https://certbot.eff.org/lets-encrypt/devuanascii-apache and that they > don't say to use snapd. However, what has certbot become? > > I have yet to look at the source code, but there are a lot of > dependencies: > > The following NEW packages will be installed: >certbot python-certbot-apache python3-acme python3-augeas […] > Other than a manual install, are there any alternatives? I am > interested to hear how others are doing this. I am still using dehydrated. It is a simple shell script which just depends on curl, openssl and ca-certificates. There is an additional package for apache2 support, which just contains the site configuration for the web challenge thing, and one for DNS challenge. I think there is an alternative to it, called acme.sh. I never looked into it. Aside from that there is a huge ton of other ACME clients in various programming languages. AFAIR Let's Encrypt web page has a list. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Ludovic Bellière - 18.11.20, 10:11:12 CET: > I believe you have some misconception on how cut and paste > works on the X Window environment. I believe that a proper > understanding on how you host environment behave would help you figure > out an appropriate workflow. Oh, and thanks for your detailed explanation. It goes deeper than what I read in a long time about it. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Linux's sucky cut and paste: was: problematic mouse driver?
Ludovic Bellière - 18.11.20, 10:11:12 CET: > On Tue, 17 Nov 2020 19:07:06 -0500 > > Steve Litt wrote: > > On Tue, 17 Nov 2020 08:16:11 -0500 > > Hendrik Boom wrote: > > > > Other than deliberate exclusion of Linux users by Microsoft and > > their > > henchmen, the only area I've seen where Windows is better than Linux > > is cut and paste. On Windows, it's Ctrl+C, Ctrl+V, and IIRC that > > works seamlessly on both CLI and GUI. On Linux, it can be Ctrl+C > > and Ctrl+V, or highlight and middle mouse button (be sure to press > > and not turn at all), or menu edit and paste, or who knows what > > else. I hate, hate, HATE it: It deeply cuts into my daily workflow. > > Whenever you select something, the content is then sent to the PRIMARY > selection. As such, selecting text would be the equivalent of MS > Windows's CTRL-C. Content is then accessed using the middle mouse > button. > > Whenever the user specifically request the content to be copied, with > CTRL-C, the content would then be sent to the CLIPBOARD selection. > Accessed then using CTRL-V. > > There can be any number of selections (ie. buffers containing your > data), but we usually needs to take care of only three: PRIMARY, > SECONDARY and CLIPBOARD. Plasma's Klipper has a functionality to unify some of this. It is an option to unify clipboard and actual selection. I bet this may refer to CLIPBOARD and PRIMARY selection. I enabled this option and it works most of the time. It is still not perfect though. I heard that with Wayland there is just one clipboard. I also really like the functionality that Klipper can store the last N selections or clipboard entries and I can still access them. You can also delete all of just one selection, for example if you copied a password. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Free faces?
Hendrik Boom - 06.08.20, 01:08:33 CEST: > On Thu, Aug 06, 2020 at 01:00:02AM +0200, marc...@welz.org.za wrote: > > Recall a while ago some company called clearview.ai made the > > news - given a picture of a person it finds all the other > > photos of that person online, and does a good job of it too. > > Is there any free/libre software that can look at two photos and > provide a reasonable guess as to whether the two are photos of the > same person? Digikam 7.0 has much improved face recognition built in. All locally, not cloud based. I never used it, though. https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Privacy and large public, yet privately owned, service providers (was: Re: Zoom?)
Ozi Traveller - 04.08.20, 06:57:38 CEST: > I've switched to teams. I avoid Teams as much as I can. Unfortunately we have Office 365 at work. I read about all the privacy issues on Zoom, but at least from the reaction of Zoom people I had the impression they are taking them seriously. And they are still smaller than Microsoft. However I do not completely trust them. The CEO publicly stated he did not want to enable end to end encrypted for free users for the service in order to *help* the FBI. The partly reconsidered, but still that kind of attitude is not acceptable for me from a privacy point of view. I also avoid Zoom. There is some chat I still used it for and if that would be end-to-end-encrypted in the future without me having to register an user account with them, it might be okay. However its still proprietary. Unfortunately it appears that Nextcloud Talk which I installed for myself cannot record talks. You can consider this a feature. But with agreement of *all* participants this would be a good thing to have. For me Microsoft with Office 365 is by no means better than Google or Amazon. They are doing the exact same thing if you ask me. And there are several data / privacy protection officials who say it is legally impossible to use Microsoft Teams and Co in Germany. I tried to understand their privacy statement. I failed to even grasp the structure of that document. Their privacy declaration is a complete, utter and incomprehensible mess. I am not sure a mere mortal is supposed to understand this crap. And then Max Schrems and his team at noyb.eu convinced the highest European court to finally kick Privacy Shield. I hope that some day companies stop the insanity to introduce proprietary software they have *no control* over *whatsoever* through the web browser and public cloud service providers, cause it does not even run on *their* computers. This stuff is proprietary software through the backdoor called browser. It completely undermines the free software movement while at least in part *using* free software. It is a trick for companies to regain and even extent their control over users. It violates user freedom at its core. I strongly distrust large public cloud service providers and I think they are in sum detrimental to a free and open society. I just recommend Why Privacy Matters from Gleen Greenwald https://invidious.snopyta.org/watch?v=pcSlowAhvUk (or use a different Invidious instance or Youtube directly as domain) With those cloud providers you can *never* know whether they spy on you or not. It is the perfect panopticon¹. Unless you only store *end-to- end* encrypted data on it, in a way that even metadata is encrypted. And even if I use something on another computer, and I do, I trust small providers like disroot.org or smaller web hosting providers a huge lot more than Google, Microsoft or Amazon Web Services. I'd like to host everything in my home though and in some homes of friends I trust. This whole centralization is a huge, big, fat mistake, if you ask me. It concentrates way too much power in way too few hands. All those companies who give up the control over their own infrastructure will at one point in history receive the real invoice for that. Loss of competence in their own employees, loss of control, increased dependencies and in the end very like also increased cost. They are at the mercy of their giant, yet privately owned, service providers. I do my best to get rid of it. It is not easy though at times to convince friends and relatives to use an alternatives. And very challenging to convince my employer to stop using Office 365. The did not tend to see the issues with it at least not to the point where they would really stop using it. However I installed my own Nextcloud and used it successfully for video chat and more meanwhile. I also attended BigBlueButton conferences and Jitsi meetings. I use XMPP for chat. This is the way to go forward. I am making a little step at a time. A little step into freedom, one after another. And I can only recommend to others to do that as well. [1] https://en.wikipedia.org/wiki/Panopticon Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom?
Hi! No need to CC me. Ozi Traveller - 04.08.20, 06:55:48 CEST: > I have it on an isolated laptop! And I don't care what happens to it! That of course is the best isolation you can get. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom?
Martin Steigerwald - 04.08.20, 06:54:06 CEST: > I also installed Rocket.Chat through Flatpak and there I was able that > I am not able to track files into the chat client from directories *drag* > that are *not* allowed for the app. Its error message was less than > helpful, but the app apparently was not able to open the file. So I > found the permission system basically appears to work. *sigh* Typo not found during initial proofreading. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom?
Martin Steigerwald - 04.08.20, 06:46:11 CEST: > If you use the Debian package, or even with the Flatpak, you can setup > up a different use or use a VM, to contain the application. For now I a different user > rely on what Flatpak can do, but a different user or a VM of course > gives stronger guarantees about security. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom?
Ozi Traveller via Dng - 04.08.20, 06:00:43 CEST: > Yes use the debian deb I have it running on devuan. > > or > > try the web client > > https://support.zoom.us/hc/en-us/articles/214629443-Zoom-web-client I'd avoid using the web client. At least with a browser that is not specifically set up to avoid privacy leaks. I am not sure about the web client specifically, however the main webpage from Zoom at least uses Google Tag Manager and Google Analytics. Both blocked on my web browser. Of course as a user of Googlemail your mileage may vary. With my browser setup I cannot even set it up easily in order to fully display the page as it seems to pull resources from not so obvious or easy to guess sources. I'd be vary of the web client. On the other hand, if you use a secured browser and manage to make the web client work with it, this *may* give you a better isolation than using a Flatpak. If you install Zoom inside a VM just for that purpose or use a different user, you may get the best protection though. I currently rely on the sandboxing in Flatpak, unless I learn that it does not work. I also installed Rocket.Chat through Flatpak and there I was able that I am not able to track files into the chat client from directories that are *not* allowed for the app. Its error message was less than helpful, but the app apparently was not able to open the file. So I found the permission system basically appears to work. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom?
Martin Steigerwald - 04.08.20, 06:34:22 CEST: > Haines Brown - 04.08.20, 01:58:26 CEST: > > I've been relying on zoom on a laptop runnding debian. But there's a > > problem with it and I want to install zoom on beowulf 3. > > > > But there's no zoom in the beowulf repository. Do I have to download > > debian's zoom .deb? > > I used flatpak to install Zoom. By the way I am not recommending to use Flatpak to install just *any* app. I only use it for stuff that I cannot obtain via Devuan or in this case on this laptop Debian package repository. I agree with the assessment at¹ enough to avoid using it to install something that I can easily obtain via the official package repository of the distribution. But compared with using the Debian package from Zoom, it may have the advantages I described. Of course if you monitor the Zoom webpage with the Debian package daily and install a new package immediately you may install security fixes more quickly. There is likely to be *some* delay regarding updated Flatpaks, but as written I receive updates of it regularly. And with installing the deb package from Zoom you need to trust them completely. They could do anything on your computer as maintainer scripts run with root permissions. Also you cannot restrict permissions of the Zoom application like you can with Flatseal this way. So I personally see an security advantage of using Flatpak for third party, closed source apps like Zoom, Skype, Teams. The best approach from a security point of view however is to avoid those apps completely. If you use the Debian package, or even with the Flatpak, you can setup up a different use or use a VM, to contain the application. For now I rely on what Flatpak can do, but a different user or a VM of course gives stronger guarantees about security. [1] https://flatkill.org/ Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Zoom?
Hi.
Haines Brown - 04.08.20, 01:58:26 CEST:
> I've been relying on zoom on a laptop runnding debian. But there's a
> problem with it and I want to install zoom on beowulf 3.
>
> But there's no zoom in the beowulf repository. Do I have to download
> debian's zoom .deb?
I used flatpak to install Zoom.
Still on Debian for this one laptop, but on Debian with runit as PID 1,
and with elogind, so I bet this will work on Devuan as well.
Advantage 1: you can use flatpak permission to restrict what the
application can do cause it runs in a kind of container. There is a
github issue on flatpak, as the default permissions are that is can
access all of $HOME¹. But that is completely unnecessary as pointed out
in the bug report. I used Flatseal, another app I installed with Flatpak
to restrict its permission to "Other files" to:
xdg-documents/Zoom
(that is where is puts whiteboards and so on)
You need to switch off access to home directory in Flatseal for this to
have any effect.
I also told it to make
.zoom
.config
persistent. This is so I do not have to configure it again every time.
However, as I found it stores some ID in an SQLite3 database that may be
used for tracking, I delete that database from time to time.
If you contain Zoom in that way, those configuration files are in
~/.var/app/us.zoom.Zoom
Nothing is stored directly in your home directory anymore, all is in
that directory above.
That code that apparently is used for tracking is in zoomus.db:
% ~/.var/app/us.zoom.Zoom/.zoom/data> sqlite3 zoomus.db
sqlite> .dump
INSERT INTO zoom_kv VALUES('tracking.code.join.meeting','{--
--}','ZoomChat');
I am not sure whether that is used for any purposes that does against
the user though, but nonetheless occasionally I delete the file or just
drop the tracking code in sqlite with something like this
sqlite> DELETE FROM zoom_kv WHERE 'tracking.code.join.meeting' NOT NULL;
I contacted Zoom privacy support, but they did not reveal anything on
the purpose of that tracking code. So far Zoom privacy support has been
not helpful, they claimed I do not have an account with them. Which is
right, however, as I still use it (with others who have accounts), I am
still eligible for GDPR requests like asking whether they do any
tracking or so.
I am pondering to just remove the persistency as I do not use Zoom all
that often and can set it up again quickly each time.
Advantage 2: Easy updates. As far as I am aware Zoom does not provide
any Debian repository, so you'd have to check for updates for yourself.
With flatpak you can just use "flatpak update".
Advantage 3: Installing Flatpak packages works with user rights. They
elevate privileges in the background during installation if you choose
to install the Flatpak systemwide (which seems to be the default).
However it may be that they do not let any maintainer scripts run with
root rights. I am not completely sure of that.
Disadvantage would be that some of the dependencies of Zoom are either
installed with a runtime Flatpak or directly with the Flatpak, like in
the case of Zoom, Qt, instead of Devuan/Debian packages. For security
you need to rely on the maintainers of the Flatpak. And there people
with critique about Flatpak security². I usually receive a Zoom update a
month at least though.
This could also be an advantage in case you like to avoid pulling in
additional dependencies in your main system.
The other option indeed it to use the Debian package you referred to. I
used that as well until I found about the Flatpak stuff.
And of course you could say that this, again, is stuff from Red Hat. I
don't mind as I do not judge the software solely from where it comes
from. While Zoom has far too many permissions by default in Flatpak, if
you install it as deb it can do everything it can do with user
privileges unless there would be some AppArmor profile or so which I
doubt would be in the official Debian package from Zoom. So every
restriction you place upon it by using Flatseal for example is something
you do not even have when installing it as a deb.
Another disadvantage is that you need to have some initial configuration
for the user for the additional comfort to be able to use the 'flatpak'
command directly. I forgot what it was and I do not find it right now,
but it is explained the first time you run the commend.
[1] https://github.com/flathub/us.zoom.Zoom/issues/18
[2] https://flatkill.org/
Best,
--
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Non-systemd Linux for older hardware (was: Devuan Jessie End of Life (EOL) archiving)
Hi! spiralofhope - 01.07.20, 05:53:38 CEST: > On Wed, 1 Jul 2020 16:53:19 +0200 > > "Dr. Nikolaus Klepp" wrote: > > A word of condolence to anybody fixed on old hardware. If you cannot > > upgrade, there is still the BSD-family which offer support down to > > 80486. And they, too, are systemd-free > > It's been a while, but I wonder if Slackware would be the Linux > alternative: > > http://www.slackware.com/ > > There is a non-SMP (single processor) kernel mentioned here: > > http://www.slackware.com/releasenotes/14.2.php I bet one could use "make bindeb-pkg" to just build a kernel package that works on this old hardware and then stuff it into the machine *before* upgrading. Unless it is not just the kernel but also glibc or something somehow not working on older hardware. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] What can even possibly go wrong?
Hi! Just a little rant and feel free to ignore it. systemd-homed… I hope none of it is ever implemented to elogind. https://www.freedesktop.org/software/systemd/man/systemd-homed.service.html https://systemd.io/USER_RECORD/ (just count the lines of that one… its utterly complex stuff) https://www.freedesktop.org/software/systemd/man/homectl.html NIH syndrome & what can even possibly go wrong? I believe it is just a question of time until the first *grave* security issue with that is revealed. And the intended application of it: To use the own home directory on different laptops? Why… at all… would I? Especially when one of those laptops would be a device that I have otherwise no control over? I'd say either I installed the laptop with Linux and thus trust it *or* it does not ever see my $HOME. But right on… extend Systemd until absurdity… maybe more people will see the insanity in it. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fw: looking for a replacement for debian since systemd
Hi Steve. Steve Litt - 14.12.19, 02:55:26 CET: > According to this message on the Debian-User email message, Debian is > working on dumping non-systemd inits. The Debian vote methods are so > arcane I can't tell whether that's true or false, or whether the > quoted vote is early or partial information. The voting period lasts still 27th of December as you can easily see on debian-vote mailing list. Before that there is no final result of that vote. So please go to the source of the information, before posting FUD here. Best, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Identifying a file system
Hendrik Boom - 11.08.19, 14:44:53 CEST: > That may be true. You can also check with “wipefs” tool (don't worry, > > without -a it won't wipe anything): > > > > wipefs --no-act /dev/sda4 > > > > Wipefs has a big database of various filesystem metadata, it detects > > almost anything. > > april:/farhome/hendrik# wipefs --no-act /dev/sda4 > april:/farhome/hendrik# > > Looks empty. > > Thanks. Now I wonder why I ever created that partition. To complete that, what does file -sk /dev/sda4 show? -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What do you think of Wayland?
Martin Steigerwald - 14.07.19, 13:19: > > And here from askubuntu[3]: > > > > Wayland is a lot less complex than X which should make it > > easier to maintain - although some of this simplicity comes > > from pushing the complexity (eg: how to actually draw onto > > that buffer, network transparency) to other layers of the > > stack. By making clients responsible for all of their > > rendering the clients can be smarter about things things > > like double-buffering. > > > > Existing xclients will not work, and although those based > > on GTK+ or Qt *may* be supported in future. > > Both GTK and Qt have Wayland support since some time already. Also there is XWayland for X11 clients that have not yet been ported to Wayland. That is basically X11 on Wayland. It has the same issues as X11 itself, but it allows to run programs that use X11. I bet it would be required for quite some time. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] removed encrypted file system? was date of publication of beowulf
Hendrik Boom - 13.07.19, 01:01: > On Fri, Jul 12, 2019 at 01:33:22PM -0400, Steve Litt wrote: > > On Fri, 12 Jul 2019 12:00:35 -0400 > > > > Hendrik Boom wrote: > > > Debian actually removed one of the encrypted file systems because > > > it turns out to be incompatible with systemd. > > > > Are you absolutely positive this is true? I was unable to find such > > a thing with a 10 minute web search. Could you please tell us the > > name of the encrypted filesystem and a URL describing the removal? > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=765854 > > Debian Bug report logs - #765854 > ecryptfs-utils: Private directory not automatically unmounted anymore > on logout > > It seems there's poor interaction between ecryptfs-utils and user > logout. Specifically, that the encrypted volume remains mounted. > There's a long discussion how to tweak it and systemd to make it work, > and it looks like they eventually just gave up. > > Maybe someone else can understand th problem in more detail than I > can. > > The remocal is mentioned in section 5.1.9. Noteworthy obsolete > packages, > https://www.debian.org/releases/stable/amd64/release-notes/ch-informa > tion.en.html#noteworthy-obsolete-packages Whoa, I am using ecryptfs. I still have ecryptfs-utils, but that is due to using Debian Unstable aka Sid. Not digging deeper into this at the moment, just telling: That with sysvinit the ecryptfs directory gets unmounted *just fine* :) So I believe Beowulf could just ship ecryptfs-utils, no matter whether it is shipped for Debian Buster or not. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What do you think of Wayland?
Joel Roth via Dng - 13.07.19, 01:24: > On Fri, Jul 12, 2019 at 11:36:17PM +0200, Dr. Nikolaus Klepp wrote: > > Anno domini 2019 Fri, 12 Jul 13:53:20 -0400 > > > > Steve Litt scripsit: […] > > Dont know if wayland is compatible to anything not gnome. But I'm > > not verry eger to try. It sure is. Plasma developers are working on Wayland support since almost as long as GNOME developers. There are still things to solve, but they got quite far already. > Why throw-away a protocol stack that solves the problem? Why > not just fix X? Keith Packard and the xorg team did a remarkable job > of modularizing X, why not build on that? Of course anyone has > the freedom to re-architect something, and perhaps > network transparency will be neatly solved. I for one > don't need to be their bug tester. I've scarcely noticed > anything with X to complain about. While it is true that X11 usually just works these days, I do believe it would be challenging to fix some of the most severe issues with it. Most notably: Security of X11 is a complete mess. A complete disaster. Not surprisingly so: Security has not been much of an issue as X11 was invented¹. X11 Clients can do *anything*. They see all of the screen, they can receive all of the keyboard input and… so… on… The network layer is completely unencrypted. SSH X11 forwarding requires a lot of trust between client and server and so on. I believe fixing it would involve inventing a new protocol and re-implement it all from scratch. From what I have read and seen security in X11 is broken beyond repair. [1] Martin Flöser, Why screen lockers on X11 cannot be secure http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/ Some of the issues with SSH X11 forwarding: https://security.stackexchange.com/questions/14815/security-concerns-with-x11-forwarding Or in more depth than I looked into (I did not watch the whole video): X Security, It's worse than it looks, Ilja van Sprundel https://media.ccc.de/v/30C3_-_5499_-_en_-_saal_1_-_201312291830_-_x_security_-_ilja_van_sprundel Just search for "X11 security" to get an idea about the how messed up X11 security is. > Quoting wikipedia again[2] > > Unlike most earlier display protocols, X was > specifically designed to be used over network > connections rather than on an integral or attached > display device. Using X11 over network is what all modern distros disable by default. For a reason. Its as insecure as it can get. > And here from askubuntu[3]: > > Wayland is a lot less complex than X which should make it > easier to maintain - although some of this simplicity comes > from pushing the complexity (eg: how to actually draw onto > that buffer, network transparency) to other layers of the > stack. By making clients responsible for all of their > rendering the clients can be smarter about things things > like double-buffering. > > Existing xclients will not work, and although those based > on GTK+ or Qt *may* be supported in future. Both GTK and Qt have Wayland support since some time already. > To paraphrase in doggerl: > > Wayland's like a step back > counting on a future hack. I do not consider that to be an accurate description of the situation. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What do you think of Wayland?
Hi Steve. Steve Litt - 12.07.19, 19:53: > What do you think of Wayland? I hear Buster now defaults to Wayland. > > I've always been under the impression that Wayland is just another > overly complexified mess from Redhat and Freedesktop.org. I do not share that view. For me rather X11 todays is that overly complexified mess. And it has a huge ton of security issues too. So for example an application can see the whole screen and receive *all* keyboard input. From what I learned it would be trivial under X11 to make a keylogger app with a hidden window. Wayland has a much tighter security. For me it is not black and white. Not everything coming *through* Red Hat and Freedesktop.org is a mess. I did my own tests with Plasma on Wayland every now and then. So far it did basically worked but it was not quite round and polished for me. Plasma developers are still working on it. It is a huge change. I am also reading about Pipewire which may replace Pulseaudio and at least for some uses Jack for multimedia purposes. Coming from Red Hat as well, they like will use Systemd to start it, but who knows, I did not check it so far. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Server updated to Devuan Beowulf
Martin Steigerwald - 08.07.19, 23:00: > After release of Debian 10 aka Buster I just upgraded my new 64-Bit > Devuan server from Ascii to Beowulf. The server provides mail, web and > some other services. > > What can I say? > > It just worked. Additionally for both of my Beowulf servers I now just did apt install libelogind0 and libsystemd0 package was gone. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd depends on random numbers in order to work properly
Tomasz Torcz - 09.07.19, 21:07: > On Tue, Jul 09, 2019 at 02:58:37PM -0400, Hendrik Boom wrote: > > > > What need could there possibly be for randomness at boot time? > > > > What *use* could there even be, never mind need? > > > > > > From what I gathered they need some basic randomness for UUID > > > generation for all units and for some hashmap implementation. But > > > as far as I got, they would not even need random values with > > > cryptographic quality. But when using /dev/urandom they still > > > drain the entropy pool for more important applications of > > > randomness (like generating SSH keys).> > > So why do they need new UUID's at every boot? > > Not every boot. Every service start: > https://github.com/systemd/systemd/commit/4b58153dd22172d817055d2a09a0 > cdf3f4bd9db3 Now *who* does need that? Well… Thank you for digging that out. Seems Systemd developers pile complexity over complexity over complexity just to even add more complexity. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd depends on random numbers in order to work properly
Steve Litt - 09.07.19, 13:07: > On Tue, 09 Jul 2019 10:54:46 +0200 > > Martin Steigerwald wrote: > > Martin Steigerwald - 08.07.19, 17:35: > > > Just another reason I am happy to use sysvinit on my systems. > > > > > > unblock: systemd/241-4 > > > https://bugs.debian.org/929215 > > > > > > Booting system should not depend on random numbers to be available > > > in a large enough quantity. > > > > > > Granted there is a processor bug involved… but why rely on the > > > random number generator of CPUs anyway? > > > > https://www.debian.org/releases/buster/amd64/release-notes/ch-inform > > ation.en.html#entropy-starvation > The preceding article mentions using haveged, which many consider > insecure. So for those times when *I* use systemd, I've created a > superior solution... > > I loosely attach my mouse to my stationary bike in such a way that the > mouse's LED shines on the stationary bike's belt, building up > entropy. Within 10 seconds boot begins! > > I've mentioned many times that although systemd holds out the promise > of fast boot, it takes someone with my skills to bring that fast boot > to fruition. Haha! You mean that, do you? Or was that a joke? -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd depends on random numbers in order to work properly
Hendrik Boom - 09.07.19, 14:26: > On Tue, Jul 09, 2019 at 07:07:20AM -0400, Steve Litt wrote: > > On Tue, 09 Jul 2019 10:54:46 +0200 > > > > Martin Steigerwald wrote: > > > Martin Steigerwald - 08.07.19, 17:35: > > > > Just another reason I am happy to use sysvinit on my systems. > > > > > > > > unblock: systemd/241-4 > > > > https://bugs.debian.org/929215 > > > > > > > > Booting system should not depend on random numbers to be > > > > available > > > > in a large enough quantity. > > > > > > > > Granted there is a processor bug involved… but why rely on the > > > > random number generator of CPUs anyway? > > > > > > https://www.debian.org/releases/buster/amd64/release-notes/ch-info > > > rmation.en.html#entropy-starvation> > > The preceding article mentions using haveged, which many consider > > insecure. So for those times when *I* use systemd, I've created a > > superior solution... > > > > I loosely attach my mouse to my stationary bike in such a way that > > the mouse's LED shines on the stationary bike's belt, building up > > entropy. Within 10 seconds boot begins! > > > > I've mentioned many times that although systemd holds out the > > promise > > of fast boot, it takes someone with my skills to bring that fast > > boot > > to fruition. > > What need could there possibly be for randomness at boot time? > What *use* could there even be, never mind need? From what I gathered they need some basic randomness for UUID generation for all units and for some hashmap implementation. But as far as I got, they would not even need random values with cryptographic quality. But when using /dev/urandom they still drain the entropy pool for more important applications of randomness (like generating SSH keys). -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd depends on random numbers in order to work properly
fsmithred via Dng - 09.07.19, 12:49: > On 7/9/19 5:07 AM, Martin Steigerwald wrote: > > Martin Steigerwald - 09.07.19, 10:54: > >> Just *booting* the system should not depend on enough entropy being > >> available. Starting services that need entropy may be delayed, but > >> just booting should not depend on entropy being available. > > > > This is enlightening: > > > > Openssh taking minutes to become available, booting takes half an > > hour ... because your server waits for a few bytes of randomness > > > > https://daniel-lange.com/archives/152-hello-buster.html > > > > According Daniel Systemd developers are basically getting it wrong > > to > > the maximum extent possible. > > Live-isos with openssh-server hang on boot while waiting for enough > entropy to make new host keys. I get this with sysvinit (in Devuan). I > made a live-config script to start haveged before openssh-server > starts to fix it. I may run into this once I upgrade my cloud-init VM images for the Linux trainings I hold. So yes, it is not just something with Systemd, but still I believe Systemd has no business to drain the entropy pool that early during boot time. Especially given the challenge of having enough entropy during boot anyway. I am not sure whether Devuan Beowulf will have any sort of release notes, but if, it may be helpful to mention that. Otherwise we can also point to Debian release notes and say that for services, and just for services, what is written there still applies. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd depends on random numbers in order to work properly
Martin Steigerwald - 09.07.19, 11:07: > Martin Steigerwald - 09.07.19, 10:54: > > Martin Steigerwald - 08.07.19, 17:35: > > > Just another reason I am happy to use sysvinit on my systems. > > > > > > unblock: systemd/241-4 > > > https://bugs.debian.org/929215 > > > > > > Booting system should not depend on random numbers to be available > > > in > > > a large enough quantity. > > > > > > Granted there is a processor bug involved… but why rely on the > > > random > > > number generator of CPUs anyway? > > > > https://www.debian.org/releases/buster/amd64/release-notes/ch-inform > > at ion.en.html#entropy-starvation > > > > is just so seriously broken I do not have any words for it. > > > > Just *booting* the system should not depend on enough entropy being > > available. Starting services that need entropy may be delayed, but > > just booting should not depend on entropy being available. > > This is enlightening: > > Openssh taking minutes to become available, booting takes half an hour > ... because your server waits for a few bytes of randomness > > https://daniel-lange.com/archives/152-hello-buster.html > > According Daniel Systemd developers are basically getting it wrong to > the maximum extent possible. I probably better stop here, but Debian kernel developers activated trusting RDRAND CPU randomness despite the warning of Theodore T'so, the maintainer of the entropy gatherer in Linux. In above blog post: "Update: Since Linux kernel build 4.19.20-1 CONFIG_RANDOM_TRUST_CPU has been enabled by default in Debian." This means the default kernel may have become less secure, but it can be disabled without recompiling the kernel. From linux-image-4.19.0-5-amd64 changelog: linux (4.19.20-1) unstable; urgency=medium […] * random: Enable RANDOM_TRUST_CPU. This can be reverted using the kernel parameter: random.trust_cpu=off […] Actually doing just that now for my Devuan based servers. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd depends on random numbers in order to work properly
Martin Steigerwald - 09.07.19, 10:54: > Martin Steigerwald - 08.07.19, 17:35: > > Just another reason I am happy to use sysvinit on my systems. > > > > unblock: systemd/241-4 > > https://bugs.debian.org/929215 > > > > Booting system should not depend on random numbers to be available > > in > > a large enough quantity. > > > > Granted there is a processor bug involved… but why rely on the > > random > > number generator of CPUs anyway? > > https://www.debian.org/releases/buster/amd64/release-notes/ch-informat > ion.en.html#entropy-starvation > > is just so seriously broken I do not have any words for it. > > Just *booting* the system should not depend on enough entropy being > available. Starting services that need entropy may be delayed, but > just booting should not depend on entropy being available. This is enlightening: Openssh taking minutes to become available, booting takes half an hour ... because your server waits for a few bytes of randomness https://daniel-lange.com/archives/152-hello-buster.html According Daniel Systemd developers are basically getting it wrong to the maximum extent possible. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd depends on random numbers in order to work properly
Martin Steigerwald - 08.07.19, 17:35: > Just another reason I am happy to use sysvinit on my systems. > > unblock: systemd/241-4 > https://bugs.debian.org/929215 > > Booting system should not depend on random numbers to be available in > a large enough quantity. > > Granted there is a processor bug involved… but why rely on the random > number generator of CPUs anyway? https://www.debian.org/releases/buster/amd64/release-notes/ch-information.en.html#entropy-starvation is just so seriously broken I do not have any words for it. Just *booting* the system should not depend on enough entropy being available. Starting services that need entropy may be delayed, but just booting should not depend on entropy being available. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Server updated to Devuan Beowulf
goli...@devuan.org - 08.07.19, 23:11: > On 2019-07-08 16:00, Martin Steigerwald wrote: > > After release of Debian 10 aka Buster I just upgraded my new 64-Bit > > Devuan server from Ascii to Beowulf. The server provides mail, web > > and some other services. > > > > What can I say? > > > > It just worked. > > > > Only thing was that for Quassel IRC I had to use "aa-disable > > quassel- > > core" to disable AppArmor. Otherwise it would not be allowed to > > access TLS certificate and config file¹. I believe it may make > > sense to forward > > this issue to the Debian bug tracker, as I do not think Devuan plays > > a huge role here. Of course it could be something about using the > > init script instead of systemd service to start up Quassel IRC > > Core. > > > > [1] quassel-core: no permission to open certificate file, cannot > > write quasselcore configuration > > https://bugs.devuan.org//cgi/bugreport.cgi?bug=340 > It looks like Devuan is not at all involved so the conversation should > probably be with Debian: > > https://pkginfo.devuan.org/cgi-bin/d1pkgweb-query?search=quassel-core; > release=any > > https://git.devuan.org/devuan-packages?utf8=%E2%9C%93=quassel-c > ore Thanks. I bet I report with Debian as well then. I just used reportbug on the server VM and that reported to bugs.devuan.org. Only thing may be that init script does something different than Systemd service and that would trigger the issue. But since quassel-core in Debian provides the init script I can still file a bug with Debian. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Server updated to Devuan Beowulf
Hi. After release of Debian 10 aka Buster I just upgraded my new 64-Bit Devuan server from Ascii to Beowulf. The server provides mail, web and some other services. What can I say? It just worked. Only thing was that for Quassel IRC I had to use "aa-disable quassel- core" to disable AppArmor. Otherwise it would not be allowed to access TLS certificate and config file¹. I believe it may make sense to forward this issue to the Debian bug tracker, as I do not think Devuan plays a huge role here. Of course it could be something about using the init script instead of systemd service to start up Quassel IRC Core. [1] quassel-core: no permission to open certificate file, cannot write quasselcore configuration https://bugs.devuan.org//cgi/bugreport.cgi?bug=340 Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
Hendrik Boom - 08.07.19, 16:56: > On Mon, Jul 08, 2019 at 10:54:58AM +0200, Martin Steigerwald wrote: > > Steve Litt - 07.07.19, 01:26: > > > On Sat, 06 Jul 2019 08:49:52 +0200 > > > > > > Martin Steigerwald wrote: > > > > So I believe it is good to let go of any drama and fear and just > > > > get > > > > on with actually doing something to improve runit / s6 support. > > > > > > Well, if I were to help integrate runit and s6 into Devuan either > > > directly or through Debian, would it really matter if my incentive > > > included drama and fear? > > > > For me it does. > > > > The fear may tell me that it is keeping me safe. My own direct > > experience through letting go tells something different however: > > Fear > > keeps me stuck. With fear I give my power away to what I imagine > > would be stronger than me. Like in your case, I dramatize a bit: > > "big large evil commercial corporations". > > > > What if I just let go of the fear instead? Or welcome it and then > > move on which is basically the same. It is just a feeling. It is > > not the truth. > > This sounds like Franl Herbert's Bene Gesserit litany against fear: > > Fear is the mind-killer . I do not know this one. Was it too much of a lecture for you? Well then please just disregard it. It is not my job to educate others without them asking for it. It appears I am still learning this. We are all in this human experience together. In the past I have also not been exempt from feeling fear and I may feel fear again. I am determined to welcome it and let it go whenever it arises. So Steve and everyone else, feel free to do or not do anything with what I wrote. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Systemd depends on random numbers in order to work properly
Hi! Just another reason I am happy to use sysvinit on my systems. unblock: systemd/241-4 https://bugs.debian.org/929215 Booting system should not depend on random numbers to be available in a large enough quantity. Granted there is a processor bug involved… but why rely on the random number generator of CPUs anyway? Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
viverna - 06.07.19, 15:58: > il devuanizzato Steve Litt il 06-07-19 07:24:37 ha scritto: > >> Instead it's possible > >> inject in all daemon's install a piece of posix shell? > >> Workaround script on event "DPkg::Post-Invoke" as I said in the > >> previous email? > > > >You know much more than I do about packaging. Given something like > >event "DPkg::Post-Invoke", all it would need to do is call a > >shellscript, with the argument of the daemon name, and the > >shellscript could make the necessary symlinks or whatever. All the > >heavy lifting would still be done in the runit-runscripts package. > > Put my code here. > > Work for epoch init system but it is adaptable to any other such as > runit, s6 and so on... Thanks a lot for your code contribution I was not even aware of epoch init system. https://universe2.us/epoch.html https://universe2.us/epochconfig.html Hmmm… -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] ..so Debian is Busting postgresql, evolution-ews inboxes and history itself?, was: Runit service depend another script not daemon
Arnt Karlsen - 07.07.19, 16:29: > ..another motive in town?: > 5.3.7. evolution-ews has been dropped, AND EMAIL INBOXES USING > EXCHANGE, OFFICE365 OR OUTLOOK SERVER WILL BE REMOVED: > https://www.debian.org/releases/buster/amd64/release-notes/ch-informat > ion.en.html#evolution-and-exchange > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=926712#19 The alternative would be to include an evolution-ews plugin that does not check for any TLS errors nor verifies certificates. I certainly can understand the decision to remove the package from testing. Its also mentioned in the release notes: https://www.debian.org/releases/buster/amd64/release-notes/ch-information.de.html#evolution-and-exchange Maybe it would have been good to delay the release… but on the other hand: I would not recommend to anyone using Office 365. Unfortunately at work I am not given a choice. Also it could probably be added back later at least as backport. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
Steve Litt - 07.07.19, 01:26: > On Sat, 06 Jul 2019 08:49:52 +0200 > > Martin Steigerwald wrote: > > Steve Litt - 06.07.19, 07:24: […] > > There is the debian-init-diversity group where Debian and Devuan > > people work together. Back then I helped to bring that forward and > > there is still a lot of activity. > > Thank you for that. Regardless of the final outcome, you did something > important in undoing the savage mistakes of late 2014. A lot of > people talk: You did something, and the something you did might > benefit all of us. Thanks. […] > [snip sysvinit, insserv and startpar bug fixes] > > My feeling that sysvinit is not in safe hands in the Debian project > isn't based on the quality of sysvinit or its components. As a matter > of fact, I never noticed any bugs or weird stuff with sysvinit during > the 13 years I used sysvinit as my daily driver init (with occasional > forays into upstart and daemontools). My feeling is based on: > > 1) Corporate profit motive for keeping systemd the only init in town. > > 2) The (insert your own noun epithet) of "FreeDesktop.Org". > > 3) Systemd's technological ability to sabotage all attempts at >alt-initting a computer. > > 4) The huge moving-target workload necessary because of #3. > > 5) See the response to your next statement... For me this is just a feeling. Not facts. While I certainly can relate to the fear, I also know that up to now Debian is still a 100% community project. Does it mean that it absolutely cannot by manipulated by commercial actors? No. But I'd rather not anticipate something happening by putting a lot of energy, for example in the form of fear, into it. If I do not like it to happen, then I am sure I am better off not to give energy to it. And if it still happens I can act then. None of what you stated above is here right now. Fact is, that Debian can be run just fine – again! – without Systemd in most of the circumstances. > > While Debian project for now will keep the libsystemd0 dependency on > > a lot of packages > > Which makes libsystemd0 the ideal kill switch for init diversity. One > might ask who would be so mean as to kill init diversity within > Debian? For a list of such people, see the original decision: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708 Nope, I won't. Reason is as simple as stated above: I'd give energy into something I do not choose as a possible future. Thus I'd rather use my time to help to bring forward the future I like to see to the best of my ability. […] > > So: If you like to provide runit support for fio Debian package, > > please go ahead. As long as the runit support is implemented in a > > way > > that the existing start support for sysvinit – which I implemented > > back then – and systemd still works as well, and you tested the > > runit > > support, I gladly accept a merge request. I'd even make some effort > > to put it into the package itself, in case you provide something to > > me, in case you are not familiar with forking a git repo and > > providing a merge request. > > I can't think of anything I or anyone could do, regarding runit > runscripts, that would adversely affect sysvinit. As far as systemd, > runit and s6 are never going to use the systemd mechanism by which > service A tells systemd that it's loaded, but if someone switched back > to systemd, that mechanism will still be there. Why? Currently my package supports both systems with sysvinit as well as systemd. There are different debhelper commands for that. I'd imagine that would work with runit as well. > > So I believe it is good to let go of any drama and fear and just get > > on with actually doing something to improve runit / s6 support. > > Well, if I were to help integrate runit and s6 into Devuan either > directly or through Debian, would it really matter if my incentive > included drama and fear? For me it does. The fear may tell me that it is keeping me safe. My own direct experience through letting go tells something different however: Fear keeps me stuck. With fear I give my power away to what I imagine would be stronger than me. Like in your case, I dramatize a bit: "big large evil commercial corporations". What if I just let go of the fear instead? Or welcome it and then move on which is basically the same. It is just a feeling. It is not the truth. However now I let go of wanting to control your experience. You may invent as much drama and fear as you'd like. I just won't take part in that. I bet I may just have replied cause all the near conspiracy-theory drama and fear stuff here and else sometimes just gets on my nerves. But can I let this go as well? Can I let go of wanting to give my power away as to whether apparent other(s) play the game of drama and fear or not? Yes. Thank you, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Installing sysv-init under Debian Buster
Joel Roth via Dng - 07.07.19, 23:39: > Noting here a solution from the debian-user mailing list. > > I'm aware there's a team working for init system flexibility > on Debian and send my kudos and beer vouchers to them :-) > > https://lists.debian.org/debian-user/2019/06/msg00961.html > > > quoted message follow > > > On Jun 27, 2019, at 12:42 AM, Rick Thomas wrote: > >> On Jun 25, 2019, at 11:20 PM, Jonas Smedegaard > >> wrote: > >> > >> Seems this would work as well, with less collateral damage: > >> > >> apt install -y sysvinit-core elogind > >> apt --purge autoremove > > > > This works great and, as noted, is far more elegant. […] > A warning about all of these solutions: They will remove the package, > network-manager. Sometimes this may rewrite the Not here. I am still running Debian with elogind and Plasma and Network Manager just fine. As I did not bother yet to switch to Devuan, but in order to replace systemd-udevd by eudev I likely will at some point in time. I do not remember whether I did it exactly like above, but I am sure that in general Network Manager can be run without Systemd just fine. Anyway, I posted it all here and/or on devuan-dev and its still available in the archives. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Runit service depend another script not daemon
Steve Litt - 06.07.19, 07:24: > > It is not > > difficult to think of the day when Debian will remove completely > > sysvinit script in all packages. > > Pre-Cisely! I would not bet on that. There is the debian-init-diversity group where Debian and Devuan people work together. Back then I helped to bring that forward and there is still a lot of activity. Developers in that group did updates for sysvinit, insserv, startpar, openrc, runit and others for Debian which then could be and have been used in Devuan. At the same time there is a new upstream maintainer for sysvinit, insserv and startpar so these are all actively developed. These developers closed a ton of sysvinit related bug reports in Debian. It's amazing. In fact the upstream developer even dug through Debian bug tracker to find bugs to fix. Just look at this: https://bugs.debian.org/sysvinit-core I believe sysvinit has never ever been in a better state in Debian than it is now. Granted insserv still has more – but it already received a lot of bug fixes as well: https://bugs.debian.org/insserv Look at this in comparison: https://bugs.debian.org/systemd Especially the ton of *forwarded* bugs! That are those for upstream to handle. While Debian project for now will keep the libsystemd0 dependency on a lot of packages that not absolutely need it and regarding init diversity there is a place for Devuan to go further, there are Debian developers who strongly prefer to use sysvinit and who prefer to avoid Systemd. Actually I have been pleasantly surprised. I just migrated also the mail server and Quassel IRC to my new 64-Bit Devuan server from my old 32-Bit Debian with sysvinit server, in addition to migrating the web server and MariaDB before. And actually everything had init scripts. Postfix, Dovecot, rspamd, Quassel core, Apache, PHP FPM, sshguard, MariaDB, you name… everything worked out of the box. So far the only things that does not work on Debian without Systemd out of the box are desktop related things: - Pulseaudio does not start, at least with Plasma - Evolution background services do not start, at least with Plasma That kind of inspired the user-services project I did not work on after that again. I more and more believe it would be good to package that stuff in a way that it would work out of the box for users. Or… well to do some post package processing to make it work. Of course it is likely at some time some may bring up that topic and there would be a discussion, but… assuming from the past, that discussion would take a time to come to an conclusion. So I believe the risk that all Debian developers would *suddenly* drop init scripts from packages is quite low. There would be at least a considerable forewarning time. That said, I agree it would be good to find a way to inject runit symlinks into packages, cause I believe it to be unlikely that many Debian package maintainers would include runit support. However that said, I would. So: If you like to provide runit support for fio Debian package, please go ahead. As long as the runit support is implemented in a way that the existing start support for sysvinit – which I implemented back then – and systemd still works as well, and you tested the runit support, I gladly accept a merge request. I'd even make some effort to put it into the package itself, in case you provide something to me, in case you are not familiar with forking a git repo and providing a merge request. But also it would be good to have something like this to fix up Pulseaudio and Evolution for Devuan users. So I believe it is good to let go of any drama and fear and just get on with actually doing something to improve runit / s6 support. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] backups from ext4 to ntfs - extended attributes and access control lists
Rick Moen - 29.05.19, 04:14: > Quoting Bruce Ferrell (bferr...@baywinds.org): > > I am absolutely astounded by the number of time I've seen *IX > > "admins" at fortune X companies copy a tree to a windows share and > > wonder why it's broken when they try to restore from it. NFS, if not > > done correctly, can do that same thing too. So... > > Reminds me of something I forgot to mention earlier. Most Linux folks > have heard of the stat(2) system call, but did you know there's also > an informative stat(1) system _utility_? Play with it on diverse > sorts of file/directory targets, and see how informative it is. It > shows in human-readable form _all_ metadata available about any > filesystem object. At the moment not in all cases all the metadata. Recent kernels have an extended statx() syscall that AFAIK is not yet fully supported in user space tools. It will support things like a creation time or the maximum filename length or file size of a filesystem while unlike stat() also being extendable. Once fully supported desktop environments or cp/rsync and so on could bail out on copying a file larger than 4 GiB to a FAT32 partition instead of copying 4 GiB and then stopping due to an error. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Java 8 on beowulf
Hi Steve. Steve - 31.05.19, 02:47: > A couple of weeks ago I upgraded to Beowulf and I see that it comes > with openjdk 11. I have an app that needs java 8 so I was planning to > have both installed, maybe use the script described here: > > https://www.linuxuprising.com/2019/02/install-any-oracle-java-jdk-vers > ion-in.html > > Any issues I need to be aware of? (Beside the obvious Don't use the > same installation dir!) Are you aware of the package 'java-package'? For a 3rd party software that required Oracle SDK with Swing it generated a debian package for me. Basically back then it turned jdk-8u191-linux-x64.tar.gz into oracle-java8-jdk_8u191_amd64.deb I do not remember how exactly I called it, but it was easy enough. You still would need to update the package manually, so I only use it for that special program and use update-alternatives to switch to the lastest openjdk in Debian otherwise. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] cloud-init with Devuan
Hi! I created a Devuan image for my Linux trainings. On Devuan Ascii with ancient cloud-init '0.7.9-2' I have an issue with initial network configuration after cloning VMs. I use Proxmox VE. On the first boot cloud-init is supposed to configure the network. However it does so *after* '/etc/init.d/networking' initialized the network already and thus I see the old IP address of the template on 'eth0'. Now changing '/etc/init.d/networking' to require 'cloud-init' would introduce a loop as cloud-init can require networking to be present in case the configuration source comes from the network (here it is a cloud- init cidata iso provived by Proxmox VE). I bet eventually this is just a bug in cloud-init. Or well I'd need the clean up the template. I believe the '/e/n/i' network configuration output of 'cloud-init' should nuke the file in '/e/n/interfaces.d' before '/etc/init.d/networking' is run. I would not report an issue before switching to next Devuan release tough, as the 'cloud-init' version is just very old. As a work-around I have /etc/init.d/networking stop ip addr flush eth0 /etc/init.d/networking start in '/etc/rc.local'. This is not optimal cause on initial boot there is a chance of duplicate IP address. The template with the original IP address is stopped before the cloning process. But depending on the speed of the hypervisor, it may be that two cloned VMs boot at almost the same time. As this conflict should be short and only on initial boot I bet I can live with that. Of course I could introduce a delay in my cloning script, but that is adding work-around upon work-around. Any other ideas for a work-around that does not have a chance to create a short time period with duplicate IP addresses? I am not yet sure why this works okayish with Systemd cause cloud-init service in run after 'After=networking.service' as well. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Linux system can be brought down by sending SIGILL to Systemd
Hi! Today in a Linux training a participant attempted to bring down Debian workstation with Systemd by sending signals to PID 1 as I invited them to try to bring down PID 1 while thinking for myself that this would not be possible from my past experiences about trying to bring down PID 1 – init – myself. While sending SIGKILL to Systemd did not have any effect, sending SIGILL – illegal instruction – to it brought the machine to an halt. I reproduced it with while true; do kill -ILL 1 ; echo -n "." ; sleep 0.5 ; done on my training workstation (Debian 9.9 with Systemd 232 and 4.9.0-9 Debian Kernel with MDS mitigation). The mouse pointer froze and the machine did not even respond to ping anymore! According to participants about 4 to 5 times sending the signal would be enough to bring down a workstation with Systemd as PID 1. Despite all the bugs and issues I have seen or read about with Systemd I was very surprised about that result. Curiously I attempted the same with the Debian on my laptop that I switched to SysVInit and elogind. As the elogind stuff mostly works I think I will switch it to Devuan once I come around to it. I am able to run while true; do kill -ILL 1 ; echo -n "." ; done against SysVinit's "init" process without any issue for minutes (Debian Sid with sysvinit 2.93-8 and self-compiled 5.1.2 kernel, also with MDS mitigation). It is even running while I write this mail normally now. Also the participants found in the manpage kill(2): NOTES The only signals that can be sent to process ID 1, the init process, are those for which init has explicitly installed sig‐ nal handlers. This is done to assure the system is not brought down accidentally. So if that is actually true, then it appears that Systemd initiates a signal handler for SIGILL for whatever reason. I pondered about writing a bug report to Systemd developers, but honestly from my past experiences with upstream feedback about bug reports regarding Systemd I then decided not to bother about it. I am not willing to take in and deal with any more "this is by design, go away" or "this works as intended, go away" kind of responses. I am not interested in Systemd to a larger extent than teaching participants of my training what they need to know about it, when they have to deal with it due to distribution choices made at their employer. And yes, I also have a slide that summarizes critique about it, complete with links, so they can make up their own opinion. And no, for me it is not black and white, but my own decision is to go without Systemd. This is another reason for me to start to provide Devuan VMs in the Proxmox VE environment I use to provide VMs of various distributions to the participants of my trainings. So participants can have a look at it and do exercises with it if they like. I already started to incorporate information about Devuan in some of my slides. I share it here not to invite another bashing about Systemd, we really do not need to go there, but instead can focus on strengthening the alternatives. But I share it here to provide another reason to use a Systemd-free distribution like Devuan. I also share it as an example of the robustness of the SysVInit init process! Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [RFC] User services
Didier Kryn - 13.05.19, 11:49: > Le 13/05/2019 à 10:47, Martin Steigerwald a écrit : > > s@po, tux...@sapo.pt - 11.05.19, 18:22: > >> Hello All, > >> > >> On Sat, 11 May 2019 11:26:12 +0200 > >> > >> Martin Steigerwald wrote: > >>> Hi. > >>> > >>> Now that the proof of concept is out, I am thinking about > >>> extending > >>> it a little bit. > > > > […] > > > >>> What do you think about that? > > > > […] > > > >> In the past Debian Wheezy had a tool for that, called 'chkconfig', > >> it > >> was a lot used in the Datacenter.. > >> > >> # Adding a Service 'atsd': > >>chkconfig --add atsd; > >> > >> # Enable the service in several Runlevels: > >>chkconfig --level 12345 atss on; > > > > AFAIK that is a tool coming from RHEL/CentOS/Fedora that was dropped > > from Debian for some reason. It only works with system-wide services > > as far as I am aware of. > > > >> And other funcionalities, like listing the services and so on.. > >> It was a very helpfull tool. > >> > >> In the absence of it( I don't know why it was removed .. ), your > >> tool > >> seems to come to replace it, BUT for users only? :) > > > > I do not know why it was removed. > > > > And yes, my approach is just for user services. I already thought > > about making it a generic frontend for runit/s6, in order to also > > allow it to handle system services, in order to allow > > starting/stopping teamviewer services. But on one hand we have the > > init system with its tools for that already and on the other how to > > handle permissions would be something to be really clear about. > > > > Also I'd rather get rid of teamviewer than to provide support for > > it. I use it very rarely for support cases from customer of my > > employee.> > >> I think it would be nice to call it like 'uservice', instead of > >> 'u[ser]service[s]', which is a lot bigger name, or a alias called > >> 'uservice', since 'service' is also another tool, to deal with.. > >> services. > > > > I bet I'd make that a symlink or so, so the tool could work as > > either > > 'uservice' or 'userservice'. 'uservice' also has 'user' and > > 'service' in it. I also thought about just 'us' but Z-Shell would > > like to correct that to 'su' and… those really short command names > > are better reserved for commands that the likely user calls often, > > such as 'cp', 'mv' and so on. > > > > Ciao, > > Why not call it Userd ? It can compare with Systemd. It's made > for the user, and user-friendly, and it does one thing, the thing it > claims to do. Nice idea. But it is no daemon. It uses a (kind of) daemon, runit as in 'runsvdir' or in the future probably alternatively s6, but itself it is none. It is just a script + alias (for now) that makes using runit for user services easy for users. But yeah, I think I like to keep it in a way that it does one thing well, flexibly and efficiently. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [RFC] User services
s@po, tux...@sapo.pt - 11.05.19, 18:22: > Hello All, > > On Sat, 11 May 2019 11:26:12 +0200 > > Martin Steigerwald wrote: > > Hi. > > > > Now that the proof of concept is out, I am thinking about extending > > it a little bit. […] > > What do you think about that? […] > In the past Debian Wheezy had a tool for that, called 'chkconfig', it > was a lot used in the Datacenter.. > # Adding a Service 'atsd': > chkconfig --add atsd; > # Enable the service in several Runlevels: > chkconfig --level 12345 atss on; AFAIK that is a tool coming from RHEL/CentOS/Fedora that was dropped from Debian for some reason. It only works with system-wide services as far as I am aware of. > And other funcionalities, like listing the services and so on.. > It was a very helpfull tool. > > In the absence of it( I don't know why it was removed .. ), your tool > seems to come to replace it, BUT for users only? :) I do not know why it was removed. And yes, my approach is just for user services. I already thought about making it a generic frontend for runit/s6, in order to also allow it to handle system services, in order to allow starting/stopping teamviewer services. But on one hand we have the init system with its tools for that already and on the other how to handle permissions would be something to be really clear about. Also I'd rather get rid of teamviewer than to provide support for it. I use it very rarely for support cases from customer of my employee. > I think it would be nice to call it like 'uservice', instead of > 'u[ser]service[s]', which is a lot bigger name, or a alias called > 'uservice', since 'service' is also another tool, to deal with.. > services. I bet I'd make that a symlink or so, so the tool could work as either 'uservice' or 'userservice'. 'uservice' also has 'user' and 'service' in it. I also thought about just 'us' but Z-Shell would like to correct that to 'su' and… those really short command names are better reserved for commands that the likely user calls often, such as 'cp', 'mv' and so on. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] User services (UPDATE 2)
Martin Steigerwald - 11.05.19, 11:00: > Martin Steigerwald - 10.05.19, 21:12: > > Do you remember the days where people believed in rough consensus > > and > > running code? :) It was before my time here on Earth, but whatever… > > > > tada… welcome to user services: > > > > https://git.devuan.org/WIP-init/user-services/blob/master/README.md > > So I updated it already: > - Changed service directory default to ~/.service (instead of > ~/.services) to more closely match system-wide /etc/service > - Made location of directory configurable (in install-or-update.sh) > - Logging now works > > So please just do > > mv ~/.services ~/.service > > in case you used it before. > > Make sure you have 8400c3c55fa7cffacbb4be1a43b0962696029dcc or a later > commit. > > And yeah, at some time there will be a changelog. As of fa0f445120adf9e2b25c2c91cdf201b514a16bc2 location of user service directory is now officially configurable, but beware of this note in README.md: "If you like to use another directory then run it as: SERVICEDIR='DIRECTORY' ./install-or-update.sh *NOTE*: For compatibility with future versions, please make sure to set that environment variable in your shell profile in case you like to use a different directory." Thanks, Martin > > % userservice list > > evolution-addressbook-factory > > evolution-calendar-factory > > evolution-source-registry > > evolution-user-prompter > > pulseaudio > > redshift > > > > % userservice enable evolution-user-prompter > > > > % ps aux | grep "[e]volution" > > martin 10495 0.0 0.0 2156 744 ?S21:01 0:00 > > runsv evolution-user-prompter martin 10497 4.4 0.3 443308 53076 > > ?> > > Sl 21:01 0:00 /usr/lib/evolution/evolution-user-prompter > > > > % userservice enabled > > evolution-user-prompter > > pulseaudio > > redshift > > > > % userservice disable evolution-user-prompter > > % ps aux | grep "[e]volution" > > > > % userservice enabled > > pulseaudio > > redshift > > > > > > And now feel free already to contribute your own services. :) > > > > I welcome merge requests. > > > > > > There are quite some ideas on how to improve this initial proof of > > concept: - Make it work out of the box with .xprofile (or how that > > is > > called). /me looking to Evilham now :) > > - Make it work with other desktop environments out of the box > > - Make it handle groups of services in a clean and simple way > > - Make it work with s6 alternatively (may just need replacing > > runsvdir) - And of course add more services, … > > - including any of those relevant in /usr/lib/systemd/user/ > > - Putting it into a package. I am willing to package it at a later > > point in time. > > > > > > When discussing this, please make sure doing so constructively. > > > > > > Thanks a lot to Evilham for coming up with the idea to use runit for > > user services and for providing the initial service directories for > > the four services to make Evolution work. > > > > > > Now let's make more out of this by the power of together… > > > > and of course enjoy using it. > > > > Thanks. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [RFC] User services
Martin Steigerwald - 11.05.19, 11:26: > Hi. > > Now that the proof of concept is out, I am thinking about extending it > a little bit. > > - make is a package > - make "install-or-update.sh" into "/usr/bin/userservices" with the > following actions: > - install: Sets up userservices for the user > - update: Updates it > - remove: Removes i - remove: Removes user services from user directory completely (after confirmation) Okay, while discussing this with Evilham, I agree that there likely is no need to differentiate between "install" and "update". I bet that is why I started with "install-or-update.sh" to begin with. Keep it stateless, keep it simple. As only > - make "userservice" alias into "/usr/bin/userservice" > - that way the user would not have to setup an alias anymore. will adapt the symlinks that are in ~/$SERVICEDIR/enabled (SERVICEDIR=".service" by default) and that on user request only. If one really likes to overwrite own changes to "run" files, there can be an "--overwrite" option. > So with these changes using user services would be like: > > As root: > > apt install user-services > > As user: > > userservices install > > userservice enable redshift > > [x] done :) > > > If user-services packaged gets updated, the user can decide to update > her installation with: > > userservices update > > Ideally it would take into account when the user changed some > services. > > > What do you think about that? > > It would be some work, but I for me this sounds like a good idea. > > > In anyway: This is still in proof of concept stage, so I may change > everything :). If you are using this, you are brave alpha tester :) Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] User services
Didier Kryn - 11.05.19, 11:22: > Le 11/05/2019 à 09:54, Steve Litt a écrit : > > On Fri, 10 May 2019 21:12:15 +0200 > > > > Martin Steigerwald wrote: > >> Hi! > >> > >> Do you remember the days where people believed in rough consensus > >> and > >> running code? :) It was before my time here on Earth, but whatever… > >> > >> tada… welcome to user services: > >> > >> https://git.devuan.org/WIP-init/user-services/blob/master/README.md > > > > Nice! > > > > This is a great new way for me to run the home-grown daemons I want > > to run as slitt instead of root. > > > > A question: What runs user-services.sh? Should it be called from > > ~/.bashrc, or from somewhere else? > > In Xfce, like probably in most DEs, you can declare the > applications you want to start when session starts. > > According to Martin's mail, I guess KDE stores that in > ~/.config/plasma-workspace/env > > In xfce4, this seems to be done by adding the launcher file in > ~/.config/autostart . Hmmm, maybe that would work with Plasma, too. A universally working location would be best. But that would need to be a *.desktop file then, wouldn't it? Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] [RFC] User services
Hi. Now that the proof of concept is out, I am thinking about extending it a little bit. - make is a package - make "install-or-update.sh" into "/usr/bin/userservices" with the following actions: - install: Sets up userservices for the user - update: Updates it - remove: Removes i - make "userservice" alias into "/usr/bin/userservice" - that way the user would not have to setup an alias anymore. So with these changes using user services would be like: As root: apt install user-services As user: userservices install userservice enable redshift [x] done :) If user-services packaged gets updated, the user can decide to update her installation with: userservices update Ideally it would take into account when the user changed some services. What do you think about that? It would be some work, but I for me this sounds like a good idea. In anyway: This is still in proof of concept stage, so I may change everything :). If you are using this, you are brave alpha tester :) Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] User services (UPDATE 1)
Martin Steigerwald - 10.05.19, 21:12: > Do you remember the days where people believed in rough consensus and > running code? :) It was before my time here on Earth, but whatever… > > tada… welcome to user services: > > https://git.devuan.org/WIP-init/user-services/blob/master/README.md So I updated it already: - Changed service directory default to ~/.service (instead of ~/.services) to more closely match system-wide /etc/service - Made location of directory configurable (in install-or-update.sh) - Logging now works So please just do mv ~/.services ~/.service in case you used it before. Make sure you have 8400c3c55fa7cffacbb4be1a43b0962696029dcc or a later commit. And yeah, at some time there will be a changelog. > % userservice list > evolution-addressbook-factory > evolution-calendar-factory > evolution-source-registry > evolution-user-prompter > pulseaudio > redshift > > % userservice enable evolution-user-prompter > > % ps aux | grep "[e]volution" > martin 10495 0.0 0.0 2156 744 ?S21:01 0:00 runsv > evolution-user-prompter martin 10497 4.4 0.3 443308 53076 ? > Sl 21:01 0:00 /usr/lib/evolution/evolution-user-prompter > > % userservice enabled > evolution-user-prompter > pulseaudio > redshift > > % userservice disable evolution-user-prompter > % ps aux | grep "[e]volution" > > % userservice enabled > pulseaudio > redshift > > > And now feel free already to contribute your own services. :) > > I welcome merge requests. > > > There are quite some ideas on how to improve this initial proof of > concept: - Make it work out of the box with .xprofile (or how that is > called). /me looking to Evilham now :) > - Make it work with other desktop environments out of the box > - Make it handle groups of services in a clean and simple way > - Make it work with s6 alternatively (may just need replacing > runsvdir) - And of course add more services, … > - including any of those relevant in /usr/lib/systemd/user/ > - Putting it into a package. I am willing to package it at a later > point in time. > > > When discussing this, please make sure doing so constructively. > > > Thanks a lot to Evilham for coming up with the idea to use runit for > user services and for providing the initial service directories for > the four services to make Evolution work. > > > Now let's make more out of this by the power of together… > > and of course enjoy using it. > > Thanks. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] User services
Steve Litt - 11.05.19, 09:54: > On Fri, 10 May 2019 21:12:15 +0200 > > Martin Steigerwald wrote: > > Hi! > > > > Do you remember the days where people believed in rough consensus > > and > > running code? :) It was before my time here on Earth, but whatever… > > > > tada… welcome to user services: > > > > https://git.devuan.org/WIP-init/user-services/blob/master/README.md > > Nice! > > This is a great new way for me to run the home-grown daemons I want to > run as slitt instead of root. > > A question: What runs user-services.sh? Should it be called from > ~/.bashrc, or from somewhere else? Well, this is a good question. If KDE Plasma is detected, the install-or-update.sh script, stuffes it into ~/.config/plasma-workspace/env so it gets started with the session. You can either put it into .xprofile or how that is called (Evilham uses that) or in your shell profile file. It depends a bit on whether you like your services be started only for graphical sessions or also for SSH / TTY sessions. I may explore how to integrate it with PAM at a later time. I happily welcome merge requests which extend the install-or-update.sh script to integrate with xprofile or you name it. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] User services
Martin Steigerwald - 10.05.19, 21:12: > Thanks a lot to Evilham for coming up with the idea to use runit for > user services and for providing the initial service directories for > the four services to make Evolution work. Thanks a lot of course also to Gerrit Pape for that piece of art and simplicity called 'runit'. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] User services
Hi! Do you remember the days where people believed in rough consensus and running code? :) It was before my time here on Earth, but whatever… tada… welcome to user services: https://git.devuan.org/WIP-init/user-services/blob/master/README.md % userservice list evolution-addressbook-factory evolution-calendar-factory evolution-source-registry evolution-user-prompter pulseaudio redshift % userservice enable evolution-user-prompter % ps aux | grep "[e]volution" martin 10495 0.0 0.0 2156 744 ?S21:01 0:00 runsv evolution-user-prompter martin 10497 4.4 0.3 443308 53076 ?Sl 21:01 0:00 /usr/lib/evolution/evolution-user-prompter % userservice enabled evolution-user-prompter pulseaudio redshift % userservice disable evolution-user-prompter % ps aux | grep "[e]volution" % userservice enabled pulseaudio redshift And now feel free already to contribute your own services. :) I welcome merge requests. There are quite some ideas on how to improve this initial proof of concept: - Make it work out of the box with .xprofile (or how that is called). /me looking to Evilham now :) - Make it work with other desktop environments out of the box - Make it handle groups of services in a clean and simple way - Make it work with s6 alternatively (may just need replacing runsvdir) - And of course add more services, … - including any of those relevant in /usr/lib/systemd/user/ - Putting it into a package. I am willing to package it at a later point in time. When discussing this, please make sure doing so constructively. Thanks a lot to Evilham for coming up with the idea to use runit for user services and for providing the initial service directories for the four services to make Evolution work. Now let's make more out of this by the power of together… and of course enjoy using it. Thanks. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What you saw on devuan.org yesterday was an April's fools joke
Jaromil - 02.04.19, 20:10: > he is now in moderation. if the trolling comes back from other > accounts please don't feed. And I already thought I just overreacted. I suggest to just let the whole topic rest for a while. If there is anything remaining, I bet its much more easy to clear up with a few nights in between. Only thing I might do is to add a note to https://www.devuan.org/pwned.html that is was an April fools joke. Just in case someone hits the page via a search engine. https://search.disroot.org luckily does not seem to catch it via a simple search for "Devuan", at least not within the first few dozens of search results. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What you saw on devuan.org yesterday was an April's fools joke
Mike Bird - 02.04.19, 18:46: > On Tue April 2 2019 07:30:58 Jaromil wrote: > > 1. There was no break-in on any part of Devuan's infrastructure on > > 1st> > >April. This was the most skillfull prank I've witnessed in my > >life. > > You are easily impressed. And you double down on KatolaZ's > irresponsible vandalism with a display of lazy wishful thinking. > You are claiming no break-in but you have reported nothing to > establish the integrity of your systems and software from > the ground up as any real Veteran Unix Admin knows how to do. Mike, please, pretty please: Drop it. You made your point pretty clear by now. To all moderators of the mailing list: I am fully okay with enabling moderation for Mike, at least for the while it needs to calm down a bit. This just crosses a line. I do not think that the Devuan project needs to take this kind of abuse. Thanks, -- Martin signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What you saw on devuan.org yesterday was an April's fools joke
Dear Jaromil. Jaromil - 02.04.19, 16:30: > dear readers, > > as a Devuan caretaker and co-founder, in my own personal capacity, let > me state that: > > 1. There was no break-in on any part of Devuan's infrastructure on 1st > April. This was the most skillfull prank I've witnessed in my life. Thank you. For me it was not needed anymore, but I bet it is important for others to regain trust. > 2. Devuan comes WITHOUT ANY WARRANTY. Bluntly put, if you want to hold […] Fully seconded. > 3. At Dyne.org - a public ICT research institution working with the Just so others do not need to search what ICT stands for: Information and Communication Technology. >European Commission and some major municipalities - we use Devuan >in production. Clearly we need the reliability: so we work for >it. We are not only developing Devuan, but also we have an in-house > continuous-integration infrastructure to build packages and new > images for Devuan's many targets. I encourage everyone reading to > consider contributing to Devuan and at the same time plan your own > way of making a community project reliable for your own >professional use. > > 4. Katolaz is not just one of the caretakers of Devuan, but is by far >the developer making the most significant contributions to this >project. If it wasn't for him, we would be stuck at Jessie, >IMHO. For our community project, he has done: > - about 75 Devuan packages > - all the Devuan installers since Jessie RC > - all the minimal-live images since Jessie Beta2 > - development on the Devuan SDK > - work on the sysvinit package in Debian > - maintainance of all our critical infrastructure, including > all the building hosts, jenkins, dak, amprolla, pkgmaster, > mirrors, BTS, file server, all the ganeti nodes, DNS, web, > and what not. Thank you for filling that in. I knew he did a lot, but I did not think it was this much! Thank you KatolaZ for all you did and I add on top of it: For just being here. Thank you Jaromil and all other contributers as well! I appreciate your work. Best. -- Martin signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Update on the Green Hat Hackers attack
Adrian Zaugg - 01.04.19, 22:10: > I'd definitively preferred: > > Devuan embraces Systemd! > After thorough discussions in our technical committee Devuan decided > to ship systemd with its next release "Beowulf" as the standard init. > Systemd is a complete pot of terware that will enhance Devuan to an > industry approved, enterprise grade blackbox system, that demands > highest trust in its developers. Ubiquitous access for any user, no > more security concerns combined with highest computing power needs > for any system will be the remarkable achievement of this wise > decision. Init freedom salutes you, veterans. +1 :) Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Mike Bird - 02.04.19, 00:03: > On Mon April 1 2019 14:39:28 Martin Steigerwald wrote: > > In what way is that not good enough for you? What would be required > > for you to forgive a mistake and go on with your life? […] > What part of Evilham's statement that "it still looks as if gdo and > the build system were compromised" [1] did you not believe? > > Do you think Evilham was mistaken? Why? > > Do you think it possible an attacker - KatolaZ or another - was > in there and later covered his tracks? Why not? > > I am still hoping the silent core team members are working on this > as I really don't want to spend the next few months changing distros. Sorry… at this point I just highly recommend to you: Breathe in deeply, breathe out deeply. And give the other core members a moment to give you the reassurance you need. Evilham already did so. Unsigned for now, but still. And after that recommendation I just do the same as Evilham: Go to sleep. Honestly: For me there is a fine line between valid security concerns and paranoia and for me you just crossed this line. Give it a rest just for the moment and give the team some time to react to your concerns. If you need: Hold back updates for a little longer. That update of tzdata I just installed some time ago did not contain any security fixes, so there is not really an immediate urgency here. Martin -- Martin signature.asc Description: This is a digitally signed message part. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Dear Mike. Mike Bird - 01.04.19, 22:52: > On Mon April 1 2019 13:25:15 Martin Steigerwald wrote: > > 1) please give any requests for removing one of the core members > > from the project or using legal enforcement a rest. KatolaZ > > apologized already several times. So please let it go. > > I have not threatened "legal enforcement" against Devuan. However > those of us who use Devuan in production cannot continue to do so > if Devuan does not take this issue seriously, least we suffer legal > consequences ourselves. 1) KatolaZ publicly apologized. 2) He wrote that he will make sure not to make such a mistake again. 3) He wrote that no one unauthorized had access to the infrastructure. 4) Devuan is a community project. If you use Devuan in production you very likely do it without any support contract with the Devuan team whatsoever. Of course that is no license for Devuan people to do bad "jokes" like this, but it does also limit what you are entitled to request from Devuan people. 5) Apt also has some safe guards. In what way is that not good enough for you? What would be required for you to forgive a mistake and go on with your life? For me there is a point to just let it go… and for me this point is reached here. If you like a confirmation that it was just a joke by other core Devuan core people, I am quite sure that this could be arranged. Maybe other Devuan core people could reply to "devuan.org is back" thread, again signed via GPG, confirming that it was "just" a joke. For me the signed mail by KatolaZ is enough. I had contact with KatolaZ already, for example when helping to kickstart cooperation between Devuan and Debian (debian-init-diversity). I trust him and I see no gain whatsoever in removing one of the core Devuan people and contributors from the team for a single mistake like this. I trust that he did not intend to cause any harm with that "joke". So, please, is there anything else than removing a member or taking legal action against one that could be enough for you to regain trust in Devuan again? I can perfectly understand when other Devuan core people decide not to follow your request for such drastic measures. And I'd actually support them regarding such a decision. Remember, if you do not regain trust, you can always also use a different distribution. While I actually indeed postponed an update of one of my Devuan servers, I trust KatolaZ and just ran the update a few minutes ago. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Rowland Penny via Dng - 01.04.19, 22:37: > The stunt pulled here could have caused alarm and distress and should > never have happened. I do not know if this was a one person stunt or > not, but in my opinion, the guy who pulled it should offer a > grovelling apology and promise to never do anything as stupid again. That guy, KatolaZ, did both of that. Just see "[DNG] devuan.org is back" thread initial mail by him. So please… yes, it was not such a hot idea, and yes, KatolaZ realized that… He apologized and he wrote he will make sure not to make such a mistake again. For me that is good enough. I really highly recommend – to everyone, including myself – to let it go now. Forgiving is something that really makes my life a lot easier. It is in the past already and there is no use in trying to change the past. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Martin Steigerwald - 01.04.19, 22:25: > 1) please give any requests for removing one of the core members from > the project or using legal enforcement a rest. KatolaZ apologized > already several times. So please let it go. > > 2) KatolaZ, could you repost your clarifying statement in thread > "devuan.org is back" signed with your gpg key. I bet it may have some > signatures from other devuan core members. Mike, is there anything > else you need to accept this statement as genuine? KatolaZ's mail had signatures to begin with. I just did not see any indication of it in K9 Mail. Thanks, Martin > Am 1. April 2019 22:12:45 MESZ schrieb Mike Bird : > >On Mon April 1 2019 12:44:05 Antony Stone wrote: > >> No, I have complied with my country's laws regarding personal data > >> protection and taken "appropriate technical and organisational > > > >measures" to > > > >> ensure the security of the systems. > > > >You do not seem to understand security. Once there is the > >possibility of an attack the security of the system has to be proven > >or rebuilt. Usually this entails locking out the attacker, > >generating all new security tokens and keys, wiping, and rebuilding > >from trusted source. > > > >An email claiming it was all a joke does nothing to prove the system > >secure even if it happens to be true. It could equally well be > >false. Similarly Evilham's suggestion of a future offline > >"discussion" is too little too late. > > > >Maybe the prankster/attacker left another easter egg or a backdoor. > >Maybe he stole keys. Maybe a black hat snuck in while the prankster > >was messing around. Maybe nothing at all bad happened. > > > >You can't entrust other people's credit cards to "maybe". > > > >And certainly the prankster cannot henceforth be trusted with > >privileged access to any systems. > > > >But don't believe me. Talk to your lawyers. > > > >I was just hoping the surviving Devuan four would take responsibility > >for fixing things before I have to invest a few months in moving > >a lot of systems to a different distro. But as time passes with no > >action it's looking increasingly as if they have no interest in > >keeping Devuan viable. > > > >--Mike > >___ > >Dng mailing list > >Dng@lists.dyne.org > >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] [kato...@freaknet.org: devuan.org is back]
KatolaZ - 01.04.19, 22:46: > Martin, All, > > all my messages have always been signed, so I don't understand what > you are referring to. This message is signed as well, with my key, > which is the same I used to sign all the Devuan install images since > Jessie RC2 in April 2017, and minimal live since Jessie Beta 2 in > November 2016. You can find it in any keyserver. The fingerprint has > been included in my email signature since I can remember. Please refer > to the archives of the mailing list or to any personal email you have > received from me in the past. Sorry, I see that now. K9 Mail did not display even a slight indication that there is a signature in your mails and before Mike's comment I did not consciously check or recognize that your mails have signatures so… KMail does, the signature is valid, it has signatures from some people including a signature of someone I trust… that is good enough for me. It might be good to do a key signing party at the conference. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Fwd: April's fools mess
Hi. 1) please give any requests for removing one of the core members from the project or using legal enforcement a rest. KatolaZ apologized already several times. So please let it go. 2) KatolaZ, could you repost your clarifying statement in thread "devuan.org is back" signed with your gpg key. I bet it may have some signatures from other devuan core members. Mike, is there anything else you need to accept this statement as genuine? Thanks, Martin Am 1. April 2019 22:12:45 MESZ schrieb Mike Bird : >On Mon April 1 2019 12:44:05 Antony Stone wrote: >> No, I have complied with my country's laws regarding personal data >> protection and taken "appropriate technical and organisational >measures" to >> ensure the security of the systems. > >You do not seem to understand security. Once there is the possibility >of an attack the security of the system has to be proven or rebuilt. >Usually this entails locking out the attacker, generating all new >security tokens and keys, wiping, and rebuilding from trusted source. > >An email claiming it was all a joke does nothing to prove the system >secure even if it happens to be true. It could equally well be false. >Similarly Evilham's suggestion of a future offline "discussion" is >too little too late. > >Maybe the prankster/attacker left another easter egg or a backdoor. >Maybe he stole keys. Maybe a black hat snuck in while the prankster >was messing around. Maybe nothing at all bad happened. > >You can't entrust other people's credit cards to "maybe". > >And certainly the prankster cannot henceforth be trusted with >privileged access to any systems. > >But don't believe me. Talk to your lawyers. > >I was just hoping the surviving Devuan four would take responsibility >for fixing things before I have to invest a few months in moving >a lot of systems to a different distro. But as time passes with no >action it's looking increasingly as if they have no interest in >keeping Devuan viable. > >--Mike >___ >Dng mailing list >Dng@lists.dyne.org >https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng -- Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] devuan.org is back
Hi KatolaZ. KatolaZ - 01.04.19, 15:27: > Again and to clarify once and for all: this was just an April fool. No > machine was compromised. No content was moved, deleted, or tampered > with in any way. Noone got access to the Devuan infra. No package or > mirror was affected. Thanks for clarifying. > I apologise if somebody thought the joke stretched a bit too far: I am > responsible for that. I thought all the clues were clear enough, but > apparently they were not and some people got too stressed about it. I > am sincerely sorry about that. Apology accepted. Regarding my own take: I just did not take the time to verify any of the clues. Part of it was, that in my local time it also was not 1st April and I forgot that there are quite a bunch of other timezones. Only later I installed a gopher client. Thing is: Devuan is used in production, so there is some responsibility coming with that. :) > Pranks have always been an essential part of the hacker culture, and > like it or not, Devuan has been brought to all of us by a bunch of > passionate hackers working long nights, not by a team of serious white > collars in suit and scarf doing 9-to-5. I certainly understand and can relate to that. While Microsoft's marketing directory tried to ban April fools jokes this year, I am always on the lookout for some. For me the joke was just a bit too… security sensitive. > I will definitely make sure I will not make such a mistake again in > the future. All is well. > P.S.: Please, do not let the world outside take away from you the > pleasure of having a good laugh, at any cost. Stopping to laugh is the > first step to the grave. Well, I even have a smile on my face at the moment. As for implementation of the "joke": You basically fooled me initially. Well done. Or as gamers say: Achievement completed. Thanks -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *** DEVUAN.ORG HAS BEEN PWNED *** , message -- UPDATE
mett - 01.04.19, 05:38: > On 2019年4月1日 11:03:36 JST, Hendrik Boom wrote: > >On Mon, Apr 01, 2019 at 01:35:30AM +0200, KatolaZ wrote: > >> On Mon, Apr 01, 2019 at 12:21:58AM +0200, KatolaZ wrote: > >> > >> [cut] > >> > >> > Just to let you know that Devuan's caretakers got anonymous > >> > emails > >> > from a group who identified themselves as "Green Hat Hackers". > >> > They > >> > insisted on the last line of the pwned website. If you have any > > > >clue, > > > >> > let us know. > >> > >> ok we probably got that! > >> > >> $ date -d @7779847 > >> $ date -d @1554080659 > > > >Or > > > >date -u -d @7779847 > >date -u -d @1554080659 […] > +1 for the -u IMO this is still a *very bad* taste for an April fools joke. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] logging uses of machine-id
Didier Kryn - 12.03.19, 09:48: > Le 11/03/2019 à 19:33, KatolaZ a écrit : > > guys, anything using dbus will most probably (indirectly) access > > /var/lib/dbus/machine-id at some point in time, since that file is > > read when attempting to send a message via dbus. > > It's most certainly as simple as that. > > The question is why the hell do a web browser need to attach to > Dbus? This question is pure rant because I won't be satisfied by any > answer. For me it would be more important to see what DBUS, aka libdbus, is actually doing with the machine id. Thus I second the recommendation of KatolaZ to look at its source code. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] new freedesktop "standard": /etc/machine-id
Jaromil - 10.03.19, 14:03: > > > but first things first: do we want /etc/machine-id? and how? > > > > In my view it falls in the completely unnessesary or the potentially > > dangerous group. > > > > I don't want it. > > while I'm still catching up with reading all the thread, I think you > make a concise and straight to the point argument with which I > wholeheartedly agree. Thanks, to you and all others providing insights > on this issue. > > I also don't want it and I think having such a machine-id is not just > a technical, but also a political decision, as you pointed out. > > for the record, my /etc/machine-id follows: > > "d34dc0d3d34dc0d3d34dc0d3d34dc0d3" I felt uneasy about the machine-id several times as well. It remembers me of the IMEI of mobile devices. After browsing through thread and internet references I am still not clear what it is used for. Every privacy policy in EU needs to state that purpose, especially for uniquely identifying data. It never came to my conclusion that I can just change the id. Now did. Probably would be good for a lot of people setting it to the same value :). As when everyone comes up with an own machine id chances are that it is still unique. Another way would be to randomize it on every boot or every few hours. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Devuan server outage -- Please read
Hi KatolaZ. KatolaZ - 10.03.19, 10:14: > we have experienced an outage to part of the Devuan infrastructure. As > a result, the following services are not currently reachable: > > - www.devuan.org > - packages.devuan.org > - *.mirror.devuan.org > - ci.devuan.org > > We are working to resolve the issue. In the meanwhile, please use > 'deb.devuan.org' as a package mirror in your sources.list. The rest of > the infrastructure (ML, forum, repos, files, git, BTS, popcon, etc.) > is up and running. We will keep you posted with updates. Best of luck and success with getting things working again. Ciao, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Systemd as tragedy
Simon Hobson - 31.01.19, 14:07: > Massimo Coppola wrote: […] > It's clear that systemd isn't the right implementation. And it's clear > that Poettering isn't the right person to be doing it. But I'd > suggest that many of us "systemd - just say no" folks aren't > fundamentally opposed to improvements where the improvement is > actually better and not a bug ridden furball' Agreed. For me right now runit is closest to what I think would be good to have. Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] slashes in FAT file names
Hendrik Boom - 23.12.18, 04:15:
> On Sun, Dec 23, 2018 at 02:35:35AM +0100, Gonzalo Pérez de Olaguer
Córdoba wrote:
> > Hi Hendrik,
> >
> > El Sat, 22 Dec 2018 18:20:22 -0500
> >
> > Hendrik Boom escribió:
> > > > > > Rename them.
> > > > > >
> > > > > > 1. 'ls -i' #Gets the inode number.
> > > > > > 2. 'find . -inum "inode-number-from-ls -i" -exec mv {}
> > > > > > "newfilename" \;'> >
> > > Yes, I see inode numbers. Unfortunately, the files with slashes
> > > in
> > > their names have question marks for their inode numbers.
> > >
> > > 2522 @ 2523 ? 2526 ?? 07/TRA~1.MP3
> > > 2516
> >
> > You don't have to use inodes at all. Anything provided by find to
> > match the file will do. For example, try something like:
> >
> > find . -type f -iname '07*TRA*MP3' -exec ...
>
> I'm starting to think the way to go about this is to use a utility
> that bypasses the kernel's VFAT file system and treats /dev/sdb1 as a
> block device. A few have been suggested. Maybe a hex editor. Maybe
> fsck.vfat. Maybe mtools, possibly modified since the documentation
> https://www.gnu.org/software/mtools/manual/mtools.html#default-values
> says:
Well mtools act directly on an FAT filesystem and do not use the vfat/
msdos filesystem drivers in Linux. It has the "mren" command to rename
files.
However I still assume that this FAT filesystem is just corrupted and
that maybe not even mtools is able to do the rename.
What I'd do is:
First copy the whole block device with the filesystem block by block into
a file. Then make a copy of that file. Only work from the copy of the file.
Then you can throw 'mren', 'fsck.vfat' / 'fsck.msdos', use a hex editor,
or well just 'photorec' on it. And due to working with a copy of the
copy you have unlimited attempts.
Thanks,
--
Martin
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] slashes in FAT file names
Hello Hendrik, Hendrik Boom - 22.12.18, 04:23: > ls -l lists them like this: > > -rw-r--r-- 1 hendrik hendrik 0 Sep 1 2007 06 - Track 6.mq3 > -? ? ? ? ?? 07/TRA~1.MP3 instead of useful metadata can be a sign of filesystem corruption. There might be something in kernel log about that. I'd try fsck.vfat and if that does not work use photorec from the testdisk package to recover the image. Best of success, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] randomness
Hi! This appears to be another reason for sysvinit or any other init system that actually uses the seed file to let the kernel start with enough entropy: Daniel Lange: Openssh taking minutes to become available, booting takes half an hour ... because your server waits for a few bytes of randomness https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html I do understand the concern when booting from hundreds identical images, but when creating images, you'd better delete OpenSSH host keys, seed file and so on. I consider getting a chaoskey. :) Thanks, -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] mailing list software
Jim Jackson - 12.12.18, 15:33: > On Wed, 12 Dec 2018, Rick Moen wrote: > > Quoting Lars Nood??n via Dng (dng@lists.dyne.org): > > > It's probably a time that Procmail be retired, and thus anything > > > based on it. There have been a lot of reports in recent years of > > > serious, unsafe bugs in its processing. However, there is this > > > comment about it from a former Procmail maintainer to consider: > > > > > > https://marc.info/?l=openbsd-ports=141634350915839=2 > > > > Upon examination, it turns out that the known flaws in Procmail lack > > any credible exploitation scenario. The matter was covered on > > LWN.net a few years ago, and I'm pretty sure nothing has changed > > substantively. > > > > (I've gone through this discussion several times since then on > > mailing lists, and can dredge up details from those if necessary.) > > Just an aside - what are the alternatives to procmail? > so far I've only found _maildrop_ as an in-line delivery filter. Postfix has built-in minimal lda, but I use "dovecot-lda" as "mailbox_command" in Postfix. I set it up for Sieve support which IMHO is a nice way to speficy rules for IMAP based mail accounts. I still receive a copy of mail via POP3 and let KMail sort it locally. All mail it duplicated to IMAP account and "find -delete" removes older mail. This IMAP account is for accessing via K9-Mail on smartphone. -- Martin ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
