Solution
I think it is not current now, but for the guys surfing the net: The solution is to add these 2 lines to snmpd.conf interface eth0 - the network card you want to use agentaddress ip-address:161 - the listening IP address and port -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
I hope You are satisfied now :)
The original problem was: "However if I run "snmpwalk -v 1 -c public 192.168.1.36 system" on the stable box, with 192.168.1.36 the IP address of the testing box, i get: Timeout: No Response from 192.168.1.36 snmpd is up and running, I can ping both ways, there are no firewalls in place. What could be wrong?" The solution is: open snmpd.conf with your favourite editor and add these 2 lines: interface eth0 agentaddress [ip address of your host]:[listening port - 161 is the default] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
You are required to change your password immediately (administrator enforced).
After the most recent update of a host running sid there was a password change dialog: You are required to change your password immediately (administrator enforced). You are required to change your password immediately (administrator enforced). That would be me, but I cannot remember having set such a policy, so WTH? Not to mention that this broke non-interactive ssh sessions as well. How can I make sure I don't have to change passwords on 400+ hosts? Regards Harri
Re: You are required to change your password immediately (administrator enforced).
On 8/17/21 21:55, Sven Joachim wrote: On 2021-08-17 19:59 +0200, Harald Dunkel wrote: How can I make sure I don't have to change passwords on 400+ hosts? Do not run sid on 400+ hosts. Do not run testing either, especially in the first months after a release. Of course not. But sid becomes the next release in 2 years, and then it might be to late to get rid of this lie. Regards Harri
ifupdown lost at upgrade time to bullseye
Hi folks, how comes ifupdown is dropped at upgrade time to bullseye, leaving the (headless) system without network connection while the upgrade is not completed yet, and breaking network on the next reboot? Regards Harri
how to forbid debhelper to modify /home ?
Hi folks, how can I tell the debhelper scripts to not install home directories for system services in /home (managed on a remote host in my environment), but to use /var/lib instead? I know I can block dpkg using apparmor, but this would break many postinst scripts, at least for 3rd-party packages. Some kind of redirect would be helpful. Regards Harri
Re: how to forbid debhelper to modify /home ?
On 9/3/21 11:40, Erwan David wrote: I would do this the other way (but not eay tpo migrate) : add your users in another directory (/srv/home or something else) where you mpount your remote home directory, and keep system using /home. I agree, but unfortunately this is not an option.
Re: how to forbid debhelper to modify /home ?
On 9/3/21 13:57, Roberto C. Sánchez wrote: That sounds like potentially buggy behavior. Can you give a specific example? ntp (Debian) sane (Debian) gitlab-runner (not Debian) zabbix-agent (not Debian) Apparently the postinst scripts of ntp and sane have been fixed. I don't want to blame anybody, anyway.
git FTBFS ?
Hi folks, trying to build git 2.34.0-1 for bullseye I get 2 segfaults (see #991214). Apparently they pop up during the built-in tests, so I wonder if this is a FTBFS? If this is nothing to worry about, how comes that these segfaults are not caught like the others? Regards Harri
how comes bug reports are processed after 10 minutes?
Hi folks, apparently it takes about 10 minutes between filing a bug report (no attachments) and sending the confirmation EMail. Thats quite a long time. Imagine you have to forward Debian's bug number to your own in-house BTS. There are about 10^6 bug reports in Debian's BTS. Maybe 1% is updated each day; lets say 10 GByte data per day on bad circumstances. That is not very much, even for a slow database. How comes? Harri
Focus on python 3.9 instead of 3.9.2 for Bullseye?
Hi folks, Would it be possible to ignore the micro version number of python 3.9 and get 3.9.12 for Bullseye? Hiding 3.9.12 in Bookworm is useless. I doubt that the users running Testing or Sid are scared of python 3.10. Regards Harri
ca-certificates: DST_Root_CA_X3.crt expired, so why is it still included in Bullseye?
Hi folks, apparently /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt expired last year: % openssl x509 -in /usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt -noout -dates notBefore=Sep 30 21:12:19 2000 GMT notAfter=Sep 30 14:01:15 2021 GMT I wonder why it is still included in ca-certificates for Bullseye? Regards Harri
Debian 10 --> 11 on Dell R740: network interfaces renamed
Hi folks, after the upgrade to Debian 11 some network interfaces in my Dell R740 got renamed. Before: # lshw -class network -short H/W path Device Class Description /0/2/0eno1networkEthernet Controller 10G X550T /0/2/0.1 eno2networkEthernet Controller 10G X550T /0/3/0eno3networkI350 Gigabit Network Connection /0/3/0.1 eno4networkI350 Gigabit Network Connection /0/103/0 ens3f0 networkI350 Gigabit Network Connection /0/103/0.1ens3f1 networkI350 Gigabit Network Connection After: # lshw -class network -short H/W path Device Class Description === /0/2/0eno1 networkEthernet Controller 10G X550T /0/2/0.1 eno2 networkEthernet Controller 10G X550T /0/3/0eno3 networkI350 Gigabit Network Connection /0/3/0.1 eno4 networkI350 Gigabit Network Connection /0/103/0 enp94s0f0 networkI350 Gigabit Network Connection /0/103/0.1enp94s0f1 networkI350 Gigabit Network Connection How comes? AFAIR these predictable interface names had been introduced to get *stable* names, if the hardware is changed. Since it is more likely to get a kernel upgrade than new network hardware I wonder of the predictable names could be made even more predictable? Old kernel was 4.19.0-18-amd64, new kernel is 5.10.0-14-amd64. /lib/systemd/network/99-default.link is [Match] OriginalName=* [Link] NamePolicy=keep kernel database onboard slot path AlternativeNamesPolicy=database onboard slot path MACAddressPolicy=persistent Every helpful comment is highly appreciated. Harri
Re: Debian 10 --> 11 on Dell R740: network interfaces renamed
If I have to hardwire the interface names to their Mac address as you suggested, then I don't see a significant difference to the old-style /etc/udev/rules.d/70-persistent-net.rules we had till Debian 10, except that the former was auto-generated and easier to modify. Regards Harri
Re: Debian 10 --> 11 on Dell R740: network interfaces renamed
On 2022-06-14 01:48:16, David Wright wrote: Perhaps calling the new interface naming scheme "predictable" is somewhat overselling it, but "persistent" (a better choice IMHO) was already in use, both in the way quoted above, and as one of the choices for MAC address generation. The changed names are neither predictable nor persistent, so this naming scheme failed, regardless how you call it. I would be glad if I could get some *expected* interface names, at least. The question remains: How comes? Looking at the kernel logging output the interface names were generated as good ol' "eth0", "eth1" and so on. They were renamed into a "persistent" string later by some code on the initrd, as it seems. AFAICT this code is part of systemd/udev. Is this a bug or did this happen on purpose? Regards Harri
how to get rid of anacron?
Hi folks, I do not like my cron jobs in /etc/cron.daily being ignored or delayed for some obfuscated reasons, so I wonder what is the recommended alternative to anacron with propper logging by default? Will systemd take care? Regards Harri
closing Bullseye bugs pointing to a fix in Unstable?
Hi folks, what is Debian's policy wrt bugs reported for a package in Stable (e.g. some daemon eating up 100% CPU)? Looking at the "Closes:" feature for debian/changelog I have the impression that a fix in Unstable is seen to be sufficient "to get rid" of the bug report. Surely "Closes:" is very convenient, but wouldn't you agree that this puts the users of Stable at a disadvantage? Regards Harri
Re: Network manager: activating VPN in GNOME remote session doesn't work, but in KDE remote session (xrdp)
Hi BM if your VPN is IPsec, then you might want to examine charon's output via journalctl. Probably openvpn, wireguard and others can be found there, too. Another thing to try is to establish the VPN connection using nmcli in a terminal window, e.g. nmcli con up "VPN name" Maybe you get a usable error message this way. Regards Harri
how to rescue lxc?
Hi folks, according to https://tracker.debian.org/pkg/lxc lxc is in bad shape. I would love to help. How can I help? I already filed a patch for #966998, verified lxc 4.0.4 (#969229) and (meaning no offense, but) #961584 looks like a home-made problem to me. Anyway, lxc 4.0.4 is supposed to fix this problem as well, see https://github.com/lxc/lxc/issues/3471. Debian is already tier-2 for container-based virtualization. It would be very nice if lxc could be rescued. Regards Harri
Tora 3 for Bullsey?
Hi folks, how comes there is not Tora for Bullseye? Regards Harri
spectre-meltdown-checker: Hash Sum mismatch
Hi folks, aptitude shows E: Failed to fetch http://deb.debian.org/debian/pool/main/s/spectre-meltdown-checker/spectre-meltdown-checker_0.42-1_all.deb: Hash Sum mismatch Hashes of expected file: - SHA256:a5b777497c860a51ce1f1fd888f727531ea60be625ffe6787aebf12823177e2f - MD5Sum:3e6e8e46213f00c03d1103757bca1fd5 [weak] - Filesize:45208 [weak] Hashes of received file: - SHA256:1dca832b59ff6fce1b506c5291418a30c99e0d1f5b43b504909bfd8bbfdc3490 - MD5Sum:2f3d9c6f6a5f7704b64f6f582ee4dcd7 [weak] - Filesize:45208 [weak] Last modification reported: Mon, 27 May 2019 11:14:06 + E: Unable to fetch some packages; try '-o APT::Get::Fix-Missing=true' to continue with missing packages I already cleared the cache of apt-cacher-ng, but the problem comes back. What would you suggest how to proceed? Regards Harri
Re: spectre-meltdown-checker: Hash Sum mismatch
Hi folks, On 2/19/21 2:47 PM, Harald Dunkel wrote: I already cleared the cache of apt-cacher-ng, but the problem comes back. What would you suggest how to proceed? Mystery solved: apt-cacher-ng used /var/cache/apt-cacher-ng instead of /export/cache/apt-cacher-ng I had configured some time ago. I flushed the wrong cache directory. Apparently a merge problem for /etc/apt-cacher-ng/acng.conf at upgrade time. My bad. Regards Harri
IPv6 prefix delegation: avahi-daemon vs dhcpcd vs kernel
Hi folks, question about IPv6 support in sid: Whose job is it to bother about the IPv6 addresses dynamically bound to eth0? AFAIU the kernel sees the prefix delegation on eth0, sets the old IPv6 address to "deprecated" and registers the new one. How comes that avahi daemon and dhcpcd and possibly others interfere? Every insightful comment is highly appreciated Harri
who is verifying proposed-updates ?
Hi folks, how good is test coverage of proposed-updates? Its pretty unknown (IMHO), so I wonder if there are numbers from the popularity contest? Regards Harri
who is verifying proposed-updates ?
Hi folks, how good is test coverage of proposed-updates? This repository is pretty much unknown (IMHO), so I wonder if there are numbers from the popularity contest? Regards Harri
who is verifying proposed-updates ?
Hi folks, how good is test coverage of proposed-updates? This repository is pretty much unknown (IMHO), so I wonder if there are numbers from the popularity contest? Regards Harri
Re: who is verifying proposed-updates ?
PS: Sorry for sending this thrice. I did not receive a copy due to some misconfiguration. Harri
ssl handshake problem with bugs.debian.org?
Hi folks, I've got a ssl handshake problem with bugs.debian.org on sending an EMail. My mta (OpenBSD 6.7, i.e. libressl) in the office says in its logfile : Jul 27 10:23:37 gate5a smtpd[67056]: d4df9298d18e1596 mta connecting address=smtp://209.87.16.39:25 host=buxtehude.debian.org Jul 27 10:23:37 gate5a smtpd[67056]: d4df9298d18e1596 mta connected Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta tls ciphers=TLSv1.3:AEAD-AES256-GCM-SHA384:256 Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta server-cert-check result="failure" Jul 27 10:23:39 gate5a smtpd[67056]: d4df9299bfe4df24 mta connecting address=smtp://[2607:f8f0:614:1::1274:39]:25 host=buxtehude.debian.org Jul 27 10:23:39 gate5a smtpd[67056]: d4df9298d18e1596 mta error reason=IO Error: error:1404C410:SSL routines:ST_OK:sslv3 alert handshake failure Jul 27 10:23:39 gate5a smtpd[67056]: smtp-out: Disabling route 5.145.142.10 <-> 209.87.16.39 (buxtehude.debian.org) for 15s Jul 27 10:23:39 gate5a smtpd[67056]: d4df9299bfe4df24 mta connected Jul 27 10:23:41 gate5a smtpd[67056]: d4df9299bfe4df24 mta tls ciphers=TLSv1.3:AEAD-AES256-GCM-SHA384:256 Jul 27 10:23:41 gate5a smtpd[67056]: d4df9299bfe4df24 mta server-cert-check result="failure" Jul 27 10:23:41 gate5a smtpd[67056]: d4df9299bfe4df24 mta error reason=IO Error: error:1404C410:SSL routines:ST_OK:sslv3 alert handshake failure Jul 27 10:23:41 gate5a smtpd[67056]: smtp-out: Disabling route [2001:67c:13b0:::60] <-> [2607:f8f0:614:1::1274:39] (buxtehude.debian.org) for 15s Jul 27 10:23:41 gate5a smtpd[67056]: smtp-out: Address family mismatch on [connector:[2001:67c:13b0:::60]->[relay:bugs.debian.org,smtp,sourcetable=,heloname=mail.aixigo.de],0x0] Jul 27 10:23:41 gate5a smtpd[67056]: smtp-out: Address family mismatch on [connector:5.145.142.10->[relay:bugs.debian.org,smtp,sourcetable=,heloname=mail.aixigo.de],0x0] : Please note the "sslv3 alert handshake failure". We send a bazillion of EMails via this MTA each day. This handshake problem shows up only for buxtehude, AFAICT. Is there a compatibility issue with openssl in Debian and libressl used in OpenBSD 6.7? AFAIU TLS 1.3 is not in libressl yet. Every helpful hint is highly appreciated. Harri
Re: ssl handshake problem with bugs.debian.org?
On 2020-07-27 11:17, Sven Hartge wrote: Debian uses their own CA to sign this certificate, which is fine for SMTP, which normally only uses opportunistic encryption. But if the client SMTP-Server is set to *verify* the certificate, it will fail. Certificate verification is optional on my MTA. See the log file. AFAICT it ignored the failed certificate check and continued with the ssl handshake. *Then* it failed. It would be interesting to know whats written in the log files on buxtehude. Are there other similar incidents? Regards Harri
Re: ssl handshake problem with bugs.debian.org?
On 2020-07-27 13:49, Sven Hartge wrote: Does your MTA present a client certificate? Maybe buxtehude does not like that? Yes, it has a certificate. Whether buxtehude likes it I cannot say, but it looks OK to me. Its a wildcard certificate, though: Certificate: Data: Version: 3 (0x2) Serial Number: 0b:4b:72:01:12:76:76:75:a8:ec:10:0d:11:36:7b:f8 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=DigiCert Inc, CN=DigiCert SHA2 Secure Server CA Validity Not Before: Jul 9 00:00:00 2020 GMT Not After : Sep 8 12:00:00 2022 GMT Subject: C=DE, ST=Nordrhein-Westfalen, L=Aachen, O=aixigo AG, OU=Internet, CN=*.aixigo.de Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:c7:43:b9:e8:1b:5b:2c:b0:a8:26:05:d3:9f:06: : : 47:58:c2:17:be:c9:d8:26:7a:4b:45:d6:df:19:cb: 50:79 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:0F:80:61:1C:82:31:61:D5:2F:28:E7:8D:46:38:B4:2C:E1:C6:D9:E2 X509v3 Subject Key Identifier: F7:5D:C6:13:97:9B:F8:D4:49:9E:EC:36:E1:B3:26:C2:12:BD:D2:8C X509v3 Subject Alternative Name: DNS:*.aixigo.de, DNS:aixigo.de, DNS:mail.aixigo.de X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: : : BTW, the problem showed up first on June 17th. When diagnosing SSL errors I also find it helpful to wireshark the connection to see which side exactly triggers the SSL Alert. That may help highlight the culprit here. See attachment. AFAICT this is all encrypted. Regards Harri buxtehude.debian.org.pcap Description: application/vnd.tcpdump.pcap
aptitude problem with control file (in stretch)
Hi folks,
I've got a problem with upgrading a private package in Stretch. The control
file says:
Package: sample-lxc
Architecture: all
Depends: ${misc:Depends}
, cgmanager | systemd
, debootstrap
, lxc
, lxc-templates | lxc ( << 3 )
Recommends: cgroup-tools
, apparmor
, uidmap
, yum
Conflicts: lxcfs
Description: LXC framework
This package provides LXC for our environment.
lxc-templates is available only for lxc >= 3 (Buster or Bullseye), and
then its a must-have in my environment.
Trying to install this package on Stretch aptitude complains about a
missing lxc-templates package, even though the most recent lxc version
1:2.0.11-1~xgo90+1 is installed.
apt and apt-get are fine, AFAICS.
???
Regards
Harri
Re: aptitude problem with control file (in stretch)
On 8/5/20 11:03 AM, Sven Joachim wrote: I am surprised to read that, considering that your installed lxc version does not actually fulfill the dependency. Note the epoch. $ dpkg --compare-versions 1:2.0.11-1~xgo90+1 lt 3 || echo 'Got it!' Got it! Maintaining the sample-lxc package I have no influence upon other packages introducing new epoch numbers. Upstream moved the templates into a separate github repository for lxc version 3, so its unreasonable to consider Debian's epoch number for package dependencies in this case. How can I express this dependency upon lxc's upstream version number in my control file, ignoring the epoch number? This is just out of interest. The workaround for my package is obvious. Regards Harri
Re: aptitude problem with control file (in stretch)
On 8/5/20 6:29 PM, Sven Joachim wrote:
I am not sure I understand what you actually want to do, though.
I am maintaining a set of meta packages, referencing the packages
to install on my hosts. To avoid having separate meta packages for
each new Debian version I have to use conditional dependencies, like
Package: sample-setup
Architecture: all
Depends: ${misc:Depends}
, sample-setup-chroot
:
, nvme-cli | base-files ( << 9 )
:
Meaning nvme-cli has to be installed for Debian 9 or newer.
This package
Package: sample-lxc
Architecture: all
Depends: ${misc:Depends}
, cgmanager | systemd
, debootstrap
, lxc
, lxc-templates | lxc ( << 3 )
:
did not work as expected (IMHO), apparently because (1:2 << 3) = false.
Regards
Harri
/dev/fd is missing, how comes?
Hi folks, after booting my desktop PC this morning it seems that /dev/fd is missing. This breaks dkms. How comes? Which tool/package/service was supposed to create the symlink for /dev/fd? Every insightful comment is highly appreciated Harri
anybody maintaining lxc and lxd in Debian?
Hi folks, is anybody maintaining lxc in Debian? I have the impression that it has been orphaned. And I don't dare to hope for #768073 anymore. Does everybody interested in virtualization use Ubuntu now? Regards Harri
Re: anybody maintaining lxc and lxd in Debian?
On 7/10/18 12:36 PM, Jonathan Dowland wrote: > On Fri, Jul 06, 2018 at 09:56:58AM +0200, Harald Dunkel wrote: >> is anybody maintaining lxc in Debian? I have the impression that >> it has been orphaned. And I don't dare to hope for #768073 anymore. > > Ah yes I'd forgotten about that (I was involved for a while). But > looking at the current status it's not as bleak as I feared; the last > dependency was finally finished in February. > I saw the updates in #768073. Good to know that it hasn't been forgotten. How about LXC? In the meantime I built and tried Ubuntu's version 3.0.1 on Stretch. It builds fine. The package upgrade path was a little bit rough, but it seems to work. Didn't try apparmor, though. Kernel was 4.16.12-1~bpo9+1. One problem here: LXC 2.1 (not available in Debian) could be used to migrate to the new config file format. 3.0.1 doesn't support the old format anymore, i.e. running LXC 2.0 it is *mandatory* to adjust the config files for 3.0.1 (using the provided lxc-update-config script). Regards Harri
Debian got too fat?
Hi folks, would you mind to take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888743 The fix is pretty easy. Whats really bugging me is that nobody dares to touch the complex code of lsb-base. IMHO this is a clear indication that Debian lost the blessed path other Unixes do follow. What is your suggestion here? Apply the patch I provided (or maybe a better one), or get rid of lsb-base completely? Regards Harri
Re: Debian got too fat?
Hi Reco, On 7/15/18 1:44 PM, Reco wrote: Hi. On Sun, Jul 15, 2018 at 12:16:20PM +0200, Harald Dunkel wrote: Hi folks, would you mind to take a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=888743 The fix is pretty easy. But does not address all the cornercases, IMO. Consider, for instance, an LXC container which shares root filesystem with the host. The "pidof -c" is just a workaround. In your case pidofproc would fall back into the current (broken) functionality, AFAICS. A *clean* solution would give /bin/pidof the boot and rely upon the PID files in /run only. This is not the problem here. The problem is that things like this don't get fixed because its pretty complex code for an easy task. Changing it might have unforeseeable side effects and nobody dares to touch it. Regards Harri
Re: Debian got too fat?
On 7/16/18 10:45 AM, Jonathan Dowland wrote: My suggestion is unless you are prepared to adopt and maintain lsb-base, (as Didier has made clear he wants to orphan it), find an alternative tool to achieve what you want. I am already running my private lsb-base package for several months. The bug (#888743) put my environment at risk. Adding a workaround to lsb-base was easier than creating private versions of all packages affected. Would you suggest to deprecate lsb-base? Regards Harri
libressl in Buster?
Hi folks, apparently the new OpenSMTPD 6.4 depends upon libressl (see https://www.opensmtpd.org/announces/release-6.4.0.txt), so I wonder what will become of #754513? Is there a chance to get libressl (optionally) into Buster? Is there a naming conflict? Every insightful comment is highly appreciated Harri
Re: libressl in Buster?
On 11/1/18 4:16 PM, Reco wrote: > > It's rather a short release cycle and a lack of feature parity with > openssl. > I don't see a short release cycle as a bad feature. Its a sign of active and agile development. Openssl has a bad reputation for introducing security problems, partly due to its complex and "dangerous code", which was the major reason for the fork. https://en.wikipedia.org/wiki/LibreSSL#History I am not asking to drop openssl or to port all projects to libressl. It just would be nice being able to chose. Regards Harri
Re: libressl in Buster?
On 11/3/18 4:42 PM, Reco wrote: > Hi. > > On Sat, Nov 03, 2018 at 03:37:06PM +0100, Harald Dunkel wrote: >> >> I don't see a short release cycle as a bad feature. Its a sign of >> active and agile development. > > And in Debian stable that also means that it's close to impossible to > backport security fixes to chosen version (because it's "too old"). > Updating such fundamental library can (and probably *will*) lead to > API/ABI breakage. While tolerable at sid/testing, such things are > frowned upon at stable. > Thats a home-made problem affecting many packages in Debian, RedHat EL, and others. > >> Openssl has a bad reputation for introducing security problems, >> partly due to its complex and "dangerous code", which was the >> major reason for the fork. >> https://en.wikipedia.org/wiki/LibreSSL#History > > As long as it's used - they will search for vulnerabilities in there. > And they will find them. PHP has even worse reputation in this regard, > for example, yet you still see people who are using PHP. > Thats the point. AFAICT there are many alternatives to php. Its upstream's job to decide which scripting language to chose. Debian can chose to include the source packages (php or the tools using it) into the distro. For opensmtpd (the package I am interested in) upstream has decided to ditch openssl in favor of libressl. Now Debian has several options in this case: - add libressl to Debian - stick to the old opensmtpd 6.0.3 and openssl and backport security fixes - modify opensmtpd 6.4 to make it work with openssl - drop opensmtpd IMHO the 2nd and 3rd options imply a lot of additional effort. The 4th option would make the Debian users loose faith in Debian upgrades (if too many packages are kicked out). Regards Harri
"missing pubkey" for buster-security
Hi folks, I am running a local mirror of the security.debian.org repository for in-house use. It seems to be available for Buster as well, except that there is an error message ERROR: Condition '7638D0442B90D010' not fulfilled for '/var/www/official/lists/buster-security_buster%2Fupdates_InRelease'. Signatures in '/var/www/official/lists/buster-security_buster%2Fupdates_InRelease': '9D6D8F6BC857C906' (signed 2019-05-03): missing pubkey 'AA8E81B4331F7F50' (signed 2019-05-03): missing pubkey Error: Not enough signatures found for remote repository buster-security (http://security.debian.org buster/updates)! There have been errors! These keys are unknown on keyserver as well: # apt-key adv --keyserver keyring.debian.org --recv-keys 9D6D8F6BC857C906 Executing: /tmp/apt-key-gpghome.VRpQHhUEoX/gpg.1.sh --keyserver keyring.debian.org --recv-keys 9D6D8F6BC857C906 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 # apt-key adv --keyserver keyring.debian.org --recv-keys AA8E81B4331F7F50 Executing: /tmp/apt-key-gpghome.HyHJegKO1w/gpg.1.sh --keyserver keyring.debian.org --recv-keys AA8E81B4331F7F50 gpg: no valid OpenPGP data found. gpg: Total number processed: 0 I understand that Buster is not released yet, but wouldn't you agree that it is unusual to sign InRelease without sharing the public key? Every helpful comment is highly appreciated Harri
Re: "missing pubkey" for buster-security
Hi Ansgar, I highly appreciate your detailed response. I had not expected that the keyserver is restricted to developer keys. Thanx very much Harri
how to disable gdm3 via systemctl?
Hi folks, what is the recommended procedure to disable gmd3 using systemctl in Buster? "systemctl mask gdm" does not work as advertised. The "masked" seems to be ignored. Every helpful hint is highly appreciated Harri
Re: how to disable gdm3 via systemctl?
On 2020-01-13 10:52, john doe wrote: What about 'systemctl disable gdm'? Doesn't work, either. "systemctl status gdm" claims that gdm is masked (or disabled), but nevertheless it *is* started. root@usbpc:~# systemctl status gdm * gdm.service - GNOME Display Manager Loaded: loaded (/lib/systemd/system/gdm.service; masked; vendor preset: enabled) Active: active (running) since Mon 2020-01-13 11:23:37 CET; 49s ago Process: 10440 ExecStartPre=/usr/share/gdm/generate-config (code=exited, status=0/SUCCESS) Main PID: 10446 (gdm3) Tasks: 3 (limit: 4915) Memory: 7.0M CGroup: /system.slice/gdm.service `-10446 /usr/sbin/gdm3 Jan 13 11:23:37 usbpc systemd[1]: Starting GNOME Display Manager... Jan 13 11:23:37 usbpc systemd[1]: Started GNOME Display Manager. Jan 13 11:23:37 usbpc gdm-launch-environment][10454]: pam_unix(gdm-launch-environment:session): session opened for user Debian-gdm by (uid=0) The man page for "systemctl mask" says "Mask one or more units, as specified on the command line. This will link these unit files to /dev/null, making it impossible to start them. This is a stronger version of disable, since it prohibits all kinds of activation of the unit, including enablement and manual activation." "impossible" and "prohibits all kinds of activation of the unit" seems to be unambigous to me. Harri
Re: how to disable gdm3 via systemctl?
On 2020-01-13 10:58, john doe wrote: https://wiki.debian.org/GDM#systemd PS: Changing the default target is not an option (but it works, AFAICT). Regards Harri
Re: how to disable gdm3 via systemctl?
Hi Andrei, On 2020-01-13 23:40, Andrei POPESCU wrote:> > Display Managers are handled a little bit different than "regular" > services, since only one can run at a time (if you have several > installed), but at least one should be running (to not leave a > potentially inexperienced user in front of a text console). > I don't see any reason why it should be impossible to run lightdm on tty1 and tty2, gdm3 on a vnc session and yet another one on xvfb, all in parallel (just as an example). Wouldn't you agree that this is a config issue, i.e the job of the admin to decide? I can handle an error message triggered by a second dm on tty1, but what chance do I have, if systemctl doesn't work as documented anymore? Regards Harri
memory.limit_in_bytes: systemd vs lxc
Hi folks, I have to restrict memory.limit_in_bytes to 16GByte for my LXC containers. Problem: The containers based on Stretch and systemd show % for i in $(find /sys/fs/cgroup/memory/lxc/lxc1 -name memory.limit_in_bytes); do \ echo $i $(cat $i) \ done | column -t /sys/fs/cgroup/memory/lxc/lxc1/memory.limit_in_bytes 17179869184 /sys/fs/cgroup/memory/lxc/lxc1/user.slice/memory.limit_in_bytes 9223372036854771712 /sys/fs/cgroup/memory/lxc/lxc1/init.scope/memory.limit_in_bytes 9223372036854771712 /sys/fs/cgroup/memory/lxc/lxc1/system.slice/memory.limit_in_bytes 9223372036854771712 Apparently systemd ignores the restricted memory. How can I tell systemd to keep the limits? Every helpful comment is highly appreciated Harri
Re: memory.limit_in_bytes: systemd vs lxc
Hi Dejan, On Mon, 24 Jul 2017 09:43:30 +0200 Dejan Jocic wrote: > On 24-07-17, Harald Dunkel wrote: > > > > Apparently systemd ignores the restricted memory. How can I tell > > systemd to keep the limits? > > > > > > Every helpful comment is highly appreciated > > Harri > > > > Never did it myself, but perhaps this can help you: > > https://www.freedesktop.org/software/systemd/man/systemd.exec.html#LimitCPU= > > Thanx for the pointer, but I think this is a misunderstanding. I want systemd to keep(!) the limits, not have another local config file. Systemd should not be allowed to extend the limits bound to the container, no matter what. Regards Harri
howto restart a service in postinst script (Stretch and newer)
Hi folks, the Debian Policy Manual still talks about "run levels" and "init.d scripts" on https://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit . No word about systemd and others. What is the right way to restart a service from the postinst script for Stretch and newer? Reason for asking is: opensmtpd died once too often when it got restarted via invoke-rc.d from a postinst script on my desktop PC. Every helpful comment is highly appreciated Harri
Re: howto restart a service in postinst script (Stretch and newer)
On Sat, 5 Aug 2017 11:56:07 +0900 Mark Fletcher wrote: > On Fri, Aug 04, 2017 at 12:30:25PM +0200, Harald Dunkel wrote: > > > > What is the right way to restart a service from the postinst > > script for Stretch and newer? > > > > I may be misunderstanding your question but on a system that has > migrated to systemd, you can restart a service with: > > systemctl restart > I think you missed the point. To run it from a postinst script we need a universal(!) way to restart a service, regardless whether systemd or sysvinit-core or whatever is installed. Regards Harri
Re: howto restart a service in postinst script (Stretch and newer)
Hi Christian, On Sun, 6 Aug 2017 09:34:31 +0200 Christian Seiler wrote: > > For things that are only available on systemd (for example if you > have split the service additionally for systemd, while sysvinit is > still just a single script) you should use the code that is > generated from dh_systemd in postinst, which you can see e.g. here: > > http://sources.debian.net/src/debhelper/10.2.5/autoscripts/postinst-systemd-restart/ > this appears to be another misunderstanding: I am not restarting the packages own service, but *another* service, e.g. opensmtpd. My package has just provided the necessary config file. opensmtpd is not the only package that is just stopped on "invoke-rc.d restart" sometimes. I have seen similar problems with sssd and zabbix-agent. Is it possible that there is a race condition? Do systemd and sysvinit wait till the old service has exited before restarting a new one? Esp. opensmtpd, sssd and zabbix-agent manage a set of child services. Killing the parent might not be sufficient for cleanup before starting a new service. Regards Harri
invoke-rc.d fails to restart?
Hi folks, I have the impression that sometimes invoke-rc.d fails to restart services with children, e.g. zabbix-agent, sssd or opensmtpd. The service and its children are stopped, but not started again. Looking at "simple" services (without children) there is no such problem. It appears to be hard to reproduce, but has anybody made a similar observation? Regards Harri
/lib/lsb/init-functions on LXC servers
Hi folks, I see a weird effect of pidofproc (defined in /lib/lsb/init-functions): If there is no local daemon with a given search path running, then it returns the PIDs the daemons running in the LXC containers. AFAICT this affects the startup scripts of apache2 opensmtpd rpcbind and maybe others. #888743 Is this just me? Can anybody reproduce? Regards Harri
Re: /lib/lsb/init-functions on LXC servers
Hi Reco, you mean this is a known issue??? Harri
Re: /lib/lsb/init-functions on LXC servers
Hi Reco, wrt "pgrep --ns 1 -f /usr/sbin/sshd": The executable path simply doesn't tell if this is the right service to stop. If I run 2 services in parallel (e.g. for different network interfaces), then this approach is already broken. Sample: # pgrep --ns 1 -f /usr/sbin/sshd 12602 # ps -ef | grep ssh[d] root 126021 0 Feb02 ?00:00:20 /usr/sbin/sshd -D # /usr/sbin/sshd -p # pgrep --ns 1 -f /usr/sbin/sshd 1933 12602 IMHO pidofproc (and hence the startup scripts) should rely upon not loosing important information (the pid file). Regards Harri
Re: /lib/lsb/init-functions on LXC servers
Hi Reco, On 02/14/18 14:55, Reco wrote: True. There's one tiny bit though - try pidof -o %PPID -x /usr/sbin/sshd and watch it output several pids as well. Yes, indeed. If pidofproc would rely upon the pidfile only, then there is no reason to call pidof. And you don't have to spawn yet another sshd, a simple ssh login will suffice. This was just an example to show how easy it is to break the pgrep approach. This particular part of pidofproc does not use pidof to get pid. It uses pidof to guess the status of the process. Indeed. /bin/pidof returns the process id of the service running in a container, if the local service is not running. pidofproc assumes it is running, even though there is no local pidfile. 2 bad things can happen here: - the service in the container is killed - the service on the host is not started Using "/bin/pidof -c" the "foreign" root directory in the container is detected and pidofproc returns less false positives, AFAICT. I tried this on my servers in the office. RedHat EL uses "pidof -c" as well, check /etc/rc.d/init.d/functions . I didn't examine other Linux distros. In the case of sshd pidofproc can break in a funny way indeed. IMHO pidofproc (and hence the startup scripts) should rely upon not loosing important information (the pid file). True, but that particular part haven't wrote itself, someone did it on purpose. I don't want to blame anybody, but I would like to get this fixed. "pidof -c" does an additional check to verify the PID to return, so this seems to be a safe workaround without introducing pgrep. Regards Harri
how to view config file changes without running an upgrade?
Hi folks, How can I view the diffs between my local modified config file (maybe modified 2 years ago) and the maintainer's config file included in the currently installed package or in a pending package upgrade? I would like to review my diffs, before running "apt upgrade". I am a big fan of etckeeper, but it cannot help in this case: It looses track of the unmodified config files included with new package versions. Regards Harri
Re: how to view config file changes without running an upgrade?
On 03/21/18 12:44, The Wanderer wrote:
On 2018-03-21 at 04:13, Harald Dunkel wrote:
So... are you entirely sure that you even need to check it *before*
initiating the upgrade? The mid-upgrade prompt might be enough.
Yes, I am sure.
Its pretty painful to resolve config file conflicts in (lets say)
dovecot at upgrade time, putting EMail access for +200 users at risk.
I have to check in advance. Resolving config file conflicts during
the upgrade is too late.
If so, the only way of doing so that I can think of would be to get the
source of the relevant version of the relevant package ('apt-get source
packagename') and look at the copy of the relevant file from under that
source tree. (And possibly check for the presence of scripts that might
automatically modify that during the package build, or even during the
preinst, but I would expect that such a situation would be rare.)
Now your assumption is that I know in advance, which packages produce a
conflict. I cannot tell.
To check I would like to run something like
checkconfig xyz.deb
after download, but before upgrade of package xyz.
Of course I could open the deb file, grab all config files and diff them
with the installed version. But it would be very nice to get an "official"
tool for this.
Regards
Harri
Re: how to view config file changes without running an upgrade?
PS: Please note that there are 2 "branches" of config file we work with: - the "orig" config files included in the *.deb file - the local config files active on the server Both branches might change over time, so manually backing up a config file to *.orig at first time modification doesn't really help. Its easy to forget, and the *.orig file is not maintained during package upgrades. Regards Harri
Re: how to view config file changes without running an upgrade?
On 03/21/18 17:18, Greg Wooledge wrote: On Wed, Mar 21, 2018 at 04:46:16PM +0100, Harald Dunkel wrote: Its pretty painful to resolve config file conflicts in (lets say) dovecot at upgrade time, putting EMail access for +200 users at risk. I have to check in advance. Resolving config file conflicts during the upgrade is too late. Then you need a second system, to test the upgrades on. If you don't keep one around at all times, then you could create one on the fly with debootstrap, rsync your current configs into it, and test the upgrade in there. We have tons of stage systems. EMail stage systems are especially painful. They are constantly out of sync to the production host, making it even more necessary to review the diffs between the config files in the most recent packages and the installed files *before* running an upgrade. Dovecot was just an example, anyway. Regards Harri
bzflag is slow since nvidia-graphics-drivers 390.59-1
Hi folks, after the upgrade of nvidia-graphics-drivers to version 390.59-1 bzflag seems to use mesa instead of the nvidia libs. Running dpkg-reconfigure glx-alternative-nvidia doesn't help. Other games (e.g. tuxracer) are fine, so I wonder WTH? I haven't found the problem yet. Every helpful comment is highly appreciated. Harri
howto avoid "apt-get update" going guru?
Hi folks, this morning I found "apt-get update" getting stuck due to an unresponsive host: # cat /etc/apt/sources.list deb http://ftp.debian.org/debian sid main contrib non-free deb-src http://ftp.debian.org/debian sid main contrib non-free # apt-get update Err:1 http://ftp.debian.org/debian sid InRelease Could not connect to klecker-ftp.debian.org:80 (130.89.148.12), connection timed out [IP: 2001:6b0:e:2018::173 80] Reading package lists... Done W: Failed to fetch http://ftp.debian.org/debian/dists/sid/InRelease Could not connect to klecker-ftp.debian.org:80 (130.89.148.12), connection timed out [IP: 2001:6b0:e:2018::173 80] W: Some index files failed to download. They have been ignored, or old ones used instead. I didn't mention klecker-ftp anywhere in my config files. Its not on the round-robin list for ftp.debian.org either: # host ftp.debian.org ftp.debian.org has address 130.239.18.173 ftp.debian.org has address 130.239.18.165 ftp.debian.org has IPv6 address 2001:6b0:e:2018::165 ftp.debian.org has IPv6 address 2001:6b0:e:2018::173 ftp.debian.org mail is handled by 0 . What would you suggest to avoid this kind of problem? Every helpful comment is highly appreciated. Regards Harri
/etc/network/interfaces: create bridge without IP address?
Hi folks, how can I define a bridge in /etc/network/interfaces without assigning it an IP address and netmask? It is supposed to be IPv6 link-layer only. Regards Harri
Re: /etc/network/interfaces: create bridge without IP address?
On 12/29/2016 11:49 AM, Reco wrote: > > auto br0 > iface br0 inet6 auto > bridge-ports ... > bridge-maxwait 0 > > Please note that you have to specify *something* in 'bridge-ports' > stanza. > Thanx, I was too blind to see. Regards Harri
how to deploy common ssh_config and sshd_config settings on all hosts?
Hi folks, Problem: Deploying a custom ssh authentication scheme common to all Debian hosts in the lan appears to be apita, esp. since the next openssh upgrade might put the default config files upside down again. What would you consider best practice to keep your ssh hosts (>300) in sync wrt the most important config optiones? openssh is version 7.4 Every helpful response is highly appreciated Harri
Re: how to deploy common ssh_config and sshd_config settings on all hosts?
Hi Andy, On 02/02/17 11:17, Andy Smith wrote: > > Also through the use of override config files that are included into > the main config file, you can avoid being prompted about changes to > the main config file. For sshd the config directive is "Include". > Are you sure about this? root@jessie2:/etc/ssh# /usr/sbin/sshd -d /etc/ssh/sshd_config: line 90: Bad configuration option: Include /etc/ssh/sshd_config: terminating, 1 bad configuration options >> What would you consider best practice to keep your ssh hosts (>300) >> in sync wrt the most important config optiones? > > This is a classic use case for configuration management. You define > your configuration externally, in one authoritative place, and the > config management system takes care of applying that config to all > your hosts. Exactly. The central place in my case is a debian source package. It provides binary meta-packages referencing other packages and some /etc/service.d/local.conf files, extending the ususal /etc/service.conf files provided by the service's binary package. Please check the output of "find /etc -name \*.d" on your favorite Debian box to see *how* wide this "Include" approach is in use. You don't even imagine a package not supporting it. Unfortunately openssh-server doesn't. > > Popular examples are Puppet, Ansible and Chef, all of which are > well-supported on Debian. To decide which is best for you will > require some independent research as this is a big topic area and > hard to generalise. > They are supported on Debian, but are they supported *by* Debian as well? Won't I have to expect conflicts with Debian's dpkg infrastructure? Of course I will look into the config management tools you suggested. Thanx very much for your detailed response Harri
Re: how to deploy common ssh_config and sshd_config settings on all hosts?
Hi Andy, On 02/02/17 17:43, Andy Smith wrote: > Hi Harald, > > On Thu, Feb 02, 2017 at 02:50:09PM +0100, Harald Dunkel wrote: >> >> Exactly. The central place in my case is a debian source package. It >> provides binary meta-packages referencing other packages and some >> /etc/service.d/local.conf files, extending the ususal /etc/service.conf >> files provided by the service's binary package. > > If you are making your own Debian packages with all of your custom > config already in them, then you could just put them in your own apt > repository and point all your machines there. But you must have > already thought of this so there must be some reason why that > solution is not acceptable… > I already have these common packages in a local repository. They Provide some common config settings, e.g. for exim4, rsyslog, logrotate, local certificates, fonts, etc. Most important: They depend on and recommend large lists of packages, helping to keep all hosts in sync. For openssh I have the problem that I can only override the whole ssh_config and sshd_config files. I cannot *extend* them. I had hoped to avoid the dpkg-divert. Regards Harri
how to override a conffile (not using dpkg-divert)?
Hi folks, https://www.debian.org/doc/debian-policy/ap-pkg-diversions.html says "Do not attempt to divert a conffile, as dpkg does not handle it well." So I wonder what would you suggest to override a conffile (e.g. /etc/ssh/sshd_conf and /etc/ssh/ssh_conf) from another package depending upon the "conffile owner"? Is it safe to ignore this warning? Regards Harri
Re: how to override a conffile (not using dpkg-divert)?
Hi Don, On 02/08/17 23:36, Don Armstrong wrote: > > If this is a private package which you are using to enforce your local > configuration, just change the conffile in your postinst [possibly after > checking that the conffile hasn't been modified.] > This can become pretty difficult, depending upon the config file format (*.xml, *.json, ...). Not to mention the config file conflicts on the next upgrade, even if the DM changed only a single comment line. Plus there is no notification to run my postinst script again. > If this is a package which you are planning on having anyone else use, > then you basically shouldn't be touching /etc/ssh/ssh_config or > /etc/ssh/sshd_config, because you're likely to break things horribly. > I am sorry, but "shouldn't" is not an option. I have to make sure that the host configuration follows certain rules on all machines, e.g. for introducing signed host certificates for sshd, for the ldap/kerberos integration, etc. Of course we all try to not "break things horribly". A working divert for config files is missing in Debian. Thanx very much for your response Harri
how to compute predictable network interface names?
Hi folks, I understand that the predictable nic names can be turned off using net.ifnames=0 on the kernel command line, but I wonder if there is a shell script to actually predict the "enpYsZ" from the old style "ethX" initially assigned by the kernel? Something like % predict_nic eth4 enp12s1 There are some recipes I found on the net, but they all appear questionable or "this_vendor systems only" or work only for X=0 or look just like some attempt to start yet another flame war. Parsing dmesg output seems to be the most stable solution I found by now. Every helpful comment is highly appreciated. Regards Harri
Re: how to compute predictable network interface names?
On 02/16/2017 12:47 PM, Christian Seiler wrote: > > On a system with predictable names running? Or on a system > pre-upgrade? > Its more "pre-installation". I boot a USB stick and run my own installer (using debootstrap or creating a clone). The NIC name is needed to setup /etc/network/interfaces. I know how the interfaces are named using the old scheme, but the predictable names are hard to guess. > Because if you have a system that's being upgraded at the > moment, the following command _might_ work _after_ you've > upgraded udev and _before_ you've rebooted the system. > > udevadm info /sys/class/net/eth4 > > Look at ID_NET_NAME there. > I found 3 for eth0 on my desktop PC: E: ID_NET_NAME_MAC=enx54bef70930bd E: ID_NET_NAME_ONBOARD=eno1 E: ID_NET_NAME_PATH=enp0s25 For a server with 6 NICs I got for eth4 E: ID_NET_NAME_MAC=enx0cc47a860566 E: ID_NET_NAME_PATH=enp4s0f2 E: ID_NET_NAME_SLOT=ens261f2 A wild guess would be it is "ID_NET_NAME_PATH" unless there is a "ID_NET_NAME_ONBOARD" ? I understand that this is the fragile part. Nice tip, thanx very much Harri
Re: how to compute predictable network interface names?
On 02/23/2017 04:25 PM, Christian Seiler wrote: > > There's a policy which are going to be preferred. man 5 systemd.link > tells you what the options are and /lib/systemd/network/99-default.link > tells you what the default setting is (the first successful one is > used). Of course I stumbled over this one: % man 5 systemd.link No manual entry for systemd.link in section 5 Now I got confused: Who is responsible for renaming the NIC names? Is this a systemd feature, is this the job of udev, or are the NICs renamed by the kernel very early at boot time? Shouldn't I get the same predictable name for eth0, no matter what? > On my Stretch system that is: > > NamePolicy=kernel database onboard slot path > AFAIU NamePolicy=kernel makes sure that net.ifnames=0 given on the kernel command line works. Is this correct? > 'kernel' and 'database' are likely going to fail in most cases (kernel > means the kernel indicates that the name used so far is already > predictable, which it only does for very special hardware, probably > embedded or similar, and database means that there's an entry in the > udev hardware database, which you'd have to do manually, because I > don't know of any upstream rules), so basically it's the following > logic: > > - first try ID_NET_NAME_ONBOARD > - if that doesn't exist, try ID_NET_NAME_SLOT > - if that doesn't exist, try ID_NET_NAME_PATH > Not to forget - if that doesn't exist, use INTERFACE Thanx very much for your detailed response. Harri
Re: how to compute predictable network interface names?
On 02/24/2017 10:10 AM, Harald Dunkel wrote: > > Now I got confused: Who is responsible for renaming the NIC names? > Is this a systemd feature, is this the job of udev, or are the NICs > renamed by the kernel very early at boot time? Shouldn't I get the > same predictable name for eth0, no matter what? > PS: Assuming the hardware isn't changed, of course. Harri
upgraded config files in /lib/systemd/system
Hi folks, short question about /lib/systemd/system: AFAICS the config files here are supposed to be overridden by local config files in /etc/systemd/system, using the same path, as described in systemd.unit(5) How can I make sure that there is a conflict dialog at upgrade time, if I have to modify the unit file shipped with my package? Regards Harri
Re: upgraded config files in /lib/systemd/system
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/28/17 15:23, Dominique Dumont wrote: > > I don't understand why a change in /lib/systemd/system should trigger a > conflict warning. > A unit file provided by the package maintainer might introduce new dependencies, for example. Maybe an ExecStart or ExecStop script has been changed, or there are new/different command line options. I don't think that conflicts between the user's old modified unit files in /etc and the new packages unit files are easy to avoid. > Either you have changed a value not modified by end user and there's no > conflict > > Or you change a value overridden by user, then your change is not taken into > account by systemd: conflict is solved by giving priority to user value. > Sorry to say, but this doesn't solve anything. It just hides the conflict. I understand that this hasn't been taken into account, but it should be considered for Buster. Regards Harri -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEH2V614LbR/u1O+a1Cp4qnmbTgcsFAli8azMACgkQCp4qnmbT gcvwagf+PU2QI2/0MPflk2JiN/Y+Y6jwH4KwhceqUQAZQi43zDJnB2C8a1HlJj+/ k/U/qoPNoBExqo2MW3OoaVg6Gr1SYs0fhs6kDge0vE/nZ+C8g+KCaDJNpkxlL8Yl KgSViwuGCFWEnWJDGRs3zGgIFAD4EPIqlSN4Ap5wOuAZ6OSDakmBRtePZSdIc0G9 ea6mkhc68KhITi8aoe6FlTdjW+nqX2jezsMr0HyZfjZsPXztOpS+EIdhH27afudt JxE1g9P36dDOHmTM75A1J5xCmJv/LwY00vvMzooaKhvy5vOrpmI5XOmWq51EyjwW Blt4hqxXVivb8Y4DfEEvXSdwtfgZBQ== =S+mQ -END PGP SIGNATURE-
Re: how to compute predictable network interface names?
Hi Christian, On 02/24/17 12:43, Christian Seiler wrote: > > udev will then rename the device once it encounters it. > > In newer udev versions, it will use some (but not all) settings from > systemd.link files. The other settings are interpreted by > systemd.networkd. (And if you don't use that or don't have that > installed, they will be ignored.) That's also the reasnon why those > files are in a systemd directory, even though udev interprets some > parts of them - since the matching of interfaces is identical for > the purposes of udev and systemd-networkd, systemd developers decided > it would be simpler to have just one configuration file that is read > by both. (udev and systemd are both in the same repository, even > though you can use udev without systemd.) > Thats a bad choice. Now the man page is not installed on "udev-only" systems, because the package maintainer recognized it as a "systemd" man page. #857270 > > No. net.ifnames=0 will have udev completely ignore NamePolicy here > and not rename the interface at all. > Is there a policy option telling udev/systemd to not touch the interface names? AFAIU that should be easy to implement, but there is no "NamePolicy=keep" described in systemd.link(5) (or I was too blind to see). Regards Harri
Re: upgraded config files in /lib/systemd/system
On 03/05/17 21:29, Michael Biebl wrote: > > Keep in mind, that in most cases you don't need to override the package > provided service file completely by making a full copy of it in > /etc/systemd/system > > You can extend/override individual bits via drop-in files (e.g. adding > additional dependencies/orderings). For a service foo.service you create > > /etc/systemd/system/foo.service.d/bla.conf > The name is arbitrary, you just need to make sure it has a .conf extension. > > Fwiw, systemctl edit (--full) foo.service can help you with that > > https://www.freedesktop.org/software/systemd/man/systemctl.html#edit%20NAME%E2%80%A6 > This is nice to have, but please remember that config options accumulate for systemd.unit files. You still need /etc/systemd/\ system/foo.service to reliably override /lib/systemd/system/\ foo.service. Since Debian already has a scheme to handle conflicts in config files on an upgrade, I wonder why there is such a high refusal to use it in this case? If the config wasn't changed or if there are just some files in /etc/systemd/system/foo.service.d, then this would be a noop. But *if* there is a conflict, then the usual dialog should be brought up, as for all other config files. > This is new in stretch, jessie's systemctl doesn't have that yet. > Focusing on Stretch or Buster is fine with me. Regards Harri
iscsi support in Jessie
Hi folks, Some years ago I have setup an iscsi target using targetcli 2.0 on Wheezy. Actually it works pretty well, but there were some serious upgrade problems to 2.1 and 3.0, making targetcli go away for Jessie. See #764005 and #751226. I lost confidence in a newer version. Now I have to install a new iscsi target (using Jessie, hopefully). Which iscsi solution would you recommend? Regards Harri
Re: iscsi support in Jessie
On 10/16/15 08:06, Harald Dunkel wrote: > Hi folks, > > Now I have to install a new iscsi target (using Jessie, hopefully). > Which iscsi solution would you recommend? > PS: Here is what I found so far: * iSCSI Enterprise Target (http://sourceforge.net/projects/iscsitarget/files/) looking at the dev mailing list it appears to be dead * Linux-iSCSI Project replaced by http://open-iscsi.org/ , afaict. * open-iscsi.org appears to be dead. 404 on the mailing list. Last stable version is of May 2012 * targetcli dropped from Jessie. Old version 2.1 is still in RHEL7. * Generic SCSI Target Subsystem http://scst.sourceforge.net/ Looks promising, but there are only Debian packages provided by upstream, and they are already 2 years old. Did I miss something (other than FreeNAS)? What would you recommend? Regards Harri
Re: iscsi support in Jessie
Hi Reco, On 10/16/15 08:17, Reco wrote: > > tgt works for me in Jessie. I would not call it that user-friendly, though. > Not bad. I have missed this one. Searching for tgt I stumbled over istgt. (http://shell.peach.ne.jp/aoyama/archives/3122). Thanx very much Harri
Re: Can't startx as normal user
If you are using startx/xinit: Try installing xserver-xorg-legacy. I had the same problem. Good luck Harri
which display manager would you suggest for Stretch?
Hi folks, since kdm is not in anymore I wonder which display manager to consider for Stretch? No assumption about the desktop environment should be made. The local Debian users are free to choose. Of course I saw https://wiki.debian.org/DisplayManager, but it appears to be out-of-date. And it doesn't give a recommendation. Every helpful comment is highly appreciated Harri
Upgrade to 12.3 fails due to missing nvidia firmware package
Hi folks, I have tried to upgrade to 12.3, but apparently the dependencies of the new nvidia-kernel-dkms version cannot be fulfilled. firmware-nvidia-gsp (= 525.147.05) is missing. I tried several repositories. Hopefully I am not too blind to find the bug report (the new version fixes a CVE, ie details might not have been disclosed), so I wonder what is the story here? Regards Harri
Re: Upgrade to 12.3 fails due to missing nvidia firmware package
On 2023-12-06 15:55:58, Michael Kjörling wrote: Which ones? ftp.de.debian.org ftp2.de.debian.org deb.debian.org That package is in the non-free-firmware component; are you bringing that in? https://packages.debian.org/bookworm/firmware-nvidia-gsp There is still the old version 525.125.06-1~deb12u1 on this page. Expected is version 525.147.05.
Re: Upgrade to 12.3 fails due to missing nvidia firmware package
On 2023-12-06 17:20:16, Sven Joachim wrote: Maintainer uploads to (old)stable are staged in proposed-updates, so you would have to enable bookworm-proposed-updates to install the new version of firmware-nvidia-gsp. I missed the non-free-firmware for bookworm-updates and bookworm-proposed-updates. My bad, sorry. Thank you for your help Regards Harri
which keyring to install to access jessie archive?
Hi folks, apparently the jessie archive repository is still alive, but if I try to update the package list there is an error message W: GPG error: http://archive.debian.org/debian jessie Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 8B48AD6246925553 NO_PUBKEY 7638D0442B90D010 NO_PUBKEY CBF8D6FD518E17E1 I tried installing debian-archive-keyring_2017.5~deb8u1_all.deb debian-archive-keyring_2019.1+deb10u1_all.deb debian-archive-keyring_2021.1.1+deb11u1_all.deb debian-archive-keyring_2023.4_all.deb but neither provides the missing keys. Which debian keyring packages do I have to install to verify Debian packages from the archive repositories? Regards Harri
openexr-viewers in Bookworm?
Hi folks, I wonder why openexr-viewers hasn't made it into Bookworm, yet? The bug tracker mentions just an ancient SIGSEGV (opened in 2010). ? https://packages.debian.org/source/sid/openexr-viewers Regards Harri
Re: openexr-viewers in Bookworm?
Found it, it doesn't build (#1017547). Its been filed against the source package. Regards Harri
apache2: fix the regressions introduced by security upgrade in Bullseye?
Hi folks, AFAIU apache2 2.4.56-1 has been included in Bullseye to mitigate CVE-2023-27522 and CVE-2023-25690 (both some mod_proxy issue with high severity). Good thing. Unfortunately this introduced 2 regressions for mod_rewrite and http2, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033284 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1033408 https://metadata.ftp-master.debian.org/changelogs//main/a/apache2/apache2_2.4.56-2_changelog Would it be possible to fix the upgrade? I can turn off http2, but I feel *very* bad about running an apache with a broken mod_rewrite in production. Thank you very much Harri
Re: apache2: fix the regressions introduced by security upgrade in Bullseye?
On 2023-04-03 14:49:16, Vincent Lefevre wrote: What about apache2 2.4.56-2? This version is not in Bullseye. Only 2.4.56-1, introducing the regressions.
override logrotate.timer from another package?
Hi folks, what is the recommended way to override logrotate.timer from a metapackage to get hourly logfile rotation (depending on size and age of the logfile, as usual)? I had added etc/systemd/system/logrotate.timer.d/hourly.conf to the package install file, but at upgrade time it complained that nobody ran systemctl daemon-reload. Ain't this the job of the DEBHELPER macro in the postinst script? Should this file be installed in /lib/systemd/system/logrotate.timer.d instead, using dh_installsystemd ? Every insightful is highly appreciated Harri
Re: override logrotate.timer from another package?
On 2023-07-04 14:36:19, Charles Curley wrote: No. All changes the local administrator makes should go under /etc/systemd because you risk updates over-writing things in /lib/systemd and elsewhere. As for dh_installsystemd, the first paragraph of the man page for it says, dh_installsystemd is a debhelper program that is responsible for installing package maintainer supplied systemd unit files. Are you doing this as a package maintainer? Yes. Its my own metapackage to be installed on all our hosts in the office to establish certain configuration standards, like hourly log file rotation, our own certificates, a standard set of packages to be installed, etc. Actually I've got a set of about 50 metapackages for Debian by now, describing development hosts, laptop setups, virtualization servers, different GUI configurations, VPNs, and so on. This could have been done by ansible or others as well, but when I started this there was no ansible. Point is, if I add a config file to /etc/systemd/system/logrotate.timer.d using my own package, then it seems to be off-limits somehow. The daemon-reload is not run, and systemctl revert logrotate.timer will wipe out the file provided by my package as well, without confirmation dialog. That doesn't seem right. Regards Harri
Re: override logrotate.timer from another package?
Hi Tim, On 2023-07-04 19:35:35, Tim Woodall wrote: On Tue, 4 Jul 2023, Harald Dunkel wrote: I'm not exactly clear what you're doing but I guess you're creating a package that provides the config file? Yes, together with other things (other config files, package depen- dencies, etc). Others would probably say use ansible (or something like that) but it works for me. to the package install file, but at upgrade time it complained that nobody ran systemctl daemon-reload. Ain't this the job of the DEBHELPER macro in the postinst script? Once your package is installed, what does the postinst script look like? It looks like this #!/bin/bash -e : # some bash function definitions : case "$1" in configure) set_distro set_debconf_defaults adjust_ssh_config adjust_sshd_config adjust_login_defs cleanup_logrotate cleanup_old_garbage systemctl daemon-reload || echo ignored ;; abort-upgrade|abort-remove|abort-deconfigure) ;; triggered) cleanup_logrotate ;; *) echo "postinst called with unknown argument \`$1'" >&2 exit 1 ;; esac #DEBHELPER# exit 0 I had expected the systemctl daemon-reload is added by DEBHELPER, but it isn't. Should this file be installed in /lib/systemd/system/logrotate.timer.d instead, using dh_installsystemd ? Assuming you are creating a package and you want to share it with possible local edits in /etc then this would be the way to go. If, like me, you're using a package in place of manually editing then /etc is more likely the right place. Thank you very much for your detailed reply. I will try to override logrotate.timer in /lib, as you suggested. Regards Harri
which dput/method to chose for automatic uploads via cron?
Hi folks, which dput/method would you suggest for uploading packages to a private repo via ssh? By now I tried - dput/rsyncfails to upload files in a reproducible sequence, breaking inoticoming on the receiver side - dput/scp "permission denied", ssh_config_options appear to be ignored - dput/sftp doesn't exist - dput-ng/scp ignores ssh_config_options - dput-ng/sftp works fine on the command line, but dies with "Failed to auth" in cron scripts. - dput-ng/rsync doesn't exist I have to use a dedicated key pair for dput via ssh, ie. IdentityFile=~/.ssh/id/id_ecdsa.debian IdentitiesOnly=yes are mandatory. Every helpful comment is highly appreciated. Harri
how to downgrade nvidia-graphics-drivers packages?
Hi folks, Looking at a set of installed binary packages built from the same source package, I would like to keep the version numbers consistent. There might be exceptions, but in general you won't like to mix unstable and experimental binary packages from the nvidia-graphics-drivers, for example. Question is, how can I tell apt to avoid mixing version numbers? Regards Harri
packages.debian.org seems to be down
Hi folks, is it just me, or is https://packages.debian.org/ down? I had a similar problem yesterday morning. Regards Harri
distribution archives became unusable
Hi folks, the repositories listed on https://www.debian.org/distrib/archive have been signed using expired keys. Unfortunately this page doesn't deal with this problem. Do you think this could be improved? Regards Harri
sanity check for /etc/ssl/certs?
Hi folks, is there a sanity check for /etc/ssl/certs included in Bookworm? I've got one host with some missing symlinks in this directory, eg. root@dpcl064:/etc/ssl/certs# ls -al *SSL.com* ls: cannot access '*SSL.com*': No such file or directory Other hosts show root@dpcl082:/etc/ssl/certs# ls -al *SSL.com* lrwxrwxrwx 1 root root 82 Jul 16 2018 SSL.com_EV_Root_Certification_Authority_ECC.pem -> /usr/share/ca-certificates/mozilla/SSL.com_EV_Root_Certification_Authority_ECC.crt lrwxrwxrwx 1 root root 85 Jul 16 2018 SSL.com_EV_Root_Certification_Authority_RSA_R2.pem -> /usr/share/ca-certificates/mozilla/SSL.com_EV_Root_Certification_Authority_RSA_R2.crt lrwxrwxrwx 1 root root 79 Jul 16 2018 SSL.com_Root_Certification_Authority_ECC.pem -> /usr/share/ca-certificates/mozilla/SSL.com_Root_Certification_Authority_ECC.crt lrwxrwxrwx 1 root root 79 Jul 16 2018 SSL.com_Root_Certification_Authority_RSA.pem -> /usr/share/ca-certificates/mozilla/SSL.com_Root_Certification_Authority_RSA.crt The files in /usr/share/ca-certificates are available, of course. The access rights seem OK. update-ca-certificates or reinstalling ca-certificates (with overwrite) didn't solve this problem. Every helpful comment is highly appreciated. Harri
