Bug#985422: syslog-ng-core: fails to capture all systemd-journal entries
Package: syslog-ng-core Version: 3.19.1-5 Severity: important Dear Maintainer, The Debian syslog-ng package is not collecting all systemd-journal messages. The use case that caused me to track this down is an inconsistency between the Debian syslog-ng and rsyslog packages when logging Knot DNS activity (using the 'knot' package from upstream https://deb.knot-dns.cz/knot-latest/). A default install of rsyslog captures Knot's logging activity to /var/log/user.log, while a default install of syslog-ng does not capture its activity at all. The default syslog-ng configuration should log the same messages to /var/log/user.log, but it seems syslog-ng doesn't even see the log messages. Digging a bit deeper .. journald.conf(5) indicates that syslog messages are written to /run/systemd/journal/syslog. I noted that syslog-ng does not create this socket, while rsyslog does. There is a comment in syslog.socket which indicates a syslog daemon is expected to include "Alias=syslog.service" in its [install] section in order to pull in this dependency. The rsyslog package does this, but the syslog-ng package does not. It seems likely this is related to the issues with capturing syslog messages. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages syslog-ng-core depends on: ii libc6 2.28-10 ii libcap21:2.25-2 ii libcurl4 7.64.0-4+deb10u1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libivykis0 0.42.3-1 ii libjson-c3 0.12.1+ds-2+deb10u1 ii libnet11.1.6+dfsg-3.1 ii libpcre3 2:8.39-12 ii libssl1.1 1.1.1d-0+deb10u5 ii libsystemd0241-7~deb10u6 ii libuuid1 2.33.1-0.1 ii libwrap0 7.6.q-28 ii lsb-base 10.2019051400 ii syslog-ng-mod-journal 3.19.1-5 ii util-linux 2.33.1-0.1 Versions of packages syslog-ng-core recommends: ii logrotate 3.14.0-4 Versions of packages syslog-ng-core suggests: ii syslog-ng-mod-add-contextual-data 3.19.1-5 ii syslog-ng-mod-amqp 3.19.1-5 ii syslog-ng-mod-examples 3.19.1-5 ii syslog-ng-mod-extra3.19.1-5 ii syslog-ng-mod-geoip3.19.1-5 ii syslog-ng-mod-geoip2 3.19.1-5 ii syslog-ng-mod-getent 3.19.1-5 ii syslog-ng-mod-graphite 3.19.1-5 ii syslog-ng-mod-map-value-pairs 3.19.1-5 ii syslog-ng-mod-mongodb 3.19.1-5 ii syslog-ng-mod-pacctformat 3.19.1-5 ii syslog-ng-mod-python 3.19.1-5 ii syslog-ng-mod-redis3.19.1-5 ii syslog-ng-mod-riemann 3.19.1-5 ii syslog-ng-mod-smtp 3.19.1-5 ii syslog-ng-mod-snmptrapd-parser 3.19.1-5 ii syslog-ng-mod-sql 3.19.1-5 ii syslog-ng-mod-stardate 3.19.1-5 ii syslog-ng-mod-stomp3.19.1-5 ii syslog-ng-mod-tag-parser 3.19.1-5 ii syslog-ng-mod-xml-parser 3.19.1-5 -- no debconf information
Bug#984602: fai-setup: mid-export newlines in /etc/exports
On Sat, 6 Mar 2021 at 05:16, Thomas Lange wrote: > > >>>>> On Fri, 05 Mar 2021 17:58:26 +0000, Matthew Pounsett > >>>>> said: > > I've made a change in fai-setup to determine the IP of the first > interface, but this seems to fail with multiple interfaces > Can you please provide the output of this command: > ip -br ad show | awk '{print $3}' Sure (indenting mine): % ip -br ad show | awk '{print $3}' 127.0.0.1/8 172.16.2.2/30 64.191.0.64/24 192.168.1.64/24 192.168.0.64/24 fe80::fc54:ff:fe78:7dd0/64 fe80::fc54:ff:fe48:106e/64 fe80::fc54:ff:fece:417f/64 If you're using that, you lose information, though. For example, the only IPv6 addresses you're getting are link-local. Here's the full output of that command without restricting it to a single column: % ip -br ad show lo UNKNOWN127.0.0.1/8 ::1/128 eno1 UP eno2 UP eno3 DOWN eno4 UP 172.16.2.2/30 fe80::baca:3aff:fef3:7bac/64 enp68s0 UP br0 UP 64.191.0.64/24 64.191.0.132/24 2620:ff:c000::132/64 2620:ff:c000::64/64 fe80::baca:3aff:fef3:7ba9/64 br1 UP 192.168.1.64/24 fe80::baca:3aff:fef3:7baa/64 br2 UP 192.168.0.64/24 fe80::260:ddff:fe43:99fb/64 vnet0UNKNOWNfe80::fc54:ff:fe78:7dd0/64 vnet1UNKNOWNfe80::fc54:ff:fe48:106e/64 vnet2UNKNOWNfe80::fc54:ff:fece:417f/64 To strip that down, you probably want something more like the output of this: % ip -br ad show | tr -s '[:blank:]' ' ' | cut -d' ' -f 3- Since a server may have multiple addresses in the same subnet, you may also want to de-dupe the output before using it. > > Which is the expected interface you want to use in /etc/exports? That would be system dependent. I would suggest that what fai-setup should do by default depends on your intentions. Do you want this to just be an example, or should it be more like a functional default? If it's the former, then I'd grab the first IPv4 and IPv6 subnets you find that are not 127/8 (for v4) or link-local (for v6). If you want it to be fully functional, then I would grab all such netblocks. Keeping in mind that the main issue I'm reporting here is a problem with /etc/exports syntax, not with the netblock selection. The man page for exports(5) is a little imprecise on this point ... an export's client list *is* whitespace delimited, and newlines are ignored, but newlines in the client list seem to be fatal. This implies they are not ignored mid-export and are not included in this definition of "whitespace". But, if you're looking at improving netblock selection as well, my advice would be to grab all v4 netblocks not in 127/8 and all non-link-local v6 blocks. > A workaround is to set the variable SERVERINTERFACE in > /etc/fai/nfsroot.conf. See nfsroot.conf(5) I think if that's a thing that needs to be done to get fai-server to generate valid /etc/exports syntax you should probably mention it in the docs. My personal workaround is just to fix the syntax of the exports file after fai-setup writes it.
Bug#984602: fai-setup: mid-export newlines in /etc/exports
Package: fai-server Version: 5.10 Severity: normal Dear Maintainer, I'm a new user of FAI. I've run a few test setups on VMs and am in the process of doing the first install on a production server, prepping to build real installs. This didn't crop up on single-interface VMs, but in production I've run into a problem with priming of the /etc/exports file, triggered by the presence of multiple interface and IP protocols on the server. At the end of the run of `fai-setup -v`, the nfs-server fails to load, and it appears the cause is that it is either failing to strip newlines when it obtains the server IP addresses, or is erroneously inserting newlines, when it constructs the exports entries. For example (indenting added by me, newlines added by fai-setup): /srv/fai/config 127.0.0.1/8 172.16.2.2/30 64.191.0.64/24 192.168.1.64/24 192.168.0.64/24 fe80::fc54:ff:fe78:7dd0/64 fe80::fc54:ff:fe48:106e/64 fe80::fc54:ff:fece:417f/64(async,ro,no_subtree_check) This causes nfs-server.service to fail to start. Correcting this is an easy problem to solve (remove the newlines) but a newbie to NFS might take a while to figure that out. -- System Information: Debian Release: 10.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-14-amd64 (SMP w/16 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages fai-server depends on: ii debootstrap 1.0.114 ii e2fsprogs1.44.5-1+deb10u3 ii fai-client 5.10 ii xz-utils 5.2.4-1 Versions of packages fai-server recommends: ii dosfstools4.1-2 ii isc-dhcp-server 4.4.1-2 ii libproc-daemon-perl 0.23-1 ii mtools4.0.23-1 ii nfs-kernel-server 1:1.3.4-2.5+deb10u1 ii openbsd-inetd [inet-superserver] 0.20160825-4 ii openssh-client1:7.9p1-10+deb10u2 ii openssh-server1:7.9p1-10+deb10u2 ii tftpd-hpa 5.2+20150808-1+b1 Versions of packages fai-server suggests: ii binutils 2.31.1-16 pn debmirror pn fai-setup-storage pn grub2 pn perl-tk ii qemu-utils 1:3.1+dfsg-8+deb10u8 ii reprepro 5.3.0-1 ii squashfs-tools 1:4.3-12 ii xorriso1.5.0-1 -- no debconf information