Re: Isolated Web Co Session crash Firefox-ESR
Hi. On Sun, Dec 03, 2023 at 12:58:47PM +0800, jeremy ardley wrote: > I noticed my Firefox -esr browser becoming progressively more sluggish. Then > suddenly I was back to the system login screen > > This is not the first time this has happened although previously when it > started getting sluggish I killed all Firefox related process > > System logs show the start of the event. > > 2023-12-03T11:35:03.335043+08:00 client kernel: [3792101.257070] Isolated Web > Co invoked oom-killer: > gfp_mask=0x140dca(GFP_HIGHUSER_MOVABLE|__GFP_COMP|__GFP_ZERO), order=0, > oom_score_adj=100 Tail of that particular trace always shows top memory consumers at the very moment oom-killer was invoked. Skipping that information can and will lead to guessing. And in this particular case: > inactive_anon:29781756kB > anon_thp: 17088512kB Do you have any relatively large filesystem, such as /tmp, mounted as tmpfs? Any tmpfs contents are not accounted by free(1) or top(1), but using large tmpfs with small swap can lead to funny results to say the least. Reco
Re: approx in debian 12
Hi. On Fri, Nov 17, 2023 at 08:03:15AM +, Russell L. Harris wrote: > On Fri, Nov 17, 2023 at 10:34:14AM +0300, Reco wrote: > > Looks good. What about this one: > > > > apt update -o Acquire::http::Proxy=http://localhost: > > root@mollydew:/etc/approx# apt update -o > Acquire::http::Proxy=http://localhost: > Ign:1 http://security.debian.org/debian-security bookworm-security InRelease Hm. I have this in my approx.conf for debian-security: debian-security http://deb.debian.org/debian-security Try changing it, I guess. Reco
Re: approx in debian 12
On Fri, Nov 17, 2023 at 07:25:23AM +, Russell L. Harris wrote: > On Fri, Nov 17, 2023 at 09:56:07AM +0300, Reco wrote: > > OK. And what happens if you execute this on a approx server: > > > > curl -x http://localhost: -v > > http://ftp.debian.org/debian/dists/stable/Release >/dev/null > > root@mollydew:/etc/approx# curl -x http://localhost: -v > http://ftp.debian.org/debian/dists/stable/Release >/dev/null > % Total% Received % Xferd Average Speed TimeTime Time Current > Dload Upload Total SpentLeft Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0* Trying 127.0.0.1:... > * Connected to localhost (127.0.0.1) port (#0) > > GET http://ftp.debian.org/debian/dists/stable/Release HTTP/1.1 > > Host: ftp.debian.org > > User-Agent: curl/7.88.1 > > Accept: */* > > Proxy-Connection: Keep-Alive > > > < HTTP/1.1 200 OK Looks good. What about this one: apt update -o Acquire::http::Proxy=http://localhost: Reco
Re: approx in debian 12
On Fri, Nov 17, 2023 at 06:48:37AM +, Russell L. Harris wrote: > > > debian http://fpt.debian.org/debian > > > > Is this a typo? It should be (ftp, not fpt) > Yes; a typo. OK. And what happens if you execute this on a approx server: curl -x http://localhost: -v http://ftp.debian.org/debian/dists/stable/Release >/dev/null Reco
Re: approx in debian 12
Hi. On Fri, Nov 17, 2023 at 05:54:45AM +, Russell L. Harris wrote: > Both the target machine (192.168.1.25) and the approx server > (192.168.1.30) are in my LAN. The approx server is a fresh install of > Debian 12. > > The approx.conf file has only two lines uncommented (should I add "us"?): > > debian http://fpt.debian.org/debian Is this a typo? It should be (ftp, not fpt) debian http://ftp.debian.org/debian > Scanning the archive mirror produces the "red screen of death" BAD > ARCHIVE MIRROR. Virtual console 4 says: "WARNING **: mirror does not > support the specified release" "journalctl | grep approx" on approx server should show something that's related to the problem. Reco
Re: dmraid not creation devices for partitions
Hi. On Wed, Nov 15, 2023 at 10:11:16AM +, Drone Ah wrote: > I found > https://unix.stackexchange.com/questions/709184/fakeraid-partition-missing-not-mapped-as-a-device-on-boot-after-upgrade-to-ubu/760998#760998 > > Using kpartx as suggested in the above post does solve the problem. Getting > it to run at startup, if required is another issue. > > However, my question is whether this is a bug to be reported. If so, for > which package? dmraid? udev package seems more appropriate. Reco
Re: approx in debian 12
Hi. On Thu, Nov 16, 2023 at 07:02:39AM +, Russell L. Harris wrote: > On Thu, Nov 16, 2023 at 07:14:04AM +0100, Kamil Jo?ca wrote: > > Kamil Jo?ca writes: > > > > > Charles Curley writes: > > > > > > > On Thu, 16 Nov 2023 04:11:37 + > > > > "Russell L. Harris" wrote: > > > > > > > > > root@mollydew:/home/rlh# systemctl daemon-reload > > > > > root@mollydew:/home/rlh# systemctl restart approx > > > > > Failed to restart approx.service: Unit approx.service not found. > > > > > root@mollydew:/home/rlh# systemctl status approx > > > > > Unit approx.service could not be found. It's expected, see below. > > What if you issue: > > systemctl status "approx@*.service" > > It appears to run; no error message is produced, but no output, either. > > But I am in not in familiar territory. What you have is approx.socket unit, which causes systemd to listen on tcp:. On each incoming connection "approx@:-:.service" is started. That service is only used to serve that particular connection, and is terminated after. Thus, there's nothing to restart. You just edit /etc/approx/approx.conf, and try your changes immediately. Reco
Re: How to compare one folder to one directory (was: How to compare contents of two folders against third one?)
Hi. On Thu, Nov 02, 2023 at 07:50:16AM +0100, Loris Bennett wrote: > writes: > > > I concur with Nicolas: every time you say "folder", a unicorn dies. > > What's the objection to 'folder'? $ mkdir /tmp/4 $ stat /tmp/4 | head -2 File: /tmp/4 Size: 4096Blocks: 8 IO Block: 4096 **directory** If you refer to a filesystem object, using anything else but a real object type name is wrong. Reco
Re: etcd - ETCD_TLS_MIN_VERSION
Hi. On Tue, Oct 31, 2023 at 04:46:29PM -0600, Dennis Gesker wrote: > Should ETCD_TLS_MIN_VERSION and ETCD_CIPHER_SUITES be recognized as valid > in the /etc/default/etcd file? ETCD_CIPHER_SUITES should be recognized. As for ETCD_TLS_MIN_VERSION - it could, but it won't. [1] shows us, that --tls-min-version and --tls-max-version were added in etcd version 3.4.25. Both bookworm and trixie have only 3.4.23. Reco [1] https://github.com/etcd-io/etcd/blob/main/CHANGELOG/CHANGELOG-3.4.md
Re: Debian installer refuses to setup IP address if gateway is no in the same subnet
Hi.
On Tue, Oct 31, 2023 at 11:13:04AM +0100, Marco M. wrote:
> > Maybe you need to help the installer along, and set the default route
> > for the machine? Perhaps using an alternate virtual terminal, like
> > FN+F5. I believe the command is `route add default gw {IP-ADDRESS}
> > {INTERFACE-NAME}`.
>
> sudo ip route add dev
> sudo ip route add 0.0.0.0/0 via
Actually, you can do it in a single command:
ip ro a default via dev onlink
Reco
Re: auto add usb network to bridge
Hi. On Mon, Sep 25, 2023 at 11:35:50AM +0200, Petric Frank wrote: > My /etc/network/interfaces reads like this: > -- cut > auto lo > iface lo inet loopback > > # onloard device > iface ens18 inet manual > > # usb device (not always there) > iface enx0 inet manual > > auto br0 > iface br0 inet static > address 10.10.10.1/24 > bridge-ports ens18 enx0 > bridge-stp off > bridge-fd 0 > -- cut > > This works as long the usb device is plugged in at boot time. > > Connecting it later the usb network device appears but will not be attached > to the bridge. You have to do it differently, like this: auto lo iface lo inet loopback # onloard device iface ens18 inet manual # usb device (not always there) allow-hotplug enx0 iface enx0 inet manual up /sbin/ip link set $IFACE master br0 auto br0 iface br0 inet static address 10.10.10.1/24 bridge-ports ens18 bridge-stp off bridge-fd 0 What that does is forces udev to execute "ifup enx0" on USB device detection, which in turn causes the network interface to attach to br0. Reco
Re: Printer HP LaserJet MFP M234sdw 5085B1
Hi. On Wed, Sep 20, 2023 at 05:05:12PM +0200, Erwan David wrote: > On Wed, Sep 20, 2023 at 04:42:12PM CEST, Reco said: > > On Wed, Sep 20, 2023 at 04:01:25PM +0200, Erwan David wrote: > > > Le 20/09/2023 à 15:55, Jörg-Volker Peetz a écrit : > > > > With this printer CUPS driverless printing works, see > > > > https://wiki.debian.org/CUPSDriverlessPrinting . No need for hplip. > > > > > > > Once again : cups driverless printing works ONLY when printer and > > > computer are on SAME NETWORK. > > > > Nope, that's not required. Whenever 'same network' is actually 'same L2 > > network segment', or 'same L3 IP subnet'. > > Because it's totally possible to configure CUPS to use known IPP > > destination without discovery, like this: > > > > lpadmin -p myprinter -E -v ipp:///ipp/print -m > > everywhere > > > > Discovering said IP is another story of course. > > First time I here it (and that's not first time I try to find the info). I'll > give it a try. So hplip will still be useful for scanning I guess ? Of course hplip is still useful for scanning (as in - don't try scanning anything by any HP MFD without hplip :) Unless they've implemented "driverless" scanning too. Reco
Re: Printer HP LaserJet MFP M234sdw 5085B1
On Wed, Sep 20, 2023 at 04:01:25PM +0200, Erwan David wrote: > Le 20/09/2023 à 15:55, Jörg-Volker Peetz a écrit : > > With this printer CUPS driverless printing works, see > > https://wiki.debian.org/CUPSDriverlessPrinting . No need for hplip. > > > Once again : cups driverless printing works ONLY when printer and computer > are on SAME NETWORK. Nope, that's not required. Whenever 'same network' is actually 'same L2 network segment', or 'same L3 IP subnet'. Because it's totally possible to configure CUPS to use known IPP destination without discovery, like this: lpadmin -p myprinter -E -v ipp:///ipp/print -m everywhere Discovering said IP is another story of course. Reco
Re: How to remove GNOME from a headless virtual Sid
Hi. On Mon, Sep 11, 2023 at 09:28:15AM +0200, Thomas Schmitt wrote: > how to get rid of voluminous desktop stuff without colateral damage ? I'd start with: apt purge libgtk-3-0 libqt* Possibly followed by: apt autoremove --purge It's assumed that you read through the list of packages to be removed before you actually do it :) Reco
Re: Corrupt root filesystem
On Fri, Jul 07, 2023 at 06:26:28PM +0100, Mick Ab wrote: > The error messages were of the form :- > > "/dev/mapper/vgpcname-root contains a file system with errors, check > forced. >Inodes that were a part of a corrupted orphan linked lost found. >/dev/mapper/vgpcname-root : UNEXPECTED INCONSISTENCY; RUN fsck > manually.(i.e ., >without -a or -p options). fsck exited with status code 4. The root >filesystem on /dev/mapper/vgpcname-root requires a manual fsck > > There is then a flashing prompt after "(initramfs)". So, first things first, it's not "before reboot". It's "during the boot". And note that initramfs ran fsck, but it failed. Second, yes, that particular filesystem is indeed required fsck. > The following command was thus run :- > sudo fsck -y /dev/mapper/vgpcname-root > The PC could then be rebooted. You've got it wrong here again. During initramfs stage root filesystem is mounted readonly. This allows it to be checked by fsck, without causing an additional damage. And, since it's a root filesystem, it's *required* to reboot after the fsck. > The file system is ext4. Thanks. It's a rare sight these days that people actually answer all the questions they're asked. Now, assuming you're using a stock Debian kernel, it's unlikely to be a kernel bug. Likewise, we can exclude some "user-firendly" software (I'm looking at you, GNOME). Which leaves us with the hardware fault. Hate to bring it to you, but additional information would be welcome. You're using lvm2, it's obvious. But which drive your physical volume resides on? I.e. make, model, SMART attributes if any? Reco
Re: Corrupt root filesystem
On July 7, 2023 6:01:23 PM GMT+03:00, Mick Ab wrote: >Twice, when trying to reboot my PC, I have had error messages which >indicate the root file system is corrupted and needs the manual use of fsck >to fix the root file system before a reboot can be done. > Typically, running fsck requires an unmounted filesystem (or at least readonly one). Achieving this before the reboot is a pretty hard trick. Thus, more information is needed. What does the message says exactly? What is the type (ext4, xfs, whatever) of the problematic filesystem? >Any thoughts please as to what might cause the above problem ? A hardware fault. A kernel bug. Overprotective software. Could be anything. Reco Hi.
Re: Debian 12, setting hostname does not persist
Hi. On Tue, Jun 27, 2023 at 10:54:32AM -0400, David Mehler wrote: > used because the interface(s) are all getting there IP addresses > statically assigned. New plan then. apt install auditd echo '-a always,exit -F arch=b64 -S sethostname' \ > /etc/audit/rules.d/hostname.rules echo '-a always,exit -F path=/proc/sys/kernel/hostname -F perm=wa' \ >> /etc/audit/rules.d/hostname.rules service auditd restart reboot Whatever's trying to change the hostname should leave a trace in /var/log/audit/audit.log. PS Here it's customary to reply at the bottom of e-mail, not at the top. There's no need to quote the mail you're replying to in full. Reco
Re: Debian 12, setting hostname does not persist
Hi. On Tue, Jun 27, 2023 at 08:06:17AM -0400, David Mehler wrote: > You might be on to something though here's what is in > /etc/dhcp/dhclient.conf I'm just not sure what options to comment out? That's even easier. Instead of send host-name = gethostname(); request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, domain-search, host-name, dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers, you should probably use: send host-name = gethostname(); request subnet-mask, broadcast-address, time-offset, routers, domain-name, domain-name-servers, domain-search, dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn, dhcp6.sntp-servers, If it does not help - consider adding: supersede host-name ""; Reco
Re: Debian 12, setting hostname does not persist
Hi. On Tue, Jun 27, 2023 at 06:48:52AM -0400, David Mehler wrote: > the upgrade itself went just fine. I set my time zone that stuck and > is persisting then went for the hostname, I am doing this via ssh, in > setting the hostname it won't persist through a reboot. One of the possible reasons for this is "cloud-init". Purge the package, or set "preserve_hostname: true" in /etc/cloud/cloud.cfg. Another one could be DHCP client. "nooption host_name" in dhcpcd.conf should fix the issue. Reco
Re: Angry, yet wrong too (was: OT: Pedantic, yet wrong)
On Thu, Jun 22, 2023 at 01:09:28PM +, Ottavio Caruso wrote:
> Am 22/06/2023 um 10:46 schrieb Reco:
> > On Thu, Jun 22, 2023 at 10:28:42AM +, Ottavio Caruso wrote:
> >
> > > > don't appreciate top posting around here)
> > >
> > > You've managed to be pedantic and patronising yet wrong. When the
> > > message is forwarded ("Weitergeleitet", you should know this, since
> > > you use a *.de domain), you have no other choice than to top post
> > > because the forwarded message is not indented.
> >
> > Before the message is forwarded, you actually have a choice whenever to
> > use dumb "inline forward style" (which you did) or proper
> > rfc822-compliant attachment (which your MUA should support).
> > In the latter case you're free to express yourself using top-posting,
> > bottom-posting or interleaved posting (which is preferred here) or even
> > cat-pictures posting.
> >
> > Of course, proper forwarding requires using a real MUA. You could
> > consider start using one.
>
> Thunderbird is a real MUA.
Consider using it properly then, because currently you're not.
Read a user guide or something.
> > PS Using real OS cannot not hurt you too, you know.
>
> You have never heard of user agent spoofing have you?
I did. So did Spamassasin.
But most importantly - you just had to prove that you're using real OS,
*and* you did just because I've asked you nicely.
See - my approach works, yours - not so much :)
Reco
Re: Angry, yet wrong too (was: OT: Pedantic, yet wrong)
On Thu, Jun 22, 2023 at 10:28:42AM +, Ottavio Caruso wrote:
> > don't appreciate top posting around here)
>
> You've managed to be pedantic and patronising yet wrong. When the
> message is forwarded ("Weitergeleitet", you should know this, since
> you use a *.de domain), you have no other choice than to top post
> because the forwarded message is not indented.
Before the message is forwarded, you actually have a choice whenever to
use dumb "inline forward style" (which you did) or proper
rfc822-compliant attachment (which your MUA should support).
In the latter case you're free to express yourself using top-posting,
bottom-posting or interleaved posting (which is preferred here) or even
cat-pictures posting.
Of course, proper forwarding requires using a real MUA. You could
consider start using one.
PS Using real OS cannot not hurt you too, you know.
Reco
Re: package managers problem
Hi. On Wed, Jun 21, 2023 at 12:57:41PM +0100, Joe wrote: > On Tue, 20 Jun 2023 17:34:45 -0400 > gene heskett wrote: > > > > My fav editor, geany is also > > dead for roots use for exactly he same reason, but runs just fine as > > me. So there is a common problem. > > Well, you could do it the right way: edit as you with geany in a work > directory, copy to/from the real location with a root-powered file > manager, such as mc under sudo in a terminal. Alter owner/perms as > required with mc. Or just use visudo which does it all without user's intervention. visudo, and this is a hint, *does* allow user to invoke both X- and Wayland-based text editors, given the appropriate amount of configuration. And this is the rightest (sp?) way there is, because allowing user to run root-powered file manager is a deviation from the said way. Reco
Re: bookworm upgrade report: not so boring (was: boring)
Hi. On Sun, Jun 11, 2023 at 12:31:31PM -0400, Dan Ritter wrote: > The machine I am typing on has been upgraded from bullseye to > bookworm. TL;DR: boring, which is good. My experience is somewhat different. 1) NTP was replaced by NTPsec. Not that I oppose the change, but 'ntpq -nc peers localhost' just hangs after the upgrade. Solved by replacing NTPsec with chrony (where I need ) 2) Exim started tainting macro arguments in transports' configuration. Broke my custom transports (aka mail delivery), but was easy to fix. 3) Kernel size has increased, again. This time it bricked one of my armhf boards, just because NAND partition has 5MB limit. It was time to decommission this particular hardware anyway, but I'll try to work around it. 4) dhcpcd became multi-process monstrosity. And it's my fault, but a custom apparmor profile caused the thing to write 6-7 Gb of identical error messages before I saw it. Note to self - do aa-complain *before* the upgrade, not *after*. 5) systemd-binfmtd fails on boot due to the python 3.11. But it's nothing that 'systemctl mask' cannot solve. 6) Contrary to my expectations, CUPS, SANE and Strongswan upgrades were easy. Although I did not try to use the printer or the scanner after the upgrade. So, bookworm has an interesting beginning, to say the least. Certainly more interesting than buster->bullseye upgrade. Reco
It's that time of the year again
Dear list, [1] came to my attention today. Quoting the most relevant part (emphasis mine): There are still about 100 known RC bugs affecting bookworm, but we have accepted *to release having them included*. Forewarned is forearmed, as they say. [1] https://lists.debian.org/debian-devel-announce/2023/06/msg0.html -- Reco
Re: OT: Mutt's Message-ID and web link
Hi. On Mon, May 29, 2023 at 04:30:23PM +0200, Thomas Schmitt wrote: > Hi, > > Reco wrote: > > [1] works for me perfectly, for instance. > > [1] > > https://lists.debian.org/msgid-search/?m=zeyj9uusax%2b%2fybg...@tuxteam.de > > That's not the same server side processing as in > https://lists.debian.org/ZEyj9UUSAx+/YbG/@tuxteam.de > Your URL submits a query where "+" and "/" are escaped. > Byung-Hee HWANG's URL uses "+" and "/" in the path component. That's my point exactly - either one escapes symbols in their URI, or it may not lead to the desired outcome. > Whatever, the List-Archive header in the resent mails of debian-user gives > bad URLs too. In my mailbox i find as example: > > List-Archive: > https://lists.debian.org/msgid-search/ZGCyEDFmig/oy...@eskimo.com That looks like an actual bug in mailman, which probably should be reported. > which does not lead to its intended target > https://lists.debian.org/debian-user/2023/05/msg00582.html Because it should not. This URL does not lead to /msgid-search, it leads to /msgid-search/ZGCyEDFmig. Reco
Re: OT: Mutt's Message-ID and web link
Hi. On Mon, May 29, 2023 at 03:13:00PM +0200, Thomas Schmitt wrote: > Byung-Hee HWANG wrote: > > https://lists.debian.org/ZEyj9UUSAx+/YbG/@tuxteam.de > > Maybe in Message-ID string, "/" seems trouble. Only if one's does not understand URLs. [1] works for me perfectly, for instance. > So the message id conforms to e-mail specs. But the list archive software > does not convert the message id into a usable URL. Last one is open to the discussion. Because if the form at [2] worked for you then the list archive software certainly *can* convert Message-ID to a usable URL. Reco [1] https://lists.debian.org/msgid-search/?m=zeyj9uusax%2b%2fybg...@tuxteam.de [2] https://lists.debian.org/msgid-search
Re: Strange locally-originating spam messages from sport.qc.ca
Hi. On Thu, Mar 30, 2023 at 12:19:24PM +0100, Julian Gilbey wrote: > The log seems quite unhelpful here, though I may be missing > something. Here is an example: I disagree. There's nothing to miss here, thus you're correct. > 2023-03-29 00:07:19 1phIPT-0047NQ-0H <= <> H=(LOCALHOSTNAME) [::1] P=smtp > S=2878 That, my friend, is a locally queued mail. I.e. some process on that very host connected to exim on tcp:25 on the same host and > 2023-03-29 00:07:19 1phIPT-0047NQ-0H ** frpjxbkek...@sport.qc.ca > R=nonlocal: Mailing to remote domains not supported tried to send a e-mail to that e-mail above. That exim is probably configured as "local" MTA, so it refused to send that e-mail. > It seems to have originated locally ([::1]), which is why I wonder > whether I've got a virus of some sort. "Virus" is such a harsh word. It's a malware, plain and simple. I suggest you to: 1) Poweroff problematic host ASAP. 2) Remove HDD from that host. 3) Attach the HDD to known clean host, preferably with a different CPU architecture, mount filesystems. 4) Check Debian software for validity (debsums -ac -r ...). 5) Check crontabs (both system and users'), double-check www-data crontab. 6) Check systemd timers, both system and users'. 7) Consider using very strict Apparmor policy for any LAN-facing services that you have there in the future (aa-genprof). > On my internet-facing host, these messages appear to originate from a > Canadian ISP, but I don't know whether to believe it, given what's > happening on my other machine. Be generous, ban whole AS of that ISP via iptables/nft first. Consider repeating the steps outlined above for internet-facing host too. Reco
Re: Strange locally-originating spam messages from sport.qc.ca
Hi. On Thu, Mar 30, 2023 at 09:30:49AM +0100, Julian Gilbey wrote: > I wonder if anyone has any idea about how to track this down? I'd check /var/log/exim4/mainlog first, obviously. For instance, your mail was sent to my MTA by bendel.d.o, as is should be: $ grep ZmNnhCgr7-N.A.uSE.A2UJkB /var/log/exim4/mainlog 2023-03-30 10:51:15 1pho03-QZ-9B <= bounce-debian-user=deb=enotuniq@lists.debian.org H=bendel.debian.org [82.195.75.100] P=esmtps X=TLS1.3:ECDHE_X25519__ECDSA_SECP384R1_SHA384__AES_256_GCM:256 CV=no S=5087 id=ZmNnhCgr7-N.A.uSE.A2UJkB@bendel Reco
Re: More RAID weirdness: external RAID over network
On Fri, Mar 17, 2023 at 03:46:54PM +0100, Nicolas George wrote: > Reco (12023-03-17): > > Yes, it will destroy the contents of the device, so backup > > No. If I accepted to have to rely on an extra copy of the data, I would > not be trying to do something complicated like that. Well, theoretically you can use Btrfs instead. I recall that there was some way to convert ext4 to btrfs without losing anything. Practically, friends do not let friends to use btrfs ;) Unless you're using SLES (*not* OpenSUSE), and do backups frequently, then it's kind of OK. In conclusion, implementing mdadm + iSCSI + ext4 would be probably the best way to achieve whatever you want to do. PS There's that old saying, "RAID is not a substitute for a backup". What you're trying to do sounds suspiciously similar to an old "RAID split-mirror" backup technique. Just saying. Reco
Re: More RAID weirdness: external RAID over network
Hi. On Fri, Mar 17, 2023 at 01:52:34PM +0100, Nicolas George wrote: > Reco (12023-03-17): > > - DRBD > > That looks interesting, with “meta-disk device”. > > > - MDADM + iSCSI > > Maybe possible, but not the way you suggest, see below. > > > - zpool attach/detach > > I do not think that is an option. Can you explain how you think it can > work? It's similar to MDADM, but with a small bonus and a pile of drawbacks on top of it. Create zpool from your device. Yes, it will destroy the contents of the device, so backup your files beforehand, and put them back after the creation of zpool. Use iSCSI/NBD/FCoE/NVMe (basically any network protocol that can provide a block device to another host) to make your zpool mirrored. This is done by zpool attach/detach commands. Small bonus that I've mentioned earlier is "zpool resilvering" (syncronization between mirror sides) concerns only actual data residing in a zpool. I.e. if you have 1Tb mirrored zpool which is filled to 200Gb you will resync 200Gb. In comparison, mdadm RAID resync will happily read 1Tb from one drive and write 1Tb to another *unless* you're using mdadm bitmaps. ZFS/ZPool drawbacks are numerous and well-documented, but I'll mention a single one - you do not fill your zpool to 100%. In fact, even 90% capacity of zpool usually equals trouble. > > > mdadm --create /dev/md0 --level=mirror --force --raid-devices=1 \ > > --metadata=1.0 /dev/local_dev missing > > > > --metadata=1.0 is highly important here, as it's one of the few mdadm > > metadata formats that keeps said metadata at the end of the device. > > Well, I am sorry to report that you did not read my message carefully > enough: keeping the metadata at the end of the device is no more an > option than keeping it at the beginning or in the middle: there is > already data everywhere on the device. Not unless you know the magic trick. See below. > Also, the mdadm command you just gave is pretty explicit that it will > wipe the local device. You mean, like this? # mdadm --create /dev/md127 --level=mirror --force --raid-devices=2 \ --metadata=1.0 /dev/loop0 missing mdadm: /dev/loop0 appears to contain an ext2fs file system size=1048512K mtime=Thu Jan 1 00:00:00 1970 Continue creating array? mdadm lies to you :) This is how it's done. # tune2fs -l /dev/loop0 | grep 'Block count' Block count: 262144 # resize2fs /dev/loop0 262128 resize2fs 1.46.2 (28-Feb-2021) Resizing the filesystem on /dev/loop0 to 262128 (4k) blocks. The filesystem on /dev/loop0 is now 262128 (4k) blocks long. # mdadm --create /dev/md127 --level=mirror --force --raid-devices=2 \ --metadata=1.0 /dev/loop0 missing mdadm: /dev/loop0 appears to contain an ext2fs file system size=1048512K mtime=Thu Jan 1 00:00:00 1970 Continue creating array? y mdadm: array /dev/md127 started. # fsck -f /dev/md127 fsck from util-linux 2.36.1 e2fsck 1.46.2 (28-Feb-2021) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/md127: 11/65536 files (0.0% non-contiguous), 12955/262128 block And the main beauty of it is that kernel will forbid you to run "resize2fs /dev/local_dev" as long as MD array is assembled, and "resize2fs /dev/md127" will take into the account that 16 4k blocks at the end. And I'm pretty sure you can reduce your filesystem by 16 4k blocks. That --metadata=1.0 is the main part of the trick. One can easily shrink the filesystem from its tail, but it's much harder to do the same from its head (which you'd have to do with --metadata=1.2). Reco
Re: More RAID weirdness: external RAID over network
Hi.
On Fri, Mar 17, 2023 at 11:09:09AM +0100, Nicolas George wrote:
> Is this possible: ?
Actually, there are at least three ways of doing it:
- DRBD
- MDADM + iSCSI
- zpool attach/detach
But DRBD was designed with continuous replication in mind, and ZFS has
severe processor architecture restrictions, and somewhat unusual design
decisions for the filesystem storage.
So let's keep it on MDADM + iSCSI for now.
> What I want to do:
>
> 1. Stop programs and umount /dev/something
>
> 2. mdadm --create /dev/md0 --level=mirror --force --raid-devices=1 \
> --metadata-file /data/raid_something /dev/something
a) Replace that with:
mdadm --create /dev/md0 --level=mirror --force --raid-devices=1 \
--metadata=1.0 /dev/local_dev missing
--metadata=1.0 is highly important here, as it's one of the few mdadm
metadata formats that keeps said metadata at the end of the device.
b) Nobody forbids you to run degraded RAID1 all the time. Saves you
unmounting and mounting again.
> → Now I have everything running again completely normally after a very
> short service interruption. But behind the scenes files operations go
> through /dev/md0 before reaching /dev/something. If I want to go back, I
> de-configure /dev/md0 and can start using /dev/something directly again.
>
> 4. mdadm --add /dev/md0 remote:/dev/something && mdadm --grow /dev/md0
> --raid-devices=2
And "remote:/dev/something" is merely "iscsiadm --mode node --targetname
xxx --portal remote --login".
Then add resulting block device as planned.
That assumes that "remote" runs configured iSCSI target ("tgt" in
current stable is perfectly fine for that), "local" can reach "remote"
via tcp:3260, and you do not care about data encryption for the data in
transmission.
Reco
Re: question on /var/run
Hi. On Thu, Mar 16, 2023 at 02:20:39AM +0800, cor...@free.fr wrote: > On 16/03/2023 02:08, Greg Wooledge wrote: > > On Thu, Mar 16, 2023 at 02:02:35AM +0800, cor...@free.fr wrote: > > > I am having the question that why the dir I created in /var/run disappears > > > after rebooting the system? how to prevent that? > > > > unicorn:~$ ls -ld /var/run > > lrwxrwxrwx 1 root root 4 Jan 11 2018 /var/run -> /run/ > > unicorn:~$ df /run > > Filesystem 1K-blocks Used Available Use% Mounted on > > tmpfs1215596 1928 1213668 1% /run > > > > Because /var/run is a symlink to /run which is a transient, in-memory > > file system not backed by permanent storage. > > > > Thanks greg. > > I have put these statement in @reboot crontab for auto startup. > > @reboot mkdir -p /var/run/xxx && chown -R www-data:www-data /var/run/xxx I'd use systemd-tmpfiles(8) for that. Just because you probably want that directory to exist before your webserver starts up and not in the arbitrary point in the future. Something like this should do it for you: cat > /etc/tmpfiles.d/xxx.conf << EOF d /run/xxx 0755 www-data www-data EOF Reco
Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
Hi. On Mon, Mar 13, 2023 at 08:53:35PM +0100, local10 wrote: > Mar 13, 2023, 12:06 by recovery...@enotuniq.net: > > > Looks correct, assuming that the contents of the key start with AwEAAaz > > and end with V74bU=. > > > > > > Look at /usr/share/dns/root.key. Compare its contents with > > /etc/bind/bind.keys. Replace the latter if needed. > > > > "dpkg-reconfigure -plow bind9" is probably more preferred way of doing > > it. > > > > They keys in the "/etc/bind/bind.keys" and "/usr/share/dns/root.key" are > identical: Well, it was worth to check it. Next idea is somewhat more complicated. Install tcpdump. Run: tcpdump -pni any -s0 -w /tmp/dns.pcap -c 30 udp port 53 or tcp port 53 Bounce BIND, wait for a minute at least. Do some DNS queries. One or two will do. Interrupt tcpdump unless it completes by itself. Post dns.pcap. Reco
Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
On Mon, Mar 13, 2023 at 12:29:44PM +0100, local10 wrote:
> Mar 13, 2023, 10:57 by recovery...@enotuniq.net:
>
> > And now to the serious stuff.
> >
> > First things first, the log.
> >
> > Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info:
> > client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com
> > <http://www.yahoo.com>): query:
> > www.yahoo.com <http://www.yahoo.com> IN A +E(0)K (127.0.0.1)
> > Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning:
> > managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
> >
> > The keyword here is not "managed-keys-zone", it's "dnssec".
> >
> > Second, to put it bluntly, if you force bind9 to do DNSSEC validation
> > (which is enabled by default), bind9 won't be able to lookup anything
> > unless it is trusting root DNSSEC key. Like, for your own security and
> > stuff :)
> >
> > Third, as every DNSSEC key, root zone keys have their expiration.
> > Meaning, you did not have to change anything to break your setup, every
> > time you deal with DNSSEC you're dealing with a ticking bomb anyway.
> >
> > Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data,
> > which should provide a current DNSSEC root key (KSK to be precise), but
> > bind9 could also take said key from /etc/bind/bind.keys.
> >
> >
> > In conclusion:
> >
> > 1) Check the contents of your /etc/bind/bind.keys, update if needed.
> > 2) Check the version of your dns-root-data, versions above and including
> > 2021011101 (aka ksk id 20326) are good.
> > 3) Set "dnssec-validation no;" at named.conf.options as a last resort.
> > 4) If you intend to troubleshoot DNS queries then consider installing
> > tcpdump. The thing helps.
>
>
> Very interesting, thanks. in the "bind.keys" I have only one entry:
>
> trust-anchors {
> # This key (20326) was published in the root zone in 2017.
> . initial-key 257 3 8 "";
> };
Looks correct, assuming that the contents of the key start with AwEAAaz
and end with V74bU=.
> But in "/etc/bind/named.conf.options" I have "dnssec-validation
> auto;", which, as I understand it should force bind to use the
> built-in root key, no?
Not exactly. "dnssec-validation auto;" should point BIND at
/etc/bind/bind.keys. And bind.keys should be created (or updated) by
debconf.
At least debconf did it for me back in 2021 during buster->bullseye
upgrade.
> Anyhow, how would I know if an update of /etc/bind/bind.keys is needed (it's
> not obvious just by looking at the key)
Obviously you cannot know that ;)
Luckily "Root KSK Rollovers", as they call it, are rare. Last one was in
2018, and the key (aka ksk id 20326) in question was released in 2017.
> and, if so, how do I update it?
Look at /usr/share/dns/root.key. Compare its contents with
/etc/bind/bind.keys. Replace the latter if needed.
"dpkg-reconfigure -plow bind9" is probably more preferred way of doing
it.
Reco
Re: BIND: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out
Hi. On Mon, Mar 13, 2023 at 10:57:48AM +0100, local10 wrote: > Mar 13, 2023, 09:32 by jer...@ardley.org: > > > My next best option is simply to remove your bind caching server (it sounds > > like it's not really necessary in your application) > > > > Backup /etc/bind and /var/cache/bind > > then > > systemctl remove bind9 > > systemctl purge bind9 LOL. > > And then edit /etc/resolv.conf to > > > > nameserver 8.8.8.8 > > nameserver 8.8.4.4 And redirect all your DNS queries to Google. I mean, people, if you suggest using a public DNS you could at least consider suggesting a privacy-respecting one, like 9.9.9.9. > Sure, I could have used some public DNS server and I may have to do that if I > can't get this issue resolved. Still, I'd like to understand why BIND > suddenly stopped working[1] for me and how to fix it. And now to the serious stuff. First things first, the log. Mar 13 05:03:18 tst named[52836]: 13-Mar-2023 05:03:18.963 queries: info: client @0x7f7812816d68 127.0.0.1#38800 (www.yahoo.com <http://www.yahoo.com>): query: www.yahoo.com <http://www.yahoo.com> IN A +E(0)K (127.0.0.1) Mar 13 05:03:21 tst named[52836]: 13-Mar-2023 05:03:21.631 dnssec: warning: managed-keys-zone: Unable to fetch DNSKEY set '.': timed out The keyword here is not "managed-keys-zone", it's "dnssec". Second, to put it bluntly, if you force bind9 to do DNSSEC validation (which is enabled by default), bind9 won't be able to lookup anything unless it is trusting root DNSSEC key. Like, for your own security and stuff :) Third, as every DNSSEC key, root zone keys have their expiration. Meaning, you did not have to change anything to break your setup, every time you deal with DNSSEC you're dealing with a ticking bomb anyway. Fourth, Debian packaging helpfully forces bind9 to depend on dns-root-data, which should provide a current DNSSEC root key (KSK to be precise), but bind9 could also take said key from /etc/bind/bind.keys. In conclusion: 1) Check the contents of your /etc/bind/bind.keys, update if needed. 2) Check the version of your dns-root-data, versions above and including 2021011101 (aka ksk id 20326) are good. 3) Set "dnssec-validation no;" at named.conf.options as a last resort. 4) If you intend to troubleshoot DNS queries then consider installing tcpdump. The thing helps. Reco
Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi. On Mon, Feb 27, 2023 at 10:53:24PM +0100, Geert Stappers wrote: > (Meanwhile solved with denyinterface in /etc/dhcpcd.conf) > > > > Long story short, consider running "systemctl mask dhcpcd" unless you > > need dhcpcd to work in a way described above. > > The laptop does need to have DHCP client. I see. Adding appropriate amount of "allowinterfaces" and "denyinterfaces" stanzas into dhcpcd.conf should solve it for you. > > Another possible workaround is to add "noipv4ll" to dhcpcd.conf, > > Not tried. It disallows dhcpcd to add IPv4LL address on any network interface. Reco
Re: MPV Player...
On Mon, Feb 27, 2023 at 07:14:25AM -0500, Greg Wooledge wrote: > On Mon, Feb 27, 2023 at 12:05:27PM +0300, Reco wrote: > > Hi. > > > > On Mon, Feb 27, 2023 at 12:40:39AM -0600, Lester Rees wrote: > > > I would like for MPV Player to be updated/upgraded because the newest > > > version uses yt-dlp instead of youtube-dl(more or less abandoned). > > > > apt install yt-dlp youtube-dl- > > ln -sf /usr/bin/yt-dlp /usr/local/bin/youtube-dl > > > > > > unicorn:~$ apt-cache show yt-dlp > N: Unable to locate package yt-dlp > E: No packages found > unicorn:~$ cat /etc/debian_version > 11.6 A valid point. $ apt policy yt-dlp yt-dlp: Installed: 2023.01.06-1~bpo11+1 Candidate: 2023.01.06-1~bpo11+1 Version table: *** 2023.01.06-1~bpo11+1 100 100 http://ftp.debian.org/debian bullseye-backports/main amd64 Packages Reco
Re: MPV Player...
Hi. On Mon, Feb 27, 2023 at 12:40:39AM -0600, Lester Rees wrote: > I would like for MPV Player to be updated/upgraded because the newest > version uses yt-dlp instead of youtube-dl(more or less abandoned). apt install yt-dlp youtube-dl- ln -sf /usr/bin/yt-dlp /usr/local/bin/youtube-dl Reco
Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi. On Sun, Feb 26, 2023 at 03:14:22PM +0100, Geert Stappers wrote: > Hi. > > On Sun, Feb 26, 2023 at 04:01:06PM +0300, Reco wrote: > > On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote: > > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired > > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25 > > > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address > > > fe80::56b2:83e1:5ceb:9d50 > > > ... > > > Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease > > > ... > > > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL > > > address > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address > > > 169.254.201.7 > > > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to > > > 169.254.0.0/16 > > > > Let's try a straightforward approach for starters: > > > > echo denyinterfaces ovs-system >> /etc/dhcpcd.conf > > > Yes, now no more route 169.254.0.0/16 for device ovs-system. > > And for the record: > * Package avahi-autoipd left removed > * Service avahi-daemon left disabled > * Socket avahi-daemon left disabled These have nothing to do with your problem. dhcpcd is the source of your problem, in a way. dhcpcd can run as a systemwide daemon, which tries to obtain DHCP lease on any network interface barring "lo". In stock configuration, dhcpcd will add IPv4LL (169.254/16) IP on a interface if it fails to obtain a lease after 60 second timeout (IIRC). And obviously you have no DHCP server on "ovs-system" :) Debian's packaging of dhcpcd should prevent the daemon to obtain DHCP lease on any interface that's listed in /etc/network/interfaces, but: 1) OVS bridge should not be listed there, it's dynamic by nature. 2) You're using Network Manager, so it's totally possible that you have an empty /etc/network/interfaces, or no such file at all. Long story short, consider running "systemctl mask dhcpcd" unless you need dhcpcd to work in a way described above. Another possible workaround is to add "noipv4ll" to dhcpcd.conf, but this could break something else in your setup. Reco
Re: CUPS - how to match autodetected printers to physical ones
Hi. On Sat, Feb 25, 2023 at 11:26:21PM +, Brian wrote: > > It's interesting how you bring up DHCP, yet do not mention DHCP option 9 > > (aka "option lpr-servers" in ISC lingo). > > A proper implementation of DHCP options would make DNS-SD (and other > > assorted kludges) completely redundant. > > But that would be in an ideal world, and in the real world DNS-SD > > serves its function (within its inherent limits of course). > > If it works, that is. > > If the IP address changes, ipp://10.76.172.100/ipp/print as a > URI becomes useless. DNS-SD ensures a reachable URI. Got it? There's no need to be rude. Leaving aside changing printer's IP (the main question here is why would anyone would do it), how exactly DNS-SD helped Greg to print in that environment? > > > It would also be hoped that port numbers and resource > > > paths are on the sheet of paper, otherwise a user will have a > > > lot of guessing to do. > > > > Nope. RTFM would suffice, as always. > > I do not think you understand my argument. A port for an IPP > printer need not be on 631 and the resource path need not be > ipp/print. RTFM hardly helps when there is an immediate need > to print. I wish you good luck in "convincing" typical dumb printer firmware in performing such feats. Bonus points for "convincing" enterprise-grade printer firmware to do the same. The main question here, of course, is why complicate things without the need? > RTFM? Which ones would you recommend? This one is good enough: https://www.pwg.org/ipp/ippguide.html > Actually, CUPS performed splendidly. If CUPS in that configuration did not allow a user to print certain amount of pages, then it cannot be called splendid. > The OP was on a badly set up, unco-operative network. That was (and > probably still is) the root of the issue. And here it's you who seem to misunderstand the issue. It's a city hall, or something like it. People come there, some are in the need of printing. We have a confirmed and documented case of CUPS failing to deliver the desired result (i.e. printing something) in that environment. Without additional user configuration, that is. Last time I've checked, they did not provide CUPS on any Android phone out of the box, and probably it's the same for Apple phones. It's likely that some visitor would bring a laptop with them, and it's likely that said laptop would run M$ Windoze (or whatever that shovelware is called these days). If mobile users or M$ laptop users would encounter any trouble printing - surely someone would make something to fix it. Yet is was not fixed (for a year at most), so it's likely *it works for the users*, so there's nothing to fix. Some user configuration on their device may be required, or not, it's not relevant here. Does that mean that CUPS is in need of fixing? Of course not. Does that mean that DNS-SD is not needed? Of course not. Does that mean that the only way of printing something via CUPS is to use DNS-SD? You can guess it, it's also not. Moreover, printing something at a city hall is a rare (although periodic) task. If the printer's IP changes between Greg's vistits there - so what? > > > How would an ordinary user go on? "Give them a piece of paper" sounds > > > awfully like "Let them eat cake". > > > > Easy, a user should RTFM. Failing that, a user can use a different > > device or OS, or *gasp* - just use ipptool. Given the environment, a > > creative use of samba suite would probably solve the problem too, but > > let's not get into *that*. > > And there's that last step - just ask somebody. > > You welcome Big Boss into your office for a $100M deal. Nope. Either it's the "ordinary user" or it's the "Big Boss". Please choose one. Reco
Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi. On Sun, Feb 26, 2023 at 12:18:52PM +0100, Geert Stappers wrote: > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: carrier acquired > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: IAID cb:93:09:25 > Feb 24 22:24:15 trancilo dhcpcd[1175]: ovs-system: adding address > fe80::56b2:83e1:5ceb:9d50 > ... > Feb 24 22:24:16 trancilo dhcpcd[1175]: ovs-system: soliciting a DHCP lease > ... > Feb 24 22:24:21 trancilo dhcpcd[1175]: ovs-system: probing for an IPv4LL > address > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: using IPv4LL address > 169.254.201.7 > Feb 24 22:24:26 trancilo dhcpcd[1175]: ovs-system: adding route to > 169.254.0.0/16 Let's try a straightforward approach for starters: echo denyinterfaces ovs-system >> /etc/dhcpcd.conf Reco
Re: stop mate weather app spamming syslog?
Hi. On Sun, Feb 26, 2023 at 07:00:34AM +0800, jeremy ardley wrote: > Any way to stop it? Or get syslog to send it to /dev/null ? Of course there is. cat > /etc/rsyslog.d/mateweather.conf << EOF if (\$syslogtag containts 'org.mate.panel.applet.MateWeatherAppletFactory') then stop EOF service rsyslog restart Reco
Re: CUPS - how to match autodetected printers to physical ones
On Sat, Feb 25, 2023 at 06:30:28PM +, Brian wrote: > On Sat 25 Feb 2023 at 17:44:15 +0300, Reco wrote: > > > Hi. > > > > On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote: > > > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote: > > > > Try this next time you're on site: > > > > > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere > > > > > > This worked. I printed two copies of the single-page PDF from Chrome > > > without any further problems. > > > > Just as planned. CUPS autodiscovery is only good for something if you > > don't know printer's real IP. This little episode shows us that nothing > > beats IP-on-sheet-of-paper discovery. > > 99% of users with tablets, smart phones, laptops etc would find > DNS-SD more to their liking, especially if DHCP assignment is > in place. It's interesting how you bring up DHCP, yet do not mention DHCP option 9 (aka "option lpr-servers" in ISC lingo). A proper implementation of DHCP options would make DNS-SD (and other assorted kludges) completely redundant. But that would be in an ideal world, and in the real world DNS-SD serves its function (within its inherent limits of course). If it works, that is. > It would also be hoped that port numbers and resource > paths are on the sheet of paper, otherwise a user will have a > lot of guessing to do. Nope. RTFM would suffice, as always. > In this thread we see how a very experienced user reacted to > being denied mdns multicasting. Allow me to quote that original e-mail for the sake of completeness: > So the printer WORKS. It is ON THE NETWORK. I can print TEXT to it > using port 9100. > > What I CANNOT do is find it in CUPS. Or avahi-browse, or driverless, or > any of these other commands that are so allegedly wonderful. > > Is there any way I can tell CUPS "Please set up a queue for a printer > whose IP address is 10.76.172.100 even though you can't discover it with > your fancy tools"? The way I see it, Greg wrote about a CUPS configuration problem. The solution of said problem was (and still is btw) at lpadmin(8). Of course, to know that the solution just lies there, waiting to be implemented, that requires one to have a knowledge of CUPS administration. Luckily we have debian-user for last one. > How would an ordinary user go on? "Give them a piece of paper" sounds > awfully like "Let them eat cake". Easy, a user should RTFM. Failing that, a user can use a different device or OS, or *gasp* - just use ipptool. Given the environment, a creative use of samba suite would probably solve the problem too, but let's not get into *that*. And there's that last step - just ask somebody. > > > I've gotta say, though, this option is a disaster: > > > > > > -E When specified before the -d, -p, or -x options, forces the use of > > > TLS encryption on the connection to the scheduler. Otherwise, > > > enables > > > the destination and accepts jobs; this is the same as running the > > > cupsaccept(8) and cupsenable(8) programs on the destination. > > > > > > Whoever decided to overload that option in that way... yikes. > > > > Back in the day Apple's slogan was "think different". The whole CUPS > > suite is a living proof of that. > > Wrong target! -E was there in its present form well before Apple > acquired CUPS. I stand corrected here. Reco
Re: CUPS - how to match autodetected printers to physical ones
Hi. On Fri, Feb 24, 2023 at 12:58:15PM -0500, Greg Wooledge wrote: > On Fri, Feb 17, 2023 at 05:35:11PM +0300, Reco wrote: > > Try this next time you're on site: > > > > lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere > > This worked. I printed two copies of the single-page PDF from Chrome > without any further problems. Just as planned. CUPS autodiscovery is only good for something if you don't know printer's real IP. This little episode shows us that nothing beats IP-on-sheet-of-paper discovery. > I've gotta say, though, this option is a disaster: > > -E When specified before the -d, -p, or -x options, forces the use of > TLS encryption on the connection to the scheduler. Otherwise, enables > the destination and accepts jobs; this is the same as running the > cupsaccept(8) and cupsenable(8) programs on the destination. > > Whoever decided to overload that option in that way... yikes. Back in the day Apple's slogan was "think different". The whole CUPS suite is a living proof of that. Reco
Re: Debugging what is deleting/recreating /etc/resolv.conf with wrong configuration, on debian stable
Hi.
On Thu, Feb 23, 2023 at 11:31:44AM +0100, daven...@tuxfamily.org wrote:
> > If it is DHCP: You might do a countermeasure in
> > /etc/dhcp/dhclient.conf. On my system I have an entry as below.
> >
> > interface "wlp4s0" {
> > supersede domain-name-servers 127.0.0.1;
>
> Unfortunately, I can't use supersede parameter because I need to use
> different resolvers at different times/in different contexts.
>
> I would need something more… conditional
>
> IF openconnect is running and has modified resolv.conf, leave that
> file alone unless you are openconnect Otherwise, when there's no VPN
> active, you can do normal DHCP requests and accept whatever
> currently-active network's router/DHCP tells you and update resolve
> conf accordingly
openconnect has that helpful --script option, which calls
/usr/share/vpnc-scripts/vpnc-script by default.
All you need is to make a copy of that script, modify dhclient.conf
at "connect" and "disconnect" phases accordingly, and then call your
modified script from openconnect.
Reco
Re: Remove route '169.254.0.0/16 dev ovs-system'
Hi. On Tue, Feb 21, 2023 at 06:44:38PM +0100, Christoph Brinkhaus wrote: > I have no idea if it is possible to estimate a DHCP response time. sudo nmap --script broadcast-dhcp-discover Reco
Re: CUPS - how to match autodetected printers to physical ones
Hi. On Thu, Feb 16, 2023 at 10:41:33AM -0500, Greg Wooledge wrote: > So the printer WORKS. It is ON THE NETWORK. I can print TEXT to it > using port 9100. > > What I CANNOT do is find it in CUPS. Or avahi-browse, or driverless, or > any of these other commands that are so allegedly wonderful. > > Is there any way I can tell CUPS "Please set up a queue for a printer > whose IP address is 10.76.172.100 even though you can't discover it with > your fancy tools"? Try this next time you're on site: lpadmin -p D14841 -E -v ipp://10.76.172.100/ipp/print -m everywhere Reco
Re: ps and AIX field descriptors
Hi.
On Fri, Feb 17, 2023 at 07:46:23AM +0100, Andreas Leha wrote:
> Now my question: How can I restore the previous behaviour that allowed
> other than whitespace separators between fields?
diff -purw procps-3.3.17/ps/sortformat.c procps-4.0.2/src/ps/sortformat.c
shows me that:
@@ -128,22 +127,24 @@ static const char *aix_format_parse(sf_n
items = 0;
walk = sfn->sf;
/* state machine */ {
- int c;
+ int c = *walk++;
initial:
-c = *walk++;
if(c=='%')goto get_desc;
if(!c)goto looks_ok;
/* get_text: */
items++;
- get_more_text:
+ get_more:
c = *walk++;
if(c=='%')goto get_desc;
-if(c) goto get_more_text;
+if(c==' ')goto get_more;
+if(c) goto aix_oops;
goto looks_ok;
get_desc:
items++;
c = *walk++;
-if(c) goto initial;
+if(c&!=' ') goto initial;
+return _("missing AIX field descriptor");
+ aix_oops:
return _("improper AIX field descriptor");
looks_ok:
;
If you look at "get_more" label, you'll notice that "old" version of
procps (bullseye's) checked for any character after "%" block.
"New" one (bookworm's) explicitly checks for space, and goes to
"aix_oops" in any other case.
And there is no #ifdefs, no environment variable checks, no options
etc.
So, to answer your question - currently the only way to restore the
behaviour you want is to patch procps and rebuild it.
Reco
Re: ipv6 maybe has arrived.
Hi. On Wed, Feb 15, 2023 at 07:30:44AM -0500, Greg Wooledge wrote: > That said, I'm curious about this part oF Gene's result: > > > > gene@bpi54:~$ grep -i bpi54 /etc/hosts > > > 192.168.71.12 bpi54.coyote.denbpi54 > > > gene@bpi54:~$ getent hosts bpi54 > > > fe80::4765:bca4:565d:3c6 bpi54 > > Where does getent pull that IPv6 address from? libnss-myhostname does that. Why it chooses ipv6 link-local over ipv4 static IP is another question. Much better question is - what exactly one should put into /etc/hosts so that it would be completely ignored? > That's not what I get when I look myself up: Maybe because *your* /etc/hosts is not malformed? Reco
Re: ipv6 maybe has arrived.
Hi. On Tue, Feb 14, 2023 at 01:32:37PM +0100, Nicolas George wrote: > Brian (12023-02-14): > > > FWIW, if you invoke lsusb with the -v option, you need > > > some superpowers. So better "sudo lsusb -v". > > I do not believe that to be the case. > > experiment > belief Indeed. lsusb -v >/dev/null sudo lsusb -v >/dev/null First one shows: "Couldn't open device, some information will be missing". Second one does not. Reco
Re: ipv6 maybe has arrived.
Hi. On Fri, Feb 10, 2023 at 08:04:38AM -0500, Greg Wooledge wrote: > On Fri, Feb 10, 2023 at 05:58:07AM -0500, gene heskett wrote: > > hosts: files mymachines dns myhostname > > This is wrong. You're correct, but for the wrong reason. > I don't know where you got it from, but "mymachines" > and "myhostname" are not valid entries in this file. On the contrary. apt show libnss-myhostname libnss-mymachines Why would anyone in their sane mind willingly install those is another question :) Reco
Re: unmask silently fails
Hi. On Mon, Sep 19, 2022 at 12:05:43AM -0400, Felix Miata wrote: > Anyone know what it takes to unmask nfs-common.service successfully? Why would you need it with systemd? As of bullseye, nfs-common package just provide this symlink instead of the proper systemd unit: # ls -la /lib/systemd/system/nfs-common.service lrwxrwxrwx 1 root root 9 Jun 28 2021 /lib/systemd/system/nfs-common.service -> /dev/null Reco
Re: headless server with console on USB port
On Thu, Aug 18, 2022 at 06:28:56PM +0200, Rainer Dorsch wrote: > Ah, I see, getting USB up early might be a problem. > > Would a native serial interface on a PCI card be a better solution? Same problem, different interface. You need UART that's soldered on the motherboard. Sadly, there's no substitutes to this. And if you really considering PCI-X card, I suggest buying something like [1]. [1] https://www.amazon.com/Dell-G8593-DRAC5-PCI-Controller/dp/B00450FDR6 Reco
Re: headless server with console on USB port
Hi. On Thu, Aug 18, 2022 at 04:48:34PM +0200, Rainer Dorsch wrote: > I am wondering if ready-made usb-to-usb solutions exist, which contain the > conversion to serial and back to usb internally I cannot call it "ready-made", but there's something similar - [1] which may solve your problems. It does not deal with serial per se, but achieves much more. Some assembly is required though. > or if there are a serial > crossover cable and two usb-to-serial adapters in some boxes in our cellar :-) That will work, I have similar setup back in the day. The main problems of such setup are: - overcomplicated setup of GRUB's USB stack. I.e. forget about seeing GRUB's menu. - unless you're using self-built Linux kernel - forget about seeing those boot messages. Because to convince the kernel to use that "console=ttyUSB0" argument you'll need to load an appropriate kernel module first. Such setup is good for saving you from the descent to the cellar in the case of occasional network misconfiguration, but that's about only problem it's good for. Hardware platforms with built-in UART are easier in this regard, but - it's very rare to have UART on a consumer-grade x86 motherboard. [1] https://github.com/Fmstrat/diy-ipmi Reco
Re: auth log full with
Hi. On Sun, Aug 14, 2022 at 04:07:03PM +0200, Matthias Böttcher wrote: > how do I block these ip ranges? The usual way. iptables -I INPUT -s -p tcp --dport 22 \ -m conntrack --ctstate NEW -j DROP or, if the source IP is an actual IPv6 (a rare thing in my experience): ip6tables -I INPUT -s -p tcp --dport 22 \ -m conntrack --ctstate NEW -j DROP Add your favorite way to persist these between host reboots, and you're set. > Which source can I use to determine the geo location of ip addresses? whois, geoiplookup, even https://bgp.he.net . Whatever works, basically. Last one is my favorite as it shows all IP blocks assigned to AS. Really helpful with spammer nests such as outlook.com (AS8075) or DigitalOcean (AS14061). > Is there a Debian packet? For the first two - sure. You'll need whois and geoip-bin. Installing iptables is assumed. Reco
Re: auth log full with
Hi. On Sun, Aug 14, 2022 at 09:16:25AM -0400, Stefan Monnier wrote: > > In fact, I'd restrict allowed SSH algorithms like this: > > > > Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com > > MACs > > hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com > > KexAlgorithms > > curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 > > Of course, if you do that, you'll want to make sure to revisit these > lists every couple of years :-( That goes without saying. Executing 'ssh -Q chiper' now and then is a good habit to have. Reco
Re: auth log full with
Hi. On Sun, Aug 14, 2022 at 08:57:47AM +0200, Maurizio Caloro wrote: > Thanks for you answer, yes add aggressive to mode, restart services and add > to ssh_config > > Host * > HostKeyAlgorithms +ssh-rsa,ssh-dss > PubkeyAcceptedKeyTypes +ssh-rsa,ssh-dss Please do not do this unless you're in a corporate environment. Basically you just allowed every SSH client made in last 25 years to connect to you. A very bad idea, to say the least. In fact, I'd restrict allowed SSH algorithms like this: Ciphers chacha20-poly1...@openssh.com,aes256-...@openssh.com MACs hmac-sha2-512-...@openssh.com,hmac-sha2-256-...@openssh.com,umac-128-...@openssh.com KexAlgorithms curve25519-sha...@libssh.org,diffie-hellman-group-exchange-sha256 Because it does not affect in any way proper OpenSSH users, and you'll probably want all those annoying bots to fail to connect. Windows users will suffer, but that's their fate anyway :) > But still auth logs everysecond with: > > Aug 14 08:53:20 lenovo sshd[270588]: Unable to negotiate with 80.92.231.239 > port 38675: no matching host key type found. Their offer: > ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ecdsa-sha2-nistp > 256-cert-...@openssh.com,ecdsa-sha2-nistp384-cert-...@openssh.com,ecdsa-sha2 > -nistp521-cert-...@openssh.com,ssh-rsa,ssh-dss [preauth] And that shows us that either fail2ban is not suitable for such messages (which is strange, fail2ban's sshd.conf contains appopriate regexes), or maybe you did not restart fail2ban. Personally I don't use fail2ban for sshd. Because why bother with userspace (written in python too, yuck) if the kernel does the same job? I.e. block M$ AS, China Telecom AS and maybe add Eastern Europe to the mix, and you've just reduced the number of offending logins by two orders of magnitude. Reco
Re: auth log full with
Hi. On Sat, Aug 13, 2022 at 07:42:28PM +0200, Maurizio Caloro wrote: > how I can disable this?, I try solution with failban, but this want be > help!? > > [sshd] > Enable = true > Mode = normal As /etc/fail2ban/filter.d/sshd.conf shows, "no matching host key type" messages are specifically ignored by Mode=normal. Try setting Mode=aggressive, it should catch those. Of course, DROPping ssh connections from AS28594 would work too. Unless you're from Brazil, that is. Reco
Re: dynupdater not seeming to do anything
Hi. On Mon, Aug 01, 2022 at 06:50:27AM +0200, to...@tuxteam.de wrote: > On Sun, Jul 31, 2022 at 02:16:30PM -0500, David Wright wrote: > > On Sun 31 Jul 2022 at 06:28:18 (-0700), Paul Scott wrote: > > > On 7/31/22 04:50, Curt wrote: > > > > On 2022-07-31, wrote: > > > > > > Doesn't it seem from the OP that the daemon doesn't > > > > > > start? > > > > > I interpret the process list in the original post as showing a > > > > > running dyn_updater: > > > > > > > > > > > ps ax |grep dyn > > > > > > 5237 ? Sl 170:43 dyn_updater > > > > > > 5269 ? Sl 5:38 /usr/bin/dyn_updater --daemon start > > > > > > 719685 pts/2 R+ 0:00 grep dyn > > > > > > You're right. I misread all that somehow. Documentation is > > > > infuriatingly sparse, but mentions that the app's ( a *GUI* app) actvity > > > > is logged to a file. Maybe the OP (who's disappeared anyway, as they > > > > often do) should look there. > > > > > > I haven't disappeared. We're probably in different time zones and > > > have different sleep schedules. > > > > > > I don't know about the GUI part of dyn_updater. It just site in my > > > task bar and doesn't do anything when I click it. > > > > I'm just intrigued by how expensive dyn_updater is to run. Admittedly, > > the machine has been up long enough to churn through 719685 processes, > > but almost three hours CPU time to tell a daemon to spend five seconds > > doing something; is everything OK? > > It seems to be from Oracle [1]. Possibly a Java abomination. Nope. It's CPython + QT. But then again, it's totally possible to write in Python in such way that users will think it's written in Java :) The package they provide embeds its own copy of libssl (version 1.0 with multiple known vulnerabilities), QT 4 (ditto), and libpython3 (version 3.3, ditto) so I would advise against using this particular utility for any reason. Reco
Re: odbc_config missing
On Wed, Jul 20, 2022 at 12:41:03PM -0500, Igor Korot wrote: > Hi, > > On Wed, Jul 20, 2022 at 12:09 PM Reco wrote: > > > > Hi. > > > > On Wed, Jul 20, 2022 at 10:40:45AM -0500, Igor Korot wrote: > > > I tried to run > > > > > > pkg-config --libs unixodbc > > > > > > and it fails. > > > > apt install unixodbc-dev > > It is installed and its the latest version... I see the problem. What you should actually execute is: pkg-config --libs odbc Or maybe: pkg-config --libs odbcinst I'm not that familiar with ODBC to know the difference between those. Reco
Re: odbc_config missing
Hi. On Wed, Jul 20, 2022 at 10:40:45AM -0500, Igor Korot wrote: > I tried to run > > pkg-config --libs unixodbc > > and it fails. apt install unixodbc-dev Reco
Re: which X11 app can show wifi info
On Wed, Jun 15, 2022 at 11:33:00AM +0200, Vincent Lefevre wrote: > On 2022-06-15 09:43:50 +0300, Reco wrote: > > Hi. > > > > On Wed, Jun 15, 2022 at 03:30:53AM +0200, Vincent Lefevre wrote: > > > On 2022-06-14 15:43:40 +0100, Brian wrote: > > > > On Tue 14 Jun 2022 at 13:15:56 +0200, Vincent Lefevre wrote: > > > > > No issues with iwlist and nmcli. > > > > > > > > /usr/sbin/wpa_gui and /sbin/wpa_cli should both give sensible outputs > > > > when run as root. > > > > > > For security reasons, I don't want to run them as root. > > > > First example they provide in wpa_supplicant.conf(5) shows the way to > > use wpa_cli sensibly without being root. > > One just needs to define a group for wpa_supplicant's control socket, like > > this: > > > > ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev > > This is either overkill (with a security risk, e.g. if this can allow > the user to become root), It cannot allow that, barring the security bugs in wpa_supplicant. It does give the user full control over a wpa_supplicant process though (i.e. associate with arbitrary AP, terminate the process, etc). > or Debian should have done that by default. That's my option too, but wpasupplicant package does not provide wpa_supplicant.conf by default. README.Debian should mention that bit of configuration probably. > > > The iwlist and nmcli utilities don't need root to work correctly. > > > > I don't know about iwlist, but nmcli uses dbus to communicate with > > NetworkManager. From the security standpoint, such approach clearly > > loses to the simple unix socket communication restricted by natural > > POSIX permissions. > > Actually, that's iwconfig that gives interesting information, such > as the current ESSID, and it doesn't need to be run as root either. So is "iw dev ... info", which uses "modern" communication via AF_NETLINK socket. Reco
Re: which X11 app can show wifi info
Hi. On Wed, Jun 15, 2022 at 03:30:53AM +0200, Vincent Lefevre wrote: > On 2022-06-14 15:43:40 +0100, Brian wrote: > > On Tue 14 Jun 2022 at 13:15:56 +0200, Vincent Lefevre wrote: > > > No issues with iwlist and nmcli. > > > > /usr/sbin/wpa_gui and /sbin/wpa_cli should both give sensible outputs > > when run as root. > > For security reasons, I don't want to run them as root. First example they provide in wpa_supplicant.conf(5) shows the way to use wpa_cli sensibly without being root. One just needs to define a group for wpa_supplicant's control socket, like this: ctrl_interface=DIR=/run/wpa_supplicant GROUP=netdev Add a user to a netdev group and you're set. > The iwlist and nmcli utilities don't need root to work correctly. I don't know about iwlist, but nmcli uses dbus to communicate with NetworkManager. From the security standpoint, such approach clearly loses to the simple unix socket communication restricted by natural POSIX permissions. Reco
Re: Hibernate filled my /root
Hi. On Thu, May 26, 2022 at 08:13:39AM -0700, Peter Ehlert wrote: > /var/log now contains 29.3 GB > /var/log/syslog 10.0 GB > /var/log/kern.log 10.0 GB > /var/log/syslog.1 4.1 GB > /var/log/kern.log.1 4.0 GB That's impressive, to say the least. > I have no clue why this happened The usual thing. Judging from the size of the kern.log, some kernel subsystem decided to generate a lot of messages, systemd-journald happily forwarded them to rsyslogd, and the latter wrote them. > how do I clean this up and prevent it from happening again? 1) Read the logs, understand what kind of messages are most frequent. 2) Purge the logs, i.e. :> /var/log/syslog :> /var/log/kern.log 3) Write appropriate rsyslogd filter rule, restart rsyslog afterwards For instance: :msg, contains, "eth0: renamed from " stop Note that you cannot filter messages at systemd-journald level, that sorry excuse for a "system journal" lack that capability. Reco
Re: Permanent email address?
Hi. On Sun, May 15, 2022 at 10:08:57AM -0400, rhkra...@gmail.com wrote: > My understanding is that the (only?) way to do get such a permanent address > is > to have my own domain and assign an email address in that domain to me? If you have to be in control over sending and receiving e-mail you'll need your own MTA. That implies a domain you control. > Also, iiuc, I cannot move my gmail address to some other provider? You cannot. But Google is merely following a common practice here, i.e. I know nobody in that market that can provide such a service for you. You can buy a domain and use Google MTAs to serve e-mails for it, but you cannot transfer it anywhere. I.e. you can change DNS records, run a different MTA, but you'll lose your mail at Google. > I'm also aware that there are some, iiuc, "free" top level domains -- I > vaguely remember an announcement some years ago, .xxx sticks in my mind as > one > of them That one is usually associated with pr0n. Conversing with a "permanent e-mail" in such domain is probably not the best idea. > -- ahh, maybe not, but I can't remember the others -- is .name one of > them? In a way, yes. .name domain will still cost you about $5 per year, $10 at max. But then .net domain will cost you about the same (it does for me, at least), and .net is more popular. > (I was going to send that longer post to the list seeking confirmation on the > various things I think I learned (or assumed), and I may do that later (and > consider adding it to my wiki) just for education and posterity.) IMO you're trying to solve a simple problem the hard way. Rent yourself a VPS, buy a domain, set up MTA and some kind of IMAP/POP server. It's not that hard if you're going to use it for yourself only. Reco
Re: macchanger - is it still working?
Hi.
On Sun, Apr 24, 2022 at 03:23:55PM +0200, Hans wrote:
> I rechecked, and everything is set as YES.
And that's the source of your problem, believe it or not.
Because what /etc/macchanger/ifupdown.sh does is it explicitly checks
for "true" value:
if [ "$ENABLE_ON_POST_UP_DOWN" != "true" ]; then
echo "disabled in /etc/default/${package}" >> $LOGFILE
exit
fi
Anything else, be it "TRUE", "YES" or "y" is considered "disabled" by
that check.
Now if "YES" appeared in /etc/default/macchanger by means of running
debconf - that's a bug in the package. Either debconf template or
ifupdown.sh should be changed to account that "YES" value.
But does systemd affects the package somehow - no, it does not.
Reco
Re: macchanger - is it still working?
Hi. On Sun, Apr 24, 2022 at 02:34:44PM +0200, Hans wrote: > I discovered, that macchanger does not change my mac-adresses at every > boot, like the installation promised. Because that's disabled by default. > So I looked around and I found some explanations in an Ubuntu forum. > This is tellingm, I need to add a systemd.service, so that this is > executed at every boot: > https://www.linuxuprising.com/2018/05/how-to-permanently-change-mac-address.html > > Of course, I could do so. This link only shows us that if the only thing one has is systemd then everything will look as a systemd unit. An interesting approach to the unit template though. > However, if this is changed, because Debian is using systemd now, and > macchanger is not adapted to this changes of Debian, should I file a > bugreport? Of course not. What you should probably do is to enable changing MACs in /etc/default/macchanger. And probably look at /etc/macchanger/ifupdown.sh for the implementation details. Doing the same thing with systemd would take a drastically different approach, involving creation of .link files. Reco
Re: disable IPv6 debian
Hi, please do not top-post. On Fri, Apr 15, 2022 at 08:35:33PM +0800, wilson wrote: > Reco wrote: > > The most non-intrusive way of doing it (side effects considered) is: > > > > /sbin/sysctl -w net.ipv6.conf.default.disable_ipv6=1 > > /sbin/sysctl -w net.ipv6.conf.lo.disable_ipv6=0 > > after doing this, do I need to restart the OS? No, you do not need to reboot. Moreover, those sysctls are non-persistent, and that's intentional. If you need to persist those settings, you'll need to modify /etc/sysctl.conf or create a new file in /etc/sysctl.d. Please consider reading sysctl.conf(5) *before* you touch those. Reco
Re: disable IPv6 debian
Hi. On Fri, Apr 15, 2022 at 07:32:01PM +0800, wilson wrote: > What's the good way to disable IPv6 in a debian system? The most non-intrusive way of doing it (side effects considered) is: /sbin/sysctl -w net.ipv6.conf.default.disable_ipv6=1 /sbin/sysctl -w net.ipv6.conf.lo.disable_ipv6=0 Reco
Re: networking.service fails
Hi. On Mon, Apr 11, 2022 at 01:48:35AM +0200, Dmitry Katsubo wrote: > The configuration is trivial: it adds both eth0 eth1 to the bridge > br0. > > === cut /etc/network/interfaces === > auto lo > auto eth0 > auto eth1 > > iface lo inet loopback > > auto br0 > iface br0 inet static > address 10.0.1.100 > gateway 10.0.1.1 > netmask 255.0.0.0 > bridge_ports eth0 eth1 > bridge_maxwait 60 > === cut === Good news - it explains "ifup: unknown interface eth0" messages. Bad news - this /e/n/i is not valid. The reason being - both eth0 and eth1 lack interface definitions, i.e. have no "iface" stanzas. If you absolutely need both eth0 and eth1 in the UP state by the time you create and bring up br0 you should either: 1) Define both eth0 and eth1 in /e/n/i like this: auto eth0 iface eth0 inet manual auto eth1 iface eth1 inet manual auto br0 iface br0 inet static address 10.0.1.100 gateway 10.0.1.1 netmask 255.0.0.0 bridge_ports eth0 eth1 bridge_maxwait 60 2) Use pre-up and post-down hooks for br0, and remove both "auto eth0" and "auto eth1": auto br0 iface br0 inet static address 10.0.1.100 gateway 10.0.1.1 netmask 255.0.0.0 bridge_ports eth0 eth1 bridge_maxwait 60 pre-up /sbin/ip link set eth0 up pre-up /sbin/ip link set eth1 up post-down /sbin/ip link set eth0 down post-down /sbin/ip link set eth1 down Reco
Re: networking.service fails
Hi.
It's pretty straightforward.
On Mon, Apr 04, 2022 at 02:38:39AM +0200, Dmitry Katsubo wrote:
> Dear Debian community,
First we have this - don't be confused by the "kernel's" timestamps,
systemd likes to add its own messages into the kernel's ringbuffer:
> Apr 4 00:37:28 debian kernel: [ 10.804450] r8169 :02:00.0 eth0:
> renamed from enp2s0
> Apr 4 00:37:28 debian kernel: [ 10.825386] r8169 :03:00.0 eth1:
> renamed from enp3s0
> Apr 4 00:37:28 debian kernel: [ 1.082558] r8169 :03:00.0 eth1:
> RTL8168g/8111g, 00:17:20:53:44:58, XID 4c0, IRQ 32
> Apr 4 00:37:28 debian kernel: [ 1.082560] r8169 :03:00.0 eth1: jumbo
> features [frames: 9194 bytes, tx checksumming: ko]
> Apr 4 00:37:28 debian kernel: [ 1.083615] r8169 :02:00.0 enp2s0:
> renamed from eth0
> Apr 4 00:37:28 debian kernel: [ 1.108937] r8169 :03:00.0 enp3s0:
> renamed from eth1
And next we see this:
> # ifdown -a --force; ifup -a -v
...
> ifup: unknown interface eth0
> ifup: unknown interface eth1
> Well, I use eth0/eth1 as I have renamed them from predictable network names
> via /etc/udev/rules.d/70-persistent-net.rules:
>
> ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:17:e8:92:b7:77",
> KERNEL=="eth*", NAME="eth0"
> ACTION=="add", SUBSYSTEM=="net", ATTR{address}=="00:17:20:53:44:58",
> KERNEL=="eth*", NAME="eth1"
As /var/log/messages helpfully show, your udev rules work.
The problem is, next thing udev does is renaming your network interfaces
back to (Un)Predictable Naming™ scheme.
Thus whatever stanzas you have in your interfaces(5) about eth0 and eth1
fail, thus the whole networking.service fails.
The conclusion is simple too:
1) Remove 70-persistent-net.rules, it's not doing what it should anyway.
2) Either use (Un)Predictable Network names in your interfaces, such as
enp2s0 and enp3s0.
3) Or use systemd network link files to rename network interfaces.
4) Or add "net.ifnames=0" to kernel's cmdline, as others suggested.
Reco
Re: ntp & ntpsec headless installation issues in Debian 11 (bullseye)
On Tue, Mar 22, 2022 at 03:08:31AM -0700, jaikuma...@gmail.com wrote: > On Tuesday, March 22, 2022 at 3:30:07 PM UTC+5:30, Reco wrote: > > Debian-installer is forbidden to remove installed packages by default. > > Hence the message: > > Mar 22 07:35:57 in-target: E: Packages need to be removed but remove is > > disabled. > Understood, then (if you know) what it is the way forward to install either > implementation i.e. ntp or ntpsec in a headless way? > Thank you. 1) Make preseed.cfg, pass it to the installer as specified at [1]. 2) Add something like this into pressed.cfg: preseed/late_command="in-target apt-get install -y ntpsec" 3) Run the installer. Reco [1] https://www.debian.org/releases/stable/amd64/apbs02
Re: ntp & ntpsec headless installation issues in Debian 11 (bullseye)
On Tue, Mar 22, 2022 at 02:07:54AM -0700, jaikuma...@gmail.com wrote: > On Tuesday, March 22, 2022 at 2:10:05 PM UTC+5:30, Reco wrote: > > Thanks for quick reply :) > > Choose one NTP implementation, install it. > > If you need it to act as an NTP server - change an appropriate > > configuration file. > Yes, that is what I mentioned - any of the implemention (ntp or ntpsec) > giving me the same behaviour in headless installation, also i'm not > triggering installation of 'systemd-timesyncd' at all, how come this is > getting installed and giving error in the log? :) Debian-installer is forbidden to remove installed packages by default. Hence the message: Mar 22 07:35:57 in-target: E: Packages need to be removed but remove is disabled. Reco
Re: ntp & ntpsec headless installation issues in Debian 11 (bullseye)
Hi. On Tue, Mar 22, 2022 at 01:42:28PM +0530, Jaikumar Sharma wrote: > It seems at first sight that systemd-timesyncd is default date/time > synchronization tool but it may act as full fledged NTP server? No. It can act as an NTP client only. > How to handle 'ntp' or 'ntpsec' headless installation? Choose one NTP implementation, install it. If you need it to act as an NTP server - change an appropriate configuration file. > and what are the reasons for this behaviour? It makes little sense to have two or more NTP clients installed on the same host. Thus installing one should uninstall others. Reco
Re: OT EU-based Cloud Service
Hi. On Fri, Mar 18, 2022 at 04:37:28PM +0900, Byung-Hee HWANG wrote: > Very long time i did googling for searching EU-based Cloud Service. But > i did fail. So i ask here Debian users. Because here Debian users looks > like to know good place, EU-based Cloud. > > Actually i'm willing to pay about 5€ for the my plan. https://hetzner.cloud German company, a single VPS cost is about 5€ per month. Reco
Re: getting a regular user to dump core when a program crashes
Hi. On Mon, Feb 28, 2022 at 11:41:27AM -0500, The Wanderer wrote: > On 2022-02-28 at 11:35, Greg Wooledge wrote: > > > On Mon, Feb 28, 2022 at 11:25:13AM -0500, songbird wrote: > > > >> >> me@ant(14)~$ ulimit -a > >> >> real-time non-blocking time (microseconds, -R) unlimited > >> >> core file size (blocks, -c) unlimited > >> > >> i had accomplished the ulimit change already, but the lack of > >> the proper permission on the output directory meant that a core > >> file would not be generated. > > > > What is an "output directory"? Core files are dumped in the process's > > *working* directory, which is "where you are when you run it". > > By default, yes, that's the case. However, from songbird's original > post: > > >>>> i have the following set in my /etc/sysctl.conf: > >>>> > >>>> # core file location and file name format > >>>> kernel.core_pattern=/crash/core.%u.%E.%p > > That appears to be a kernel parameter which defines the path and > filename of the core file. It can do that too. Quoting the relevant part of the kernel's documentation (admin-guide/sysctl/kernel.rst.gz) : If the first character of the pattern is a '|', the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file. For instance, one can use systemd-coredump (needs a package installed, though) to write backtraces to journald. Or, one can specify /dev/null in kernel.core_pattern, thus preventing core dumps from creating regardless of user's shell limits. > and that the syntax of the kernel parameter in question is > such that you have to specify the full path to the file. When used in such way, it's also prevents user's processes to spam an entire filesystem with coredumps. Reco
Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?
Hi. On Tue, Feb 22, 2022 at 10:56:43AM -0600, Nicholas Geovanis wrote: > > It's possible, of course. What's also possible is card's EEPROM may have > > gone haywire. I had a similar problem back in the day with rtl8139 NIC, > > IIRC. One day the thing simply started to assign itself a random MAC > > (but worked in every other regard), and since the thing was a part of > > the motherboard - I had to try almost every workaround in the existence. > > > > And you checked to make certain that really really really no firmware > upgrades took place in the meantime? Of course I'm sure. I'd remember rewriting card's EEPROM. That NIC had only built-in impossible to upgrade firmware, just in case. And in the grand scheme of things ever-changing MAC was a nuisance, not a problem. Changing the MAC on boot was a klugde, but it worked. > Or downgrades? See above. > Not even from some dual-booted OS on the same box? I don't do dual-boot for last 20 years at least. Dual-boot may be useful to someone, but I have no need of it. Besides, I don't own that hardware anymore. Unless I'm mistaken, it was "retired" to a nearest garbage dump. Reco
Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?
Hi.
On Sun, Feb 20, 2022 at 05:30:10PM -0600, Flacusbigotis wrote:
> On Thu, Feb 17, 2022 at 1:06 AM Reco wrote:
> > On Thu, Feb 17, 2022 at 12:32:48AM -0600, Flacusbigotis wrote:
> > > Thanks Reco & Greg. I did see the
> > > /lib/systemd/network/73-usb-net-by-mac.link file. Thanks for that.
> > >
> > > I don't know exactly what is happening, but the MAC address of the device
> > > keeps changing after an ifdown/ifup cycle post boot.
> >
> > You should've said that first.
> >
>
> I only found that out later after the 1st post :-)
:)
> > If the MAC address of the NIC is not persistent, that means udev will
> > provide you with different interface name each time you boot.
> > That means that you've hit yet another case of unpredictability of so
> > called Predictable Network Interface Names.
> >
> I did not have this problem in Debian 10. I do not know if the card's
> driver has changed between the two versions of Debian, so I am going to
> boot into a Debian 10 live image and see if it displays the same behavior.
It's possible, of course. What's also possible is card's EEPROM may have
gone haywire. I had a similar problem back in the day with rtl8139 NIC,
IIRC. One day the thing simply started to assign itself a random MAC
(but worked in every other regard), and since the thing was a part of
the motherboard - I had to try almost every workaround in the existence.
> If the drivers are the same then the issue was probably introduced by the
> changes made to start using ".link" vs .rules" files.
".link" and ".rules" are merely means to configure udev, they mean
nothing to the kernel. By default udev should not randomize NIC's MAC.
> > > I also tried adding a udev file (/etc/udev/rules.d/99_fix_usb.rules) with
> > > the following content to try to force the addr_assign_type to 0, but this
> > > did nothing:
> > >
> > > SUBSYSTEMS=="usb", SUBSYSTEM=="net", ATTR{addr_assign_type}="0"
> >
> > Try this:
> >
> > 1) Create a file called /etc/systemd/network/00-usb.link with the following
> > contents:
> >
> > [Match]
> > Driver=ax88179_178a
> >
> > [Link]
> > MACAddressPolicy=none
> > NamePolicy=kernel
> >
> > You may have to create an appropriate directory, and the file name has
> > to start with double zeroes.
> >
> > 2) Invoke (really needed):
> >
> > update-initramfs -k all -u
> >
> > 3) Reboot.
> >
> > 4) Watch your network interface is called usb0 from now then.
> >
> > Thanks!
You're welcome.
> > Now, this approach has its caveats, so:
> >
> > 1) If you ever plug-in two USB devices that both served with
> > "ax88179_178a" - you won't be able to distinguish between them. They
> > will be called usb0, usb1, etc without any meaningful order.
> >
> > Ugghhh.. I am not entirely comfortable with that.
>
>
> > 2) If they decide to rename "ax88179_178a" in the kernel - this link
> > file will cease to work for obvious reasons.
> >
> > Also not comfortable with this.
>
> I'll first check if I can replicate the behavior in Buster.
IIRC in Buster .link files are ignored if 73-usb-net-by-mac.rules apply
to the NIC. But you can cheat it by creating an empty file called:
/etc/udev/rules.d/73-usb-net-by-mac.rules
Reco
Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?
Hi.
On Thu, Feb 17, 2022 at 12:32:48AM -0600, Flacusbigotis wrote:
> Thanks Reco & Greg. I did see the
> /lib/systemd/network/73-usb-net-by-mac.link file. Thanks for that.
>
> I don't know exactly what is happening, but the MAC address of the device
> keeps changing after an ifdown/ifup cycle post boot.
You should've said that first.
If the MAC address of the NIC is not persistent, that means udev will
provide you with different interface name each time you boot.
That means that you've hit yet another case of unpredictability of so
called Predictable Network Interface Names.
> I also tried adding a udev file (/etc/udev/rules.d/99_fix_usb.rules) with
> the following content to try to force the addr_assign_type to 0, but this
> did nothing:
>
> SUBSYSTEMS=="usb", SUBSYSTEM=="net", ATTR{addr_assign_type}="0"
Try this:
1) Create a file called /etc/systemd/network/00-usb.link with the following
contents:
[Match]
Driver=ax88179_178a
[Link]
MACAddressPolicy=none
NamePolicy=kernel
You may have to create an appropriate directory, and the file name has
to start with double zeroes.
2) Invoke (really needed):
update-initramfs -k all -u
3) Reboot.
4) Watch your network interface is called usb0 from now then.
Now, this approach has its caveats, so:
1) If you ever plug-in two USB devices that both served with
"ax88179_178a" - you won't be able to distinguish between them. They
will be called usb0, usb1, etc without any meaningful order.
2) If they decide to rename "ax88179_178a" in the kernel - this link
file will cease to work for obvious reasons.
Reco
Re: 73-usb-net-by-mac.rules is no longer used in Bullseye for USB ethernet devices?
Hi. On Wed, Feb 16, 2022 at 03:55:21AM -0600, Flacusbigotis wrote: > Back in Debian Buster, I learned that the "predictive" naming of this USB > ethernet interface would be governed by "73-usb-net-by-mac.rules" and so I > had it configured accordingly with a config file in > /etc/network/interfaces.d/... Namely that the device name would basically > be its MAC. It's still true in Bullseye, but the implementation has changed somewhat. Instead of /lib/udev/rules.d/73-usb-net-by-mac.rules now systemd uses /lib/systemd/network/73-usb-net-by-mac.link. > Well, I just upgraded to Bullseye, and I can't bring up the darn > interface. I have tried fiddling around with the device name in my config > file in /etc/network/interfaces.d/ directory, but it just won't come up. > The Networking.service also fails during bootup. A straightforward approach would be to learn the actual name of the device via "ip a"/"ifconfig -a", and then using that name in /e/n/i. > Anyone know how the heck this is supposed to work in Bullseye? systemd.link(5), systemd.net-naming-scheme(7). The keyword you need is NamePolicy=mac. > BTW, the device shows up as disabled in lshw (I obfuscated the MAC in the > output): > > *-network DISABLED That could mean anything. Please show the output of "ip a". Reco
Re: systemd/dhcp v. ntpd
On Wed, Feb 09, 2022 at 10:49:34AM -0500, Lee wrote: > >> My first thought was telling the machine to ignore the NTP server > >> address handed out via DHCP. Maybe there's a way to do that, but I > >> couldn't figure out how :( > > > > supercede ntp-servers "..." in dhclient.conf should do it for you. > > > > The option was helpfully provided by dhclient.conf(5). > > I tried not giving it a value - ie > supersede ntp-servers ; > > didn't work. Apparently one _has_ to give it a value. Yup. But you know which NTP servers you want this host to use, do you? > >> >> I tried changing /etc/dhcp/dhclient.conf to request just > >> >> request subnet-mask, broadcast-address, routers, > >> >> interface-mtu, > >> >> rfc3442-classless-static-routes ; > >> >> > >> >> and systemd still restarted ntpd with only the dhcp supplied ntp > >> >> server address ... which is this machine, so all the configured ntp > >> >> servers went away :( > > > > And that merely stopped dhclient from asking DHCP server to provide > > "ntp-server" option. What it cannot stop is DHCP server providing > > "ntp-server" option anyway. > > > > ISC dhclient simply lacks the option to ignore certain options in DHCP > > reply. It can supercede them though. > > The way I read the man page, supercede requires a value. One can say that too. > I can't just say ignore what the DHCP server gives me, I have to say > use instead of what the DHCP server gives me ... and there is > no value, it's several pool & server lines that I don't want > replaced. Changing DHCP client is an option too. > >> >> I then tried telling network manager to just get an ip address & > >> >> subnet mask from dhcp. And still systemd fucked up the ntpd config > >> >> > >> >> What finally worked was editing /usr/lib/ntp/ntp-systemd-wrapper to > >> >> remove ' NTPD_OPTS="$NTPD_OPTS -u $UGID" ' > >> > > >> > Huh? You're saying that removing the "-u $UGID" option made it "work"? > >> > And that it "didn't work" with -u being passed? > > > > Changing the contents of /etc/dhcp/dhclient-exit-hooks.d/ntp would make > > it more friendly for the purpose of the future updates. > > Changing it or moving it to another, clearly not supposed to be > invoked, directory? Removing this hook should be sufficient. Even better - add "exit 0" to the beginning. Reco
Re: systemd/dhcp v. ntpd
On Wed, Feb 09, 2022 at 11:00:14AM -0500, Lee wrote: > Any idea what the chances are of getting an enhancement request for > the dhcp client to add an > ignore option; > that says not use the option given by the dhcp server? apt install dhcpcd5 It can do this, it is called "nooption ntp_servers" Reco
Re: systemd/dhcp v. ntpd
Hi. On Wed, Feb 09, 2022 at 09:05:51AM -0500, Lee wrote: > On 2/8/22, Greg Wooledge wrote: > > On Tue, Feb 08, 2022 at 02:43:02PM -0500, Lee wrote: > >> How to tell systemd to leave the ntpd config alone? > > > > What makes you think the two are connected in any way? > > $ grep "Network Time Service" syslog > Feb 6 12:06:48 spot systemd[1]: Stopping Network Time Service... > Feb 6 12:06:48 spot systemd[1]: Stopped Network Time Service. > Feb 6 12:06:48 spot systemd[1]: Starting Network Time Service... > Feb 6 12:06:48 spot systemd[1]: Started Network Time Service. > Feb 6 12:09:25 spot systemd[1]: Stopping Network Time Service... > Feb 6 12:09:25 spot systemd[1]: Stopped Network Time Service. > Feb 6 12:09:25 spot systemd[1]: Starting Network Time Service... > Feb 6 12:09:25 spot systemd[1]: Started Network Time Service. > Feb 6 12:22:53 spot systemd[1]: Stopping Network Time Service... > Feb 6 12:22:53 spot systemd[1]: Stopped Network Time Service. > Feb 6 12:22:53 spot systemd[1]: Starting Network Time Service... > Feb 6 12:22:53 spot systemd[1]: Started Network Time Service. > ... etc > > every time I connect or disconnect from a wifi network. Or it could mean that dhclient hook merely asks systemd to restart ntpd service. See /etc/dhcp/dhclient-exit-hooks.d/ntp. > My first thought was telling the machine to ignore the NTP server > address handed out via DHCP. Maybe there's a way to do that, but I > couldn't figure out how :( supercede ntp-servers "..." in dhclient.conf should do it for you. The option was helpfully provided by dhclient.conf(5). > >> I tried changing /etc/dhcp/dhclient.conf to request just > >> request subnet-mask, broadcast-address, routers, > >> interface-mtu, > >> rfc3442-classless-static-routes ; > >> > >> and systemd still restarted ntpd with only the dhcp supplied ntp > >> server address ... which is this machine, so all the configured ntp > >> servers went away :( And that merely stopped dhclient from asking DHCP server to provide "ntp-server" option. What it cannot stop is DHCP server providing "ntp-server" option anyway. ISC dhclient simply lacks the option to ignore certain options in DHCP reply. It can supercede them though. > >> I then tried telling network manager to just get an ip address & > >> subnet mask from dhcp. And still systemd fucked up the ntpd config > >> > >> What finally worked was editing /usr/lib/ntp/ntp-systemd-wrapper to > >> remove ' NTPD_OPTS="$NTPD_OPTS -u $UGID" ' > > > > Huh? You're saying that removing the "-u $UGID" option made it "work"? > > And that it "didn't work" with -u being passed? Changing the contents of /etc/dhcp/dhclient-exit-hooks.d/ntp would make it more friendly for the purpose of the future updates. Reco
Re: Security
Hi. On Fri, Feb 04, 2022 at 09:43:18AM +0100, Andrei POPESCU wrote: > On Du, 30 ian 22, 19:27:56, Reco wrote: > > > > > > > > How does "people installing without recommends" translate to "GNOME > > > users" is beyond me, > > > > Easy. Look closely at two graphical frontends to libvirt they provide in > > main archive. > > Now ask yourself - would I need these on a server? Who would need to use > > these? > > Those who want a graphical tool to manage their VMs? I.e. those who have a dozen VM at most, a single "server" to host them, and said "server" is most probably translates to a localhost. I don't see all that as a bad thing, but each GUI has its share of limitations once it comes to managing something in big quantities, and both GNOME boxes and Virt Manager follow that principle. > Installing some -gnome packages still doesn't make me a GNOME user ;) But installing them gives you a pile of GNOME core packages by dependency. Thus the software in question behaves the way GNOME developers want it to behave, and the dependent software does it too. #768376 is a fine example of that. Thus I have bad news for you - installing either GNOME boxes or Virt Manager (or other GNOME stuff) made you GNOME user, but if you insist you're not - I won't press it ;) For the record, for me both "GNOME" and "GNOME user" does not have a negative connotation. About the only flaw of GNOME project for me is their abuse of Scrum software development methodology, and that's a topic for another discussion. Reco
Re: why copying big file fails?
Hi. On Sun, Jan 30, 2022 at 10:23:12PM +0100, Hans wrote: > Am Sonntag, 30. Januar 2022, 21:53:00 CET schrieb Reco: > > > > BTW which package in bullseye can play mp4? > > > > mpv or vlc. Everything else is not a media player anyway. > > Hmm... > I had very good success with smplayer on slower computers. An mpv or mplayer frontend. Most probably you've used mpv one, it's listed first in the Depends list. > So I would not say, others are no mediaplayers. Everyone should be allowed some exaggeration now and then, me included :) Let me say it another way - if one needs a mediaplayer that will play everything one throws at it, and wants to disregard assorted frontends available - there are exactly two choices. First is mpv, and second is vlc. > Aso XINE looks like a good player, That's its appearance, indeed. Subject to change once one starts using the thing. > too, or kaffeine. It's KDE VLC frontend. Reco
Re: why copying big file fails?
Hi. On Sun, Jan 30, 2022 at 03:11:36PM -0500, a wrote: > i run "ls -l", about 2G has been copied This. Method you're using for copying files does not matter. Whatever your phone is using instead of a proper filesystem does. 2G file size limit is typical for FAT, and chances are it's exactly what your phone uses. There's no way around it, probably even if you root your phone. Split your file in chunks, that's how it will work. > BTW which package in bullseye can play mp4? mpv or vlc. Everything else is not a media player anyway. Reco
Re: Security
Hi. On Sun, Jan 30, 2022 at 02:39:14PM +0100, Andrei POPESCU wrote: > On Du, 30 ian 22, 15:54:17, Reco wrote: > > On Mon, Jan 31, 2022 at 01:36:06AM +1300, Richard Hector wrote: > > > On 29/01/22 04:17, Vincent Lefevre wrote: > > > > > > > Servers shouldn't have pkexec installed in the first place, anyway. > > > > > > > > > > libvirt-daemon-system depends on policykit-1. > > > > > > Should that not be on my (kvm) server either? > > > > Many years ago exactly this was disputed in #768376. > > Long story short - the only reason libvirt-daemon-system depends on > > policykit-1 is because GNOME users could be confused if it does not. > > As far as I can tell the Maintainer's stance (in 2014) was: > > Having polkit installed and doing nothing (for people switching to > socke based permission checks) is IMHO a better service to our users > than having all the bugs for people installing without recommends (and > there are many of those) > > > How does "people installing without recommends" translate to "GNOME > users" is beyond me, Easy. Look closely at two graphical frontends to libvirt they provide in main archive. Now ask yourself - would I need these on a server? Who would need to use these? > considering that GNOME users would have policykit-1 > installed anyway (as a dependency of GNOME) and they are much less > likely to disable installation of Recommends in the first place. Back in '14 that was not universal axiom. Things have changed since then somewhat though. > As written in message #80 circumstances have changed, maybe the > Maintainer will reconsider. Possibly, although unlikely. I mean, it was a wishlist priority bug, after all. My point in all this - PolicyKit was redundant on a typical server back then, and by large it still is. Even if your server has libvirt, although in this case some assembly is required. Reco
Re: Security
Hi. On Mon, Jan 31, 2022 at 01:36:06AM +1300, Richard Hector wrote: > On 29/01/22 04:17, Vincent Lefevre wrote: > > > Servers shouldn't have pkexec installed in the first place, anyway. > > > > libvirt-daemon-system depends on policykit-1. > > Should that not be on my (kvm) server either? Many years ago exactly this was disputed in #768376. Long story short - the only reason libvirt-daemon-system depends on policykit-1 is because GNOME users could be confused if it does not. Reco
Re: hostname is being reset, killing net on reboot
On Wed, Jan 26, 2022 at 07:11:36PM +0100, Andrei POPESCU wrote: > > # fallback to static profile on eth0 > > interface eth0 > > fallback static_eth0 > > > > So if dhcpd fails, it uses the above, and it Just Works. > > And I've not found any reference to it in the man page. So I've no clue > > why it seems to be such a huge, no one knows about it secret. > > This must be the most complicated, round-about, inefficient method I've > ever seen to configure a static IP :) I disagree. One can install NetworkManager, and then it will get even more complicated. > Is it so difficult to find out what is the canonical method to configure > a static IP on a Raspberry Pi OS? This is such a basic task it should be > somewhere in their documentation, wiki, whatever. Curiously enough, this time Gene used "official" way to configure static IP on RPi - [1]. Official documentation does not even mention e/n/i. > Then it should be possible to configure a static IP with any of Debian's > network management tools you like. And *that* would be fighting the distribution-approved method, and not working with it. It's totally possible (I did it), but then again, it's totally possible to install a real Debian on RPi. All this once again proves us, folks - RaspberryPi OS is not Debian. It's Debian-based. Certain list members do not see the difference, let's refrain from pointing fingers :) Reco [1] https://www.raspberrypi.com/documentation/computers/configuration.html#static-ip-addresses
Re: DNS resolver issue
Hi. On Mon, Jan 24, 2022 at 10:14:23AM +, Bhasker C V wrote: > $ dig +short server.example.local > 192.168.2.2 Just in case, using ".local" domain that way violates RFC 6762. There are numerous ways to name your private domain, but ".local" is not a proper name for that. > Now, isnt the lookup supposed to fall back to next server if first one > doesnt have an answer ? Only if the first DNS is unreachable or returning SERVFAIL. Your is returning NXDOMAIN, so this behaviour is expected. > How does multiple DNS servers entry work in resolv.conf ? Barring "options rotate", always try first nameserver specified for any query, switch to the second if timeout (5 seconds by default, according to resolv.conf(5), 30 seconds in practice) is reached. Easiest way to solve your problem would be specify an public resolver (1.1.1.1) in your bind configuration for anything but your domain, and then use only 192.168.2.1 in your resolv.conf. Reco
Re: jupyter-notebook and bullseye
Hi. On Fri, Dec 31, 2021 at 01:35:47PM -0700, D. R. Evans wrote: > Reco wrote on 12/17/21 6:10 AM: > > Hi. > > > > On Thu, Dec 16, 2021 at 12:43:51PM -0700, D. R. Evans wrote: > > > FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/python' > > ... > > > Can someone suggest how I might get back to the fully-working set of > > > kernels that I had in buster? > > > > Try this: > > > > apt install python-is-python3 > > Thank you very much. > > That was certainly a help (although I wonder why it was necessary for me to > do that manually), It's official Debian policy now, believe it or not. python 2.x is /usr/bin/python2. python 3.x is /usr/bin/python3. If the user really wants /usr/bin/python the user should install python-is-python2 or python-is-python3. And these two packages conflict with each other. > but ultimately I am still unable to do anything. I'm not familiar with jupyter and I'm not using it. What I do know is: a) /usr/bin/python was python 2.x in Debian 10. b) Python 2.x and python 3.x modules are not compatible nor they are interchangeable. Judging from [1], you're required to reinstall all these "jupyter kernels", because what you have was installed for python2, but what you need is to install them for python3. But then again, I could be wrong. Sorry, cannot help you further. Reco [1] https://github.com/takluyver/bash_kernel
Re: jupyter-notebook and bullseye
Hi. On Thu, Dec 16, 2021 at 12:43:51PM -0700, D. R. Evans wrote: > FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/python' ... > Can someone suggest how I might get back to the fully-working set of kernels > that I had in buster? Try this: apt install python-is-python3 Reco
Re: reject dhclient offer from wrong subnet
Hi. On Wed, Dec 15, 2021 at 04:37:19PM +0100, Tuxo wrote: > Can I configure dhclient on my router to discard lease offers from a certain > subnet? I could also try to match the lease time, the 192.168.100/24 lease > time > is only several seconds (!!) short, the real one will be 4 hours or more and > come with a valid WAN subnet mask. Try adding "reject 192.168.100/24;" into your router's dhclient.conf. Also, dhclient.conf(5). Reco
Re: upgrade - packages have been kept back
Hi. On Fri, Dec 10, 2021 at 09:04:25AM +0100, teamas...@mad-hatters-teatime.teanet.org wrote: > On Thu, 9 Dec 2021 23:09:34 + > "Andrew M.A. Cater" wrote: > > > On Thu, Dec 09, 2021 at 11:58:33PM +0100, > > teamas...@mad-hatters-teatime.teanet.org wrote: > > > hey, > > > i have not been using debian for long and not sure how to proceed > > > here. is a: > > > apt-get upgrade linux-image-amd64 > > > the right way? > > > ty, jens. > > > > apt-get update ; apt-get upgrade > > > > [You need to pull in an up to date list of packages first] > > exactly that did not work And it's because it should not work in the first place in the situation like this. "apt-get upgrade" should and will refuse to install any new packages (or uninstall existing ones). What should solve your problem is: apt update; apt upgrade And it's because "apt" (not to be confused with "apt-get") is allowed to install new packages during the update. What also could solve your problem (but it's inherently dangerous, as it will allow to remove installed packages as well) is: apt-get update; apt-get dist-upgrade In short, when in doubt, use "apt", not "apt-get". Reco
Re: nginx mail proxy
Hi. On Sun, Nov 21, 2021 at 02:27:52PM +0300, Gokan Atmaca wrote: > What could be the problem? The very thing nginx tells you in the error message - "mail" directive is not recognized. Probably your installation is missing libnginx-mod-mail. Reco
Re: question?
Hi. On Tue, Oct 26, 2021 at 10:19:05PM -0500, John Hasler wrote: > Piotr writes: > > It already exists - Mobian. I use it on my Pinephone with Debian > > Testing. > > How do I get it? The Mobian site says that the PinePhone Mobian > Community Edition is available from Pine64 but I don't see it on their > site. The usual place - [1]. Reco [1] https://linuxtracker.org/browse.php/index.php?page=torrents=2251
Re: what is the best package to design the layout of the house
Hi. On Wed, Oct 27, 2021 at 11:34:08AM +0200, lina wrote: > What is the best/user-friendly package that can be used to design a simple > house, if it comes with garden design it would be a bonus. I don't know about garden design, but I used sweethome3d for an apartment design back in the day. Written in Java, but works reasonably fast. Reco
Re: xhost-command in Debian11
Hi. On Fri, Oct 22, 2021 at 08:25:36AM -0600, Charles Curley wrote: > charles@jhegaala:~$ su --whitelist-environment=DISPLAY - It won't be enough. You need this: su --whitelist-environment=DISPLAY,XAUTHORITY - Reco
Re: Sata Hard drive testing
Hi. On Thu, Oct 21, 2021 at 01:45:52AM +0200, Thomas Anderson wrote: > I am trying to parse them myself, to see if I can learn anything. But, > immediate glance and queries did not reveal anything that could help > me determine if the drive is good or not. It's not. You have a Seagate, after all, and those are good only as long as trash can is considered :) But anyway, it's not new. > 9 Power_On_Hours 0x0032 084 084 000 Old_age Always > - 14558 (99 41 0) It has bad sectors, a small amount compared to the drive size. > 183 Runtime_Bad_Block 0x0032 095 095 000 Old_age Always > - 5 > 187 Reported_Uncorrect 0x0032 001 001 000 Old_age Always > - 1334 > 197 Current_Pending_Sector 0x0012 100 100 000 Old_age Always > - 8 > 198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offline > - 8 And you had some problems with the drive in the past, which could be a bad SATA cable, but could be the drive itself: > Error 1334 occurred at disk power-on lifetime: 10525 hours (438 days + 13 > hours) > When the command that caused the error occurred, the device was active or > idle. > > After command completion occurred, registers were: > ER ST SC SN CL CH DH > -- -- -- -- -- -- -- > 40 53 00 ff ff ff 0f Error: UNC at LBA = 0x0fff = 268435455 > > Commands leading to the command that caused the error were: > CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name > -- -- -- -- -- -- -- -- > 60 00 08 ff ff ff 4f 00 15d+00:06:46.256 READ FPDMA QUEUED > ef 10 02 00 00 00 a0 00 15d+00:06:46.247 SET FEATURES [Enable SATA > feature] > 27 00 00 00 00 00 e0 00 15d+00:06:46.220 READ NATIVE MAX ADDRESS EXT > [OBS-ACS-3] > ec 00 00 00 00 00 a0 00 15d+00:06:46.217 IDENTIFY DEVICE > ef 03 46 00 00 00 a0 00 15d+00:06:46.205 SET FEATURES [Set transfer mode] Assuming you make backups, I'd call this drive servicable. I'd replace it sooner or later, because it has bad sectors, but it won't be the first priority. Reco
Re: Sata Hard drive testing
Hi. On Mon, Oct 18, 2021 at 06:25:19PM +0200, Thomas Anderson wrote: > I have been having problems with a drive (non-SSD) for a while now, > but I would like to "identify" the problem specifically, so that I may > perhaps be able to get the drive replaced. Assuming it's SATA/IDE drive, all you need to do is: apt install smartmontools smartctl -t long # wait for the test to finish smartctl -a Please post the output of the last command. Reco
