Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
Le 02/03/2021 à 12:48, Steve Litt a écrit : > Hi all, > > As you know, I was asking many Qemu LAN-peer questions on this list a > week ago. My documentation on the subject has finally achieved > first-draft status. If you'd like to see it, go to: > > http://troubleshooters.com/linux/qemu/nobs.htm > Thanks Steve for this document. I have a question though and a remark that tomething is missing in your block diagram. From the response to the command "[slitt@mydesk qemu]$ ip -4 addr", it is visible that enp40s0, the physical Ethernet adapter has no address. This means that the host's network configuration must be modified to operate through br0 instead of enp40s0. I mean /both/ guest and host use the bridge. Do I understand correctly? -- Didier ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] My Qemu LAN-peer documentation is now in its first draft
>Le 02/03/2021 à 12:48, Steve Litt a écrit : >> Hi all, >> >> As you know, I was asking many Qemu LAN-peer questions on this list a >> week ago. My documentation on the subject has finally achieved >> first-draft status. If you'd like to see it, go to: >> >> http://troubleshooters.com/linux/qemu/nobs.htm >> > Thanks Steve for this document. I have a question though and a >remark that tomething is missing in your block diagram. From the >response to the command "[slitt@mydesk qemu]$ ip -4 addr", it is >visible that enp40s0, the physical Ethernet adapter has no address. >This means that the host's network configuration must be modified to >operate through br0 instead of enp40s0. I mean /both/ guest and host >use the bridge. Do I understand correctly? > >-- Didier Hi Didier, The vast majority of documents I've read tell me that once you make the bridge, the hardware NIC must be robbed of its IP addresses. So that's what I did. By the time I finally got a LAN-peer setup working, after about a year on and off of trying, and 2.5 weeks of full-on work to create the LAN-peer configuration, I was so happy just to have something work that I didn't go back and do the obvious experiment of adding the addresses to enp40s0 and seeing what difference that makes. My itch was scratched :-) Right now my long term TODO list includes writing two books and creating a playlist creation system, so it will be several months before I have time to run the experiment. If you remind me in September, I just might run the experiment then. Thanks, SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
>Quoting Steve Litt (sl...@troubleshooters.com): > >> My philosophy: One big hammer prevents a 100 step packaging system >> raindance. > >The Big Hammer always seems a great idea for a temporary solution. >And I assume you know what the catch is with those. > >Every single time I've nailed down a sysadmin annoyance using the Big >Hammer, it's come back to haunt me later -- and, moreover, it turned >out that a further ten minutes of digging would have found a better >solution that didn't cripple the system's administrative framework but >would, instead, have worked with the framework. > >Setting /etc/resolv.conf immutable, the classic case that was the first >I saw you fall in love with, is a case in point. There are multiple >ways to ensure that a DHCP client respects and enforces your preference >of recursive nameserver, averting the need for breaking system >administration tools using the immutable bit. Did everyone read what Rick said? He restated, for a specific situation, the carved in granite troubleshooting rule that you never coathanger the symptom, but instead fix the cause. I teach this in every Troubleshooting course I teach. It's the stone truth. Rick speaks of the immutability of /etc/resolv.conf breaking admin tools. This is a specific instance of the more general principle that when you coathanger a symptom instead of eliminating the root cause, you create side-effects which are typically harmful. I've known audio techs who *solved* the problem of intermittent blown fuses by wrapping aluminum foil around the blown fuse and re-installing it. And of course, the next time the customer's speaker wires shorted at high volume, instead of blowing the fuse, all the output transistors and drivers would short, possibly along with the transformer and bridge rectifier (this was in the early 80's, remember), with the very real possibility of your beloved amplifier bursting into flames (I've seen this happen on another audio technician's service benche). So why do I violate the principle of eliminating the root cause instead of coathangering the symptom, in this particular case, when I tell my students never to coathanger the symptom? Troubleshooting, as defined on Troubleshooters.Com and my books and courses, is defined as "restoring the system to its as-designed behavior". When I chattr +i /etc/resolv.conf, I'm not troubleshooting, I'm redesigning. I violently disagree with the design decision of having the likes of wicd or NetworkManager modify my /etc/resolv.conf, at least on a non-portable desktop. Even on a laptop, today you can DNS from 8.8.8.8 and 8.8.4.4 anywhere you go, so there's no need to use the local ISP's suggested DNS servers. If I had demanded of myself to change the root cause instead of coathangering the symptom, I'd have needed to go to the Void Linux developers and ask them to find a way to accommodate DNS, in a travelling situation, without changing /etc/resolv.conf. But of course the software wasn't written by Void, it was written by people who have drunk heavily of the FreeDesktop.org flavored drink. I'd have as much success there as I'd have demanding Redhat drop systemd. When I repaired consumer audio equipment for a living, we had Technical Service Bulletins. Occasionally a bulletin would ask me to coathanger a symptom, and I'd do so. Because the manufacturers and/or Pacific Stereo had studied the situation and determined that the coathanger has minimal side effects and that it's by far the cheapest solution. Likewise, when I used Ubuntu, I wanted to get rid of Plymouth, which in my opinion is eye-candy for Windows Weenies. I tried and failed with package-manager-fu. I tried and failed with several other approaches. Finally I just renamed the Plymouth executable, and BANG, things worked like I wanted them to. SteveT Steve Litt Spring 2021 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
>>Quoting Steve Litt (sl...@troubleshooters.com): >If I had demanded of myself to change the root cause instead of >coathangering the symptom, I'd have needed to go to the Void Linux >developers and ask them to find a way to accommodate DNS, in a >travelling situation, without changing /etc/resolv.conf. Before Rick says it, the preceding paragraph was slightly miswritten. I'm sure on Void Linux there's some package-manager-fu or some other raindance to get /etc/resolv.conf to do what you want it to, without making it immutable. What I was trying to say was that if I wanted to change the *design* of the system, I'd have to petition the Void Linux packagers and the (urk) Freedesktop.org "upstream". SteveT Steve Litt Spring 2020 featured book: Thriving in Tough Times http://www.troubleshooters.com/thrive ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] What does this remind you of?
See this web page: https://en.wikipedia.org/wiki/Anti-pattern I'd say at least half of the listed anti-patterns are used by systemd. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote: > See this web page: > > https://en.wikipedia.org/wiki/Anti-pattern > > I'd say at least half of the listed anti-patterns are used by systemd. Very nice. Antony. -- I bought a book about anti-gravity. The reviews say you can't put it down. Please reply to the list; please *don't* CC me. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
On Sun, 7 Mar 2021 18:03:30 +0100 Antony Stone wrote: > On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote: > > > See this web page: > > > > https://en.wikipedia.org/wiki/Anti-pattern > > > > I'd say at least half of the listed anti-patterns are used by > > systemd. > > Very nice. > > Antony. > Hi, this makes me think of the times when you could startx with IceWM on a 1.44 floppy disk. That was simplicity and to a certain extent poetry. I personally would scrap: dbus consolekit packagekit policykit systemd apparmor selinux I am sure I've forgot some other garbage. P.S.: I'm open to new technologies.. when they follow a simple rule: less code is better as I can understand only as much code as fits onto my screen. Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
On 07-03-2021 18:20, tito via Dng wrote: > On Sun, 7 Mar 2021 18:03:30 +0100 > Antony Stone wrote: > >> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote: >> >>> See this web page: >>> >>> https://en.wikipedia.org/wiki/Anti-pattern >>> >>> I'd say at least half of the listed anti-patterns are used by >>> systemd. >> Very nice. >> >> Antony. >> > Hi, > this makes me think of the times when you could startx > with IceWM on a 1.44 floppy disk. That was simplicity > and to a certain extent poetry. I personally would scrap: > dbus > consolekit > packagekit > policykit > systemd > apparmor > selinux > I am sure I've forgot some other garbage. > > P.S.: I'm open to new technologies.. > when they follow a simple rule: less code is better > as I can understand only as much code as fits > onto my screen. > > Ciao, > Tito Hi, Mostly agree with you and in its current state apparmor belongs to this list. In the same time I like the idea of apparmor in limiting apps behavior. It could be most useful if implemented correctly. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
On Sun, 7 Mar 2021 19:11:18 +0100 "d...@d404.nl" wrote: > On 07-03-2021 18:20, tito via Dng wrote: > > On Sun, 7 Mar 2021 18:03:30 +0100 > > Antony Stone wrote: > > > >> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote: > >> > >>> See this web page: > >>> > >>> https://en.wikipedia.org/wiki/Anti-pattern > >>> > >>> I'd say at least half of the listed anti-patterns are used by > >>> systemd. > >> Very nice. > >> > >> Antony. > >> > > Hi, > > this makes me think of the times when you could startx > > with IceWM on a 1.44 floppy disk. That was simplicity > > and to a certain extent poetry. I personally would scrap: > > dbus > > consolekit > > packagekit > > policykit > > systemd > > apparmor > > selinux > > I am sure I've forgot some other garbage. > > > > P.S.: I'm open to new technologies.. > > when they follow a simple rule: less code is better > > as I can understand only as much code as fits > > onto my screen. > > > > Ciao, > > Tito > > Hi, > > Mostly agree with you and in its current state apparmor belongs to > this list. In the same time I like the idea of apparmor in limiting > apps behavior. It could be most useful if implemented correctly. > > Grtz. > > Nick > > Hi, I doubt this could be ever implemented correctly as you have to check every code path of every app you will armorize or as soon as your usage diverges from what the distro gurus have envisioned your program will stop working without even a warning. Next then we will need a uber-apparmor that checks apparmor safety and anyway more code more bugs less security. Why not fix the existing programs instead? Ciao, Tito ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
What does apparmor actually do? It was installed on my system as a Recommends for my kernel (linux-image-4.19.0-14-amd64), but I get warnings of some type every time I reboot (which I don't do often, so I can't say just what the warnings are). Is there any reason to keep it installed? Or can I just uninstall it? Marc On 3/7/21 10:11 AM, d...@d404.nl wrote: On 07-03-2021 18:20, tito via Dng wrote: On Sun, 7 Mar 2021 18:03:30 +0100 Antony Stone wrote: On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote: See this web page: https://en.wikipedia.org/wiki/Anti-pattern I'd say at least half of the listed anti-patterns are used by systemd. Very nice. Antony. Hi, this makes me think of the times when you could startx with IceWM on a 1.44 floppy disk. That was simplicity and to a certain extent poetry. I personally would scrap: dbus consolekit packagekit policykit systemd apparmor selinux I am sure I've forgot some other garbage. P.S.: I'm open to new technologies.. when they follow a simple rule: less code is better as I can understand only as much code as fits onto my screen. Ciao, Tito Hi, Mostly agree with you and in its current state apparmor belongs to this list. In the same time I like the idea of apparmor in limiting apps behavior. It could be most useful if implemented correctly. Grtz. Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
On 07-03-2021 19:22, Marc Shapiro via Dng wrote: > > What does apparmor actually do? It was installed on my system as a > Recommends for my kernel (linux-image-4.19.0-14-amd64), but I get > warnings of some type every time I reboot (which I don't do often, so > I can't say just what the warnings are). Is there any reason to keep > it installed? Or can I just uninstall it? > > Marc > > On 3/7/21 10:11 AM, d...@d404.nl wrote: >> On 07-03-2021 18:20, tito via Dng wrote: >>> On Sun, 7 Mar 2021 18:03:30 +0100 >>> Antony Stone wrote: >>> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote: > See this web page: > > https://en.wikipedia.org/wiki/Anti-pattern > > I'd say at least half of the listed anti-patterns are used by > systemd. Very nice. Antony. >>> Hi, >>> this makes me think of the times when you could startx >>> with IceWM on a 1.44 floppy disk. That was simplicity >>> and to a certain extent poetry. I personally would scrap: >>> dbus >>> consolekit >>> packagekit >>> policykit >>> systemd >>> apparmor >>> selinux >>> I am sure I've forgot some other garbage. >>> >>> P.S.: I'm open to new technologies.. >>> when they follow a simple rule: less code is better >>> as I can understand only as much code as fits >>> onto my screen. >>> >>> Ciao, >>> Tito >> Hi, >> >> Mostly agree with you and in its current state apparmor belongs to this >> list. In the same time I like the idea of apparmor in limiting apps >> behavior. It could be most useful if implemented correctly. >> >> Grtz. >> >> Nick >> >> See https://wiki.ubuntu.com/AppArmor for a explanation. Grz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] apparmor? (was Re: What does this remind you of?)
Sun, 7 Mar 2021 19:11:18 +0100 - "d...@d404.nl" : > On 07-03-2021 18:20, tito via Dng wrote: [...] I personally would scrap: [..] > > apparmor [...] > > Tito > Mostly agree with you and in its current state apparmor belongs to this > list. In the same time I like the idea of apparmor in limiting apps > behavior. It could be most useful if implemented correctly. > Nick Hi I have: ~~~ $ sudo service apparmor status apparmor module is loaded. 17 profiles are loaded. 17 profiles are in enforce mode. /usr/bin/man /usr/lib/cups/backend/cups-pdf /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session /usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium /usr/sbin/cups-browsed /usr/sbin/cupsd /usr/sbin/cupsd//third_party /usr/sbin/libvirtd /usr/sbin/libvirtd//qemu_bridge_helper /usr/sbin/ntpd /usr/sbin/tcpdump man_filter man_groff nvidia_modprobe nvidia_modprobe//kmod system_tor virt-aa-helper 0 profiles are in complain mode. 6 processes have profiles defined. 6 processes are in enforce mode. /usr/sbin/cups-browsed (2446) /usr/sbin/cupsd (12205) /usr/lib/cups/notifier/dbus (12208) /usr/sbin/cupsd /usr/sbin/libvirtd (3278) /usr/sbin/ntpd (3030) /usr/bin/tor (3200) system_tor 0 processes are in complain mode. 0 processes are unconfined but have a profile defined. ~~~ I have done nothing (I can remember) about apparmor configuration and profiles... Maybe it was installed by default or maybe I had installed it ages ago and it hasremained over time, a dist-upgrade after the other. So, I would like your advice: is there any sense that I keep it on the system? Or can I do without quietly? Thanks in advance. Regards al3xu5 -- Say NO to copyright, patents, trademarks and industrial design restrictions! Public GPG/PGP key: 8FC2 3121 2803 86E9 F7D8 B624 DA50 835B 2624 A36B pgpdYDzrLwRfj.pgp Description: Firma digitale OpenPGP ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] apparmor? (was Re: What does this remind you of?)
On 07-03-2021 19:39, al3xu5 wrote: > Sun, 7 Mar 2021 19:11:18 +0100 - "d...@d404.nl" : > >> On 07-03-2021 18:20, tito via Dng wrote: > [...] I personally would scrap: > [..] >>> apparmor > [...] >>> Tito >> Mostly agree with you and in its current state apparmor belongs to this >> list. In the same time I like the idea of apparmor in limiting apps >> behavior. It could be most useful if implemented correctly. >> Nick > > Hi > > I have: > > ~~~ > $ sudo service apparmor status > > apparmor module is loaded. > 17 profiles are loaded. > 17 profiles are in enforce mode. >/usr/bin/man >/usr/lib/cups/backend/cups-pdf >/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session >/usr/lib/x86_64-linux-gnu/lightdm/lightdm-guest-session//chromium >/usr/sbin/cups-browsed >/usr/sbin/cupsd >/usr/sbin/cupsd//third_party >/usr/sbin/libvirtd >/usr/sbin/libvirtd//qemu_bridge_helper >/usr/sbin/ntpd >/usr/sbin/tcpdump >man_filter >man_groff >nvidia_modprobe >nvidia_modprobe//kmod >system_tor >virt-aa-helper > 0 profiles are in complain mode. > 6 processes have profiles defined. > 6 processes are in enforce mode. >/usr/sbin/cups-browsed (2446) >/usr/sbin/cupsd (12205) >/usr/lib/cups/notifier/dbus (12208) /usr/sbin/cupsd >/usr/sbin/libvirtd (3278) >/usr/sbin/ntpd (3030) >/usr/bin/tor (3200) system_tor > 0 processes are in complain mode. > 0 processes are unconfined but have a profile defined. > ~~~ > > I have done nothing (I can remember) about apparmor configuration and > profiles... > > Maybe it was installed by default or maybe I had installed it ages ago and > it hasremained over time, a dist-upgrade after the other. > > So, I would like your advice: is there any sense that I keep it on the > system? Or can I do without quietly? > > Thanks in advance. > > Regards > al3xu5 > > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng In its current state (with little updated profiles working with enforce) it does not add much to your daily use imo. According to https://wiki.debian.org/AppArmor/HowToUse#Disable_AppArmor it is enabled by default in Debian 10. And you can disable it with a kernel parameter in grub. Grtz. Nick signature.asc Description: OpenPGP digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
On Fri, Mar 05, 2021 at 11:36:57AM -0800, Rick Moen wrote: > Quoting Steve Litt (sl...@troubleshooters.com): > > > The benefit of this list is if meet.jit.si ever dies during a meeting > > or classroom, there can be a predefined list of alternate URLs to go > > to. This makes Jitsi a much safer choice than I thought it was. > > More to the point, Jitsi Meet (reminder: that's its correct name) > is open source (Apache License 2.0). All it takes to run is a computer > with adequate RAM and a public IP address. AND enough network bandwidth. -- hendrik > > BigBlueButton also has many adherents, and is generally similar > (including relying on WebRTC and being open source, LGPL). > > -- > Cheers, "2021 showed up, and told 2020 'hold my > beer.'" > Rick Moen -- @justinaireland > r...@linuxmafia.com > McQ! (4x80) > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Hendrik Boom (hend...@topoi.pooq.com): > On Fri, Mar 05, 2021 at 11:36:57AM -0800, Rick Moen wrote: > > More to the point, Jitsi Meet (reminder: that's its correct name) > > is open source (Apache License 2.0). All it takes to run is a computer > > with adequate RAM and a public IP address. > > AND enough network bandwidth. But less than you might think. Locally, one LUG leader stands up a Jitsi Meet instance occasionally for LUG use in a modest Qemu/KVM virtual machine on a laptop that's on his residential ADSLv1. When I was configuring the instance on Amazon EC2 for the New Zealand Worldcon (Aug. 2020), I took a number of precautions against excessive bandwidth draw, including setting the default to outbound video = off for people joining conferences. That having been said, my main worry was pegging RAM or CPU on the Jitsi Videobridge 2 component, that routes all the video whizzing back and forth. As it turned out, RAM & CPU usage as recorded on Zabbix remained quite low. I'll also mention that each connected user's video link automatically will step down resolution/framerate to reflect how much bandwidth is available. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
See https://wiki.ubuntu.com/AppArmor for a explanation. Ubuntu? What's that? Is that the thing they use in North America 'cause they never heard of Debian? There is https://wiki.debian.org/AppArmor too, it seems (never read it). Bernard (Beer) Rosset https://rosset.net/ ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] apparmor? (was Re: What does this remind you of?)
On Sun, 2021-03-07 at 19:39 +0100, al3xu5 wrote: > Maybe it was installed by default or maybe I had installed it ages > ago and > > it hasremained over time, a dist-upgrade after the other. > > > > So, I would like your advice: is there any sense that I keep it on > the > > system? Or can I do without quietly? For me, apparmor came with the upgrade to beowulf. I had some problem with it, I think it was killing an application that I use. After searching around on the web, I decided to just try apt purge apparmor. I did that 6 or 8 months ago or so and didn't have any issues. Although, apparmor is reinstalled with upgrades based on my experience. It's back on my machine now actually and has been for a month or so. I'll purge it again but since it was reinstalled I've been curious if it will start causing me problems again, so I've left it so far. Gabe ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Bug on backport-kernel
Hi, somebody has an idea what this is about? I 've looked at _rb_insert_augmented but there was nothing obvious for a self taught free time coder. Ciao, Tito Mar 7 01:00:01 aplysia kernel: [1168943.562359] BUG: kernel NULL pointer dereference, address: 0008 Mar 7 01:00:01 aplysia kernel: [1168943.562440] #PF: supervisor read access in kernel mode Mar 7 01:00:01 aplysia kernel: [1168943.562480] #PF: error_code(0x) - not-present page Mar 7 01:00:01 aplysia kernel: [1168943.562519] PGD 0 P4D 0 Mar 7 01:00:01 aplysia kernel: [1168943.562546] Oops: [#1] SMP PTI Mar 7 01:00:01 aplysia kernel: [1168943.562576] CPU: 0 PID: 18545 Comm: php Tainted: G OE 5.10.0-0.bpo.3-amd64 #1 Debian 5.10.13-1~bpo10+1 Mar 7 01:00:01 aplysia kernel: [1168943.562650] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./C2750D4I, BIOS P3.20 03/26/2018 Mar 7 01:00:01 aplysia kernel: [1168943.562722] RIP: 0010:__rb_insert_augmented+0x23/0x1e0 Mar 7 01:00:01 aplysia kernel: [1168943.562762] Code: 06 c3 48 89 41 10 c3 48 8b 07 48 85 c0 0f 84 c2 01 00 00 41 54 49 89 f4 55 53 48 83 ec 08 48 8b 18 f6 c3 01 0f 85 ee 00 00 00 <48> 8b 4b 08 48 89 de 48 39 c1 74 65 48 85 c9 74 09 f6 01 01 0f 84 Mar 7 01:00:01 aplysia kernel: [1168943.562888] RSP: 0018:b6f48b07fd48 EFLAGS: 00010246 Mar 7 01:00:01 aplysia kernel: [1168943.562929] RAX: 985c70932378 RBX: RCX: 001c Mar 7 01:00:01 aplysia kernel: [1168943.562980] RDX: 8ce311d0 RSI: 985c49f6e3f8 RDI: 985cf34b08f0 Mar 7 01:00:01 aplysia kernel: [1168943.563031] RBP: 985cf34b0898 R08: 985c70932378 R09: Mar 7 01:00:01 aplysia kernel: [1168943.563081] R10: 985cf34b0898 R11: R12: 985c49f6e3f8 Mar 7 01:00:01 aplysia kernel: [1168943.563133] R13: 985dad9bfb10 R14: 985dad9bfaf0 R15: 985c49f6e408 Mar 7 01:00:01 aplysia kernel: [1168943.563185] FS: 7f68bac90980() GS:98639fc0() knlGS: Mar 7 01:00:01 aplysia kernel: [1168943.563242] CS: 0010 DS: ES: CR0: 80050033 Mar 7 01:00:01 aplysia kernel: [1168943.563285] CR2: 0008 CR3: 0001b3406000 CR4: 001006f0 Mar 7 01:00:01 aplysia kernel: [1168943.563335] Call Trace: Mar 7 01:00:01 aplysia kernel: [1168943.563368] vma_link+0x6c/0xb0 Mar 7 01:00:01 aplysia kernel: [1168943.563400] mmap_region+0x48d/0x6c0 Mar 7 01:00:01 aplysia kernel: [1168943.563432] do_mmap+0x373/0x580 Mar 7 01:00:01 aplysia kernel: [1168943.563463] vm_mmap_pgoff+0xd3/0x120 Mar 7 01:00:01 aplysia kernel: [1168943.563496] ksys_mmap_pgoff+0x1dd/0x240 Mar 7 01:00:01 aplysia kernel: [1168943.563530] do_syscall_64+0x33/0x80 Mar 7 01:00:01 aplysia kernel: [1168943.563563] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Mar 7 01:00:01 aplysia kernel: [1168943.563604] RIP: 0033:0x7f68bd9db6f3 Mar 7 01:00:01 aplysia kernel: [1168943.563636] Code: 54 41 89 d4 55 48 89 fd 53 4c 89 cb 48 85 ff 74 4e 49 89 d9 45 89 f8 45 89 f2 44 89 e2 4c 89 ee 48 89 ef b8 09 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 65 5b 5d 41 5c 41 5d 41 5e 41 5f c3 66 2e 0f Mar 7 01:00:01 aplysia kernel: [1168943.563763] RSP: 002b:7fffdbbac298 EFLAGS: 0246 ORIG_RAX: 0009 Mar 7 01:00:01 aplysia kernel: [1168943.563819] RAX: ffda RBX: RCX: 7f68bd9db6f3 Mar 7 01:00:01 aplysia kernel: [1168943.563870] RDX: 0001 RSI: 0001c038 RDI: Mar 7 01:00:01 aplysia kernel: [1168943.563921] RBP: R08: 0003 R09: Mar 7 01:00:01 aplysia kernel: [1168943.563971] R10: 0802 R11: 0246 R12: 0001 Mar 7 01:00:01 aplysia kernel: [1168943.565711] R13: 0001c038 R14: 0802 R15: 0003 Mar 7 01:00:01 aplysia kernel: [1168943.567435] Modules linked in: fuse btrfs blake2b_generic ufs qnx4 hfsplus hfs cdrom minix vfat msdos fat jfs xfs dm_mod nft_limit nft_counter nft_compat nft_chain_nat nf_tables nfnetlink xt_geoip(OE) xt_CT xt_tcpudp xt_helper nf_conntrack_ftp nf_log_ipv4 nf_log_common ip6table_raw ip6table_mangle ip6table_nat iptable_nat nf_nat xt_TCPMSS xt_LOG ipt_REJECT nf_reject_ipv4 iptable_raw iptable_mangle xt_multiport xt_state xt_limit xt_conntrack nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip6table_filter ip6_tables iptable_filter ip_tables x_tables nct6775 hwmon_vid intel_powerclamp coretemp kvm_intel kvm ipmi_ssif irqbypass crc32_pclmul ghash_clmulni_intel aesni_intel libaes ast drm_vram_helper drm_ttm_helper crypto_simd ttm cryptd drm_kms_helper glue_helper cec wdat_wdt drm watchdog intel_cstate acpi_ipmi ipmi_si pcspkr at24 ipmi_devintf joydev evdev ipmi_msghandler button acpi_cpufreq ext4 crc16 mbcache jbd2 raid10 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_pq Mar 7 01:00:01 aplysia kernel: [1168943.567542] async_xor async_tx xor rai
Re: [DNG] web conferencing software (was Re: Any interest in a Devuan Meetup in Colorado Springs or Denver?)
Quoting Steve Litt (sl...@troubleshooters.com): > If I had demanded of myself to change the root cause instead of > coathangering the symptom, I'd have needed to go to the Void Linux > developers and ask them to find a way to accommodate DNS, in a > travelling situation, without changing /etc/resolv.conf. [acknowledging your point, posted separately, that Void Linux devs could doubtless cite some way to do so, if you asked them.] > What I was trying to say was that if I wanted to change the *design* of > the system, I'd have to petition the Void Linux packagers and the (urk) > Freedesktop.org "upstream". [...] > I violently disagree with the design decision of having the likes of > wicd or NetworkManager modify my /etc/resolv.conf, at least on a > non-portable desktop. Even on a laptop, today you can DNS from 8.8.8.8 > and 8.8.4.4 anywhere you go, so there's no need to use the local ISP's > suggested DNS servers. (I'll get to the 'no need' statement further down.) I doubt you _truly_ aimed at a system redesign to the effect that "Nothing shall be allowed to touch /etc/resolv.conf except me doing 'chattr -i /etc/resolv.conf; vi /etc/resolv.conf; chattr +i /etc/resolv.conf'." Because there are legitimate reasons to do otherwise. TCP/IP-networked systems fall into two broad classes, those that are DHCP clients and those statically IPed. Statically IPed systems are the easy case, I cannot presently think of any system software sysadmins are tempted to run that would want to alter /etc/resolv.conf . That leaves DHCP clients. There are three DHCP client implementations I'm aware of for Linux. My Resolvconf page (link posted earlier) explains how to control what each does to the nameserver line(s) in /etc/resolv.conf . So, I've documented how to override and control (if desired) those system utilities' mucking about. Likewise, My page details how to do likewise with either of the two competing Resolvconf implementations (which is why the page has that name). That leaves 'network managers' like GNOME NetworkManager, wicd, and all that lot. wicd appears to invoke Resolvconf to manage /etc/resolv.conf, so see above. GNOME NetworkManager keeps its grubby paws off /etc/resolv.conf if that file's a symlink (including but not limited to use of Resolvconf, which like wicd, GNOME NetworkManager relies on). So, do that. _Or_, create /etc/NetworkManager/conf.d/90-dns-none.conf containing [main] dns=none ...and restarted the damned GNOME NetworkManager thing. Theoretically, I could research and document how to do likewise for every goshdarned ill-advised tool that occasionally mucks with the nameserver line in /etc/resolv.conf -- systemd-resolvd, netctl, an endless variety of crummy little utilities. I won't, because (1) there's no end to that, but -- more to the point -- (2) people who run crummy little utilities like that need to understand the basics of how they work. Or, here's an idea: Don't have them. I have a standard joke about the "Facebook remedy". People ask me how I solve Facebook problems, and my cheery answer is "Simple! No Facebook; no Facebook problems!" I've not needed those crummy little network-administrative utilities. If I adopted one, I'd take the trouble to research its basics, including how to _properly_ instruct it to keep its grubby little paws off the nameserver line in /etc/resolv.conf . And, by the way, sadly, no you are incorrect that "you can DNS from 8.8.8.8 and 8.8.4.4 anywhere you go": Leaving aside my being disappointed about people willingly outsourcing their recursive DNS to the second-nosiest company on the planet[1] instead of just running a local recursive nameserver, sorry, you'll find that such a setup breaks when negotiating a "captive portal" on, e.g., most hotel and motel WiFi, where crummy artificial DNS on the WAP redirects any initial HTTP query to the portal Web site, where you prove that you're an authorised user before they give your client routing to outside the service network. Overriding that nameserver instruction means you won't see the login Web page, so you won't be able to prove you're a customer, so you won't get a usable connection. The above is a vexing problem for travelers w/laptops who prefer to specify their own choice of nameserver and still use hotel/motel WiFi (and wired ethernet, actually). Best case, you have to disable your nameserver IP override long enough to navigate the captive portal, and then can put the override back. But, no, you cannot just leave your choice of nameserver IPs in place (without disappointment). [1] Nor is it any better to outsource to OpenNIC, Cisco Umbrella, Comodo, Yandex, UncensoredDNS, etc. Here's an idea: How about not outsourcing recursive DNS to anyone? It's not like it's even difficult. We've had this conversation before. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
>On Fri, Mar 05, 2021 at 11:36:57AM -0800, Rick Moen wrote: >> Quoting Steve Litt (sl...@troubleshooters.com): >> >> > The benefit of this list is if meet.jit.si ever dies during a >> > meeting or classroom, there can be a predefined list of alternate >> > URLs to go to. This makes Jitsi a much safer choice than I thought >> > it was. >> >> More to the point, Jitsi Meet (reminder: that's its correct name) >> is open source (Apache License 2.0). All it takes to run is a >> computer with adequate RAM and a public IP address. > >AND enough network bandwidth. AND the tech chops to set it up. SteveT Steve Litt Spring 2021 featured book: Troubleshooting Techniques of the Successful Technologist http://www.troubleshooters.com/techniques ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Any interest in a Devuan Meetup in Colorado Springs or Denver? (was "GNUPGP Web of trust")
Quoting Steve Litt (sl...@troubleshooters.com): > AND the tech chops to set it up. I provided a simple copy/paste recipe. My friend Michael Paoli even scripted the entire process: http://www.mpaoli.net/~michael/tmp/2jitsi And just following the official instructions isn't actually difficult, either. "Tech chops" my great aunt. Don't be such a technopeasant. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] What does this remind you of?
Anno domini 2021 Sun, 7 Mar 19:18:42 +0100 tito via Dng scripsit: > On Sun, 7 Mar 2021 19:11:18 +0100 > "d...@d404.nl" wrote: > > > On 07-03-2021 18:20, tito via Dng wrote: > > > On Sun, 7 Mar 2021 18:03:30 +0100 > > > Antony Stone wrote: > > > > > >> On Sunday 07 March 2021 at 17:59:22, Steve Litt wrote: > > >> > > >>> See this web page: > > >>> > > >>> https://en.wikipedia.org/wiki/Anti-pattern > > >>> > > >>> I'd say at least half of the listed anti-patterns are used by > > >>> systemd. > > >> Very nice. > > >> > > >> Antony. > > >> > > > Hi, > > > this makes me think of the times when you could startx > > > with IceWM on a 1.44 floppy disk. That was simplicity > > > and to a certain extent poetry. I personally would scrap: > > > dbus > > > consolekit > > > packagekit > > > policykit > > > systemd > > > apparmor > > > selinux > > > I am sure I've forgot some other garbage. > > > > > > P.S.: I'm open to new technologies.. > > > when they follow a simple rule: less code is better > > > as I can understand only as much code as fits > > > onto my screen. > > > > > > Ciao, > > > Tito > > > > Hi, > > > > Mostly agree with you and in its current state apparmor belongs to > > this list. In the same time I like the idea of apparmor in limiting > > apps behavior. It could be most useful if implemented correctly. > > > > Grtz. > > > > Nick > > > > > > Hi, > I doubt this could be ever implemented correctly as you have to check > every code path of every app you will armorize or as soon as your usage > diverges from what the distro gurus have envisioned your program > will stop working without even a warning. > Next then we will need a uber-apparmor that checks apparmor safety > and anyway more code more bugs less security. Why not fix the existing > programs instead? The point is to delegate access control to a higher instance e.g. kernel. The problem is, that apparmor looks at a program from the the outside and tries to do the right thing with that black box - or what the profiles provider thought was the right thing. OpenBSD has quite an interesting aproach with unveil ( https://man.openbsd.org/unveil.2 ) and pledge ( https://man.openbsd.org/pledge ). The programmer itself takes care what the program will use and tells the system that what e.g. access privileges it does not want to use from now on. That's the look at the world from the inside, no black box involved. If you droped things, you can never get them back, so evil hackers code is confined inside the same cage. Nik > > Ciao, > Tito > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
