Re: Error including file in nftables.conf
On Tue, Oct 4, 2022 at 2:32 AM Anssi Saari wrote: > Dave Parker writes: > > > So, I copied /lib/systemd/system/nftables.service to > /etc/systemd/system/nftables.service, set > > ProtectHome=false, ran "systemctl daemon-reload", and now it works! > > Well, good, buy why not put configuration data in /etc instead of /root > where it belongs and keep the service as is? > > Personally I have my main or common rules in /etc/nftables.conf and have > in there include "/etc/nftables.conf.d/*" so that I can add extra input > rules for different computers. > > You're right that it probably should just go in /etc/nftables.conf. This was mostly just for testing; I had a fairly large ruleset in a file which was converted from an iptables script on another server, and instead of pasting that all into nftables.conf, I was hoping to keep it separate and use include to read it. Moving that to a location other than /root is the solution. Thanks!
Re: Error including file in nftables.conf
On Mon, Oct 3, 2022 at 5:42 PM Andy Smith wrote: > Hello, > > On Mon, Oct 03, 2022 at 05:36:19PM -0400, Greg Wooledge wrote: > > On Mon, Oct 03, 2022 at 05:01:21PM -0400, Dave Parker wrote: > > > Oct 03 16:48:55 host systemd[1]: Starting nftables... > > > Oct 03 16:48:55 host nft[926]: /etc/nftables.conf:4:1-37: Error: File > not > > > found: /root/nftables/ruleset.txt > > > > Sounds like the service might be chrooted. > > … so OP please show us > > $ systemctl cat nftables.service > > to see if there are any interesting options about restricting > access to the filesystem. > > Hello, Thanks for pointing me in the right direction. I checked the service as you suggested: -- ~# systemctl cat nftables.service # /lib/systemd/system/nftables.service [Unit] Description=nftables Documentation=man:nft(8) http://wiki.nftables.org Wants=network-pre.target Before=network-pre.target shutdown.target Conflicts=shutdown.target DefaultDependencies=no [Service] Type=oneshot RemainAfterExit=yes StandardInput=null ProtectSystem=full ProtectHome=true ExecStart=/usr/sbin/nft -f /etc/nftables.conf ExecReload=/usr/sbin/nft -f /etc/nftables.conf ExecStop=/usr/sbin/nft flush ruleset [Install] WantedBy=sysinit.target -- It turns out that the problem was the "ProtectHome=true" in the service config. According to the systemd documentation[1]: "If true, the directories /home, /root and /run/user are made inaccessible and empty for processes invoked by this unit." So, I copied /lib/systemd/system/nftables.service to /etc/systemd/system/nftables.service, set ProtectHome=false, ran "systemctl daemon-reload", and now it works! Thank you! [1] https://www.freedesktop.org/software/systemd/man/systemd.exec.html#ProtectHome= -- Dave Parker '11 Database & Systems Administrator Utica University Integrated Information Technology Services 315-792-3229 He/Him
Error including file in nftables.conf
Hi All! After using iptables for years, I'm using nftables on Debian 11 for the first time, and have encountered a weird issue which may just be due to my own lack of experience with this. FYI, I'm doing everything here as root. I have a valid ruleset stored in the file /root/nftables/ruleset.txt . When I run this, it works: nft -f - flush ruleset include "/root/nftables/ruleset.txt" I then run "nft list ruleset" and get the expected results. But when I put this in /etc/nftables.conf... #!/usr/sbin/nft -f flush ruleset include "/root/nftables/ruleset.txt" This happens... # systemctl start nftables Job for nftables.service failed because the control process exited with error code. See "systemctl status nftables.service" and "journalctl -xe" for details. # systemctl status nftables ● nftables.service - nftables Loaded: loaded (/lib/systemd/system/nftables.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2022-10-03 16:48:55 EDT; 9s ago Docs: man:nft(8) http://wiki.nftables.org Process: 926 ExecStart=/usr/sbin/nft -f /etc/nftables.conf (code=exited, status=1/FAILURE) Main PID: 926 (code=exited, status=1/FAILURE) CPU: 14ms Oct 03 16:48:55 host systemd[1]: Starting nftables... Oct 03 16:48:55 host nft[926]: /etc/nftables.conf:4:1-37: Error: File not found: /root/nftables/ruleset.txt Oct 03 16:48:55 host nft[926]: include "/root/nftables/ruleset.txt" Oct 03 16:48:55 host nft[926]: ^ Oct 03 16:48:55 host systemd[1]: nftables.service: Main process exited, code=exited, status=1/FAILURE Oct 03 16:48:55 host systemd[1]: nftables.service: Failed with result 'exit-code'. Oct 03 16:48:55 host systemd[1]: Failed to start nftables. Does anyone know why nft will load the included file manually but throws an error when doing it through systemd? Thanks! Dave -- Dave Parker '11 Database & Systems Administrator Utica University Integrated Information Technology Services 315-792-3229 He/Him
Re: Sendmail SASL Auth on Debian 11
On Tue, Sep 13, 2022 at 6:41 AM Henning Follmann wrote: > > > > > So I guess my question is, do I need one now on the Bullseye server, if > > saslauthd always worked for this before? > > > > OK, that's an option too. > > Now I would check if sasl works. There is an little helper program; try: > testsaslauthd -u -p > > you might have to specify the location (-f path) of the unix socket if it > is located > somewhere uncommon. > > If your authentication works then the communication between sendmail and > saslauthd > is not working. > Hello, The testsaslauthd utility was also working, so the break was between Sendmail and SASL. I finally got it working, though. A Google search led me to these three commands, and running them indeed fixed gthe issue: /usr/share/sendmail/update_tls /usr/share/sendmail/update_sendmail sendmailconfig All of the config and .m4 files involved here still look the same between the old and new server, with the exception of some updated comments. So, I'm not exactly sure what this did to fix the underlying problem, but it's fixed nonetheless. Thanks! Dave -- Dave Parker '11 Database & Systems Administrator Utica University Integrated Information Technology Services 315-792-3229 He/Him
Re: Sendmail SASL Auth on Debian 11
On Mon, Sep 12, 2022 at 10:37 AM Henning Follmann wrote: > > First, please do not top post. > > On Mon, Sep 12, 2022 at 09:00:00AM -0400, Dave Parker wrote: > > Thanks for the advice. Just to clarify, this is an enterprise SMTP > server > > for a university, and we have used Sendmail for at least 25 years now. I > > have deployed and configured Sendmail on probably hundreds of servers > over > > the years, but most of them are on internal networks and relay mail > > through this SMTP server. This is a high traffic SMTP server and its > > uptime is critical, so I would prefer to stay with Sendmail because it > has > > always been rock solid in the past. > > Understood. And I apologize. I assumed because of the old version of your > existing installation a less actively maintained situation and made a snap > judgement about your experience. > I also never said sendmail is not a solid MTA. I stated it is extremely > difficult to maintain. > Also other MTA are well suited for high traffic servers. Exim is used > by ISPs with extremely high traffic. > > > > > The issue here is that Sendmail with SASL auth doesn't seem to work the > > same way in Bullseye as it did in Wheezy, which is probably to be > expected, > > given the large gap between versions. I'm just trying to track down > > anything I may have missed in my new Bullseye configuration, since the > > exact same config works fine in Wheezy. > > > > Well, in my previous post I might hinted at your issue. > > Please check if courier-authdaemon or dovecot-core is installed. > Both provide an sasl authdaemon. > I do not know anything about your old installation so you have to > figure out, how and where the unix socket of the daemon is located. > If you use a chroot environment you must make sure the socket is accessible > to sendmail. > > My apologies for the top post. We use Google for our institutional email, and the Gmail interface defaults to that when I reply to a message. Looking at the existing Wheezy server which works correctly, I do not see anything providing an auth daemon besides saslauthd: # dpkg-query -W | egrep 'sendmail|sasl|courier|dovecot' libsasl2-2:amd64 2.1.25.dfsg1-6+deb7u1 libsasl2-modules:amd64 2.1.25.dfsg1-6+deb7u1 sasl2-bin 2.1.25.dfsg1-6+deb7u1 sendmail 8.14.4-4 sendmail-base 8.14.4-4 sendmail-bin 8.14.4-4 sendmail-cf 8.14.4-4 So I guess my question is, do I need one now on the Bullseye server, if saslauthd always worked for this before? Thanks, Dave -- Dave Parker '11 Database & Systems Administrator Utica University Integrated Information Technology Services 315-792-3229 He/Him
Re: Sendmail SASL Auth on Debian 11
Thanks for the advice. Just to clarify, this is an enterprise SMTP server for a university, and we have used Sendmail for at least 25 years now. I have deployed and configured Sendmail on probably hundreds of servers over the years, but most of them are on internal networks and relay mail through this SMTP server. This is a high traffic SMTP server and its uptime is critical, so I would prefer to stay with Sendmail because it has always been rock solid in the past. The issue here is that Sendmail with SASL auth doesn't seem to work the same way in Bullseye as it did in Wheezy, which is probably to be expected, given the large gap between versions. I'm just trying to track down anything I may have missed in my new Bullseye configuration, since the exact same config works fine in Wheezy. Thanks! On Mon, Sep 12, 2022 at 3:17 AM Henning Follmann wrote: > On Fri, Sep 09, 2022 at 11:55:06AM -0400, Dave Parker wrote: > > Hello, > > > > Years ago, I set up an SMTP server on Debian 7.5, running Sendmail > > configured for SASL authentication using an LDAP directory. I am now > > trying to set up a new one on Debian 11.5 in pretty much the same > > configuration, but SMTP auth does not work. I have verified that nslcd > and > > You have not "used" sendmail for several years. You should not use it. > Sendmail is very complex and extremely difficult to maintain, definetely > not > suitable for a "casual" user. > You should either use > 1) Exim (I do not like it, because it does not use standard logging. But > that > is personal taste) Its debians default. > > 2) Postfix > > I used sendmail for a decade but I switched over to Postfix years ago. > It is too hard to maintain. > > > > saslauthd are running, the sendmail, PAM and NSS configurations all look > > good, and ldapsearch returns a result using the settings from > > pam_ldap.conf. When I open a connection to the old server and issue AUTH > > PLAIN or AUTH LOGIN, I can authenticate with my base64 LDAP credentials > as > > expected. But when I do the same on the new server, I get a "535 5.7.0 > > authentication failed" response. > > > > I ran a tcpdump on this SMTP server during an auth attempt, and there was > > no traffic to or from the LDAP server. > > > > I literally copied all of the configs over from the old server and > Sendmail > > starts up fine, but still no auth. Does anyone know where I might look > for > > the breakage? > > > > Old server (works): > > - Sendmail 8.14.4 > > - SASL (libs/modules/bin) 2.1.25 > > - libnss-ldap 264 > > - libpam-ldap 184 > > > > New server (doesn't work): > > - Sendmail 8.15.2 > > - SASL (lib/modules/bin) 2.1.27 > > - libnss-ldapd 0.9.11 (because libnss-ldap is deprecated) > > - libpam-ldap 186 > > You need an external authentication daemon for sasl to work. > I guess based on the age of your old system, it was courier in your case. > > Today I would prefer dovecot. > > > > > > > Thanks! > > Dave > > > > -- > > Dave Parker '11 > > Database & Systems Administrator > > Utica University > > Integrated Information Technology Services > > 315-792-3229 > > He/Him > > -- > Henning Follmann | hfollm...@itcfollmann.com > > -- Dave Parker '11 Database & Systems Administrator Utica University Integrated Information Technology Services 315-792-3229 He/Him
Sendmail SASL Auth on Debian 11
Hello, Years ago, I set up an SMTP server on Debian 7.5, running Sendmail configured for SASL authentication using an LDAP directory. I am now trying to set up a new one on Debian 11.5 in pretty much the same configuration, but SMTP auth does not work. I have verified that nslcd and saslauthd are running, the sendmail, PAM and NSS configurations all look good, and ldapsearch returns a result using the settings from pam_ldap.conf. When I open a connection to the old server and issue AUTH PLAIN or AUTH LOGIN, I can authenticate with my base64 LDAP credentials as expected. But when I do the same on the new server, I get a "535 5.7.0 authentication failed" response. I ran a tcpdump on this SMTP server during an auth attempt, and there was no traffic to or from the LDAP server. I literally copied all of the configs over from the old server and Sendmail starts up fine, but still no auth. Does anyone know where I might look for the breakage? Old server (works): - Sendmail 8.14.4 - SASL (libs/modules/bin) 2.1.25 - libnss-ldap 264 - libpam-ldap 184 New server (doesn't work): - Sendmail 8.15.2 - SASL (lib/modules/bin) 2.1.27 - libnss-ldapd 0.9.11 (because libnss-ldap is deprecated) - libpam-ldap 186 Thanks! Dave -- Dave Parker '11 Database & Systems Administrator Utica University Integrated Information Technology Services 315-792-3229 He/Him
