Moving server from OpenBSD to FreeBSD

Jose · May 18, 2020

Zaragon said:
Does that work for sending to an actual mail account outside my LAN, though? I don't run a local mailserver and I don't generally check *any* of the local accounts on either of my *BSD servers, so forwarding it to a local user on the same box unfortunately isn't all that helpful either. And I was always under the assumption that (for example) Gmail's SMTP server would reject any attempt by a dynamic IP to forward email to it. I do have my own domain name and functioning dynamic DNS through Google Domains, if there's anything that can be configured there that would allow it to work?

Amazingly, it does seem to work. Turns out this game I'd been working on had been sending off email without me noticing. I realized it by tailing /var/log/maillog as root:

Code:

May 18 11:03:06 myhost sm-mta[1583]: 04II2x9h001479: to=<all@oddlabs.com>, ctladdr=<me@myhost.example.com> (1001/1001), delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=30395, relay=aspmx.l.google.com. [74.125.142.27], dsn=2.0.0, stat=Sent (Ok: queued as E3BE13270C)

However I do own the .com domain used, it does have a proper SPF record, and the message did go out through the proper MX host. I'm surprised that the "myhost" part didn't cause any problems, though. In any case, you can test it. Set yourself up with a tail of /var/log/maillog in one terminal, and in another other execute echo 'This is only a test' | mail -s 'This is a test' me@example.com and see if it works. You can give the "-v" option to the mail(1) command if you want verbose output on the client side.

Zaragon said:
I've never found OpenBSD's "lack of a modern filesystem" to be an issue; I've lost more data to ext2 in Linux than I ever have to UFS in OpenBSD. It's not clear to me how much better UFS is in FreeBSD because I planned to use root-on-ZFS from day one, so never looked into it. Is it that much better than OpenBSD's version? ...unless of course you're just referring to ZFS, in which case I agree that OpenBSD has nothing that can touch it. Neither does Linux, IMO...

Are you sure? The Linuxmeister himself has said ZFS is just hype. Surely you're mistaken? (That's sarcasm.)

donallen · May 18, 2020

Zaragon said:
Does that work for sending to an actual mail account outside my LAN, though? I don't run a local mailserver and I don't generally check *any* of the local accounts on either of my *BSD servers, so forwarding it to a local user on the same box unfortunately isn't all that helpful either. And I was always under the assumption that (for example) Gmail's SMTP server would reject any attempt by a dynamic IP to forward email to it. I do have my own domain name and functioning dynamic DNS through Google Domains, if there's anything that can be configured there that would allow it to work?

Perhaps I'm lucky my first experience with FreeBSD is 12.1, then? Just about everything has worked right out of the box, and the few things that haven't I've been generally able to trace to me not understanding how FreeBSD does things.

I've been using OpenBSD as a general purpose network appliance (named/dhcpd/pf) for years, which it excels at, and as a file server using softraid RAID1 mirrors, which it does not. I've been drooling over ZFS snapshots since I found out about them--I used to work for NetApp and got very used to how WAFL worked, and ZFS is about the closest thing I've seen in the home space.

I've never found OpenBSD's "lack of a modern filesystem" to be an issue; I've lost more data to ext2 in Linux than I ever have to UFS in OpenBSD. It's not clear to me how much better UFS is in FreeBSD because I planned to use root-on-ZFS from day one, so never looked into it. Is it that much better than OpenBSD's version? ...unless of course you're just referring to ZFS, in which case I agree that OpenBSD has nothing that can touch it. Neither does Linux, IMO, and it doesn't really look like ZFS is ever going to be as integrated into Linux as it is into FreeBSD because of how Torvalds clearly feels about it.

Performance-wise, OpenBSD is generally behind... well, everyone, except possibly NetBSD (haven't used NetBSD in two decades, but it was never a screamer either). It's not their focus, and I get it. I'm still likely to continue to use it for my network appliances because of the security, but I'm likely to use FreeBSD from this point forward for any internally facing server. I only used OpenBSD for that because it was what I knew, and it's simpler to stick with what you know.

I never considered Linux; even though I got my start with Linux back in the mid-90's, but it's gotten more and more disjointed and fragmented and I don't like the direction most major Linux distributions are going. Systemd alone was enough to make me swear off Linux permanently in my own home--there's no polite way to say how I feel about it so that's all I'll say. I have an XUbuntu workstation at work, and while it's fine for actually getting work done it's a chore to actually configure anything.

As far as de Raadt (and Torvalds, for that matter), I consider both to be brilliant people (or at least much, much smarter than I am) whose social skills are lacking, and I don't much care for either of them. However I vastly prefer *BSD to Linux and find that (unpleasantness aside) I tend to agree with the substance of what de Raadt says more often than I do Torvalds. I have a real hard time understanding why Torvalds makes the decisions he does, whereas with de Raadt I can generally follow his reasoning (even if I don't always agree with it).

Usually though, I try to stay out of the communities as much as possible as I find that in most cases the closer you get to the people in charge, the less pleasant they are, and I prefer to use my OS without getting dragged into politics.

I agree with much of what you said. A few comments:

I did not mean to suggest that OpenBSD has no purpose in life. Certainly in network-facing roles where security is paramount, it's probably the best choice.

As for losing data with ext2 -- first, I presume you haven't been using it recently, since ext3 and ext4 are much safer. ext2 was always async by default, whereas OpenBSD's ufs is sync by default. So if you use the default settings on each, OpenBSD is much safer in terms of protecting your data. The performance hit of doing file-system operations synchronously can be significant, however. When I used OpenBSD, I tended to set up most of the file-systems with softdep enabled and /home and /tmp async. I usually have multiple machines running and have scripts to rsync changes from one to another that just take a moment to run, so I never left myself with a lot of un-backed-up work in an async directory on /home. And it did improve the performance. But they still haven't really gotten their smp act together and I don't think a unified buffer cache has been implemented (I could be wrong; I haven't checked in a long time and it wouldn't make a difference to me if they had implemented it).

Systemd was the reason I stopped using Arch, but Slackware is still a very viable choice. Patrick hasn't released in almost 4 years, but I run current, updating occasionally and it works beautifully (and no systemd). But I agree completely about the Linux development model -- chaos -- and Torvalds is no walk in the park either. I think both he and de Raadt suffer from a syndrome I've observed over years of working with very smart people -- they forget that there's a difference between being right most of the time and being right all the time. And so they will too often close their ears; not always, but too often. And the arrogance and nastiness is just so unnecessary. I've had very pleasant and helpful interchanges with Patrick Volkerding and Matt Dillon (leader of the Dragonfly project; Matt has done amazing work on that system and I'd use it in a heart-beat if they could keep Rust up-to-date; I have a suite of financial management tools that I wrote for myself in Rust that I depend on and don't want to be subjected to yesterday's compiler bugs).

Zaragon · May 18, 2020

Phishfry said:
Well "historical reasons" is not very explanatory so here goes.
In the early days FreeBSD updates would overwrite /boot/loader.conf and /etc/rc.conf.
So you would put localized settings in rc.conf.local/loader.conf.local and the update process would ignore these files.
Fast forward to today and you will notice that freebsd-update prompts you about /etc/rc.conf and /boot/loader.conf.

Infact OPNsense still requires you to put localized settings (for instance if_cxgbe_load for Chelsio) in boot.loader.local on their NanoBSD version. NanoBSD uses a read only configuration for certian configuration files so boot.loader.conf is used.

Yeah, in the early days OpenBSD would either clobber everything, or make you manually merge everything in /etc until they added sysmerge for the 4.4 release. I used to have to make a backup of important configuration files whenever I did an update. I don't miss those days.

I haven't done a FreeBSD update yet, of course, having just installed the OS less than a week ago, so hadn't run into that yet. That's useful information--we'll see if I still remember it whenever I get to updating.

Jose said:
Amazingly, it does seem to work. Turns out this game I'd been working on had been sending off email without me noticing. I realized it by tailing /var/log/maillog as root:

Code:

May 18 11:03:06 myhost sm-mta[1583]: 04II2x9h001479: to=<all@oddlabs.com>, ctladdr=<me@myhost.example.com> (1001/1001), delay=00:00:02, xdelay=00:00:02, mailer=esmtp, pri=30395, relay=aspmx.l.google.com. [74.125.142.27], dsn=2.0.0, stat=Sent (Ok: queued as E3BE13270C)

However I do own the .com domain used, it does have a proper SPF record, and the message did go out through the proper MX host. I'm surprised that the "myhost" part didn't cause any problems, though. In any case, you can test it. Set yourself up with a tail of /var/log/maillog in one terminal, and in another other execute echo 'This is only a test' | mail -s 'This is a test' me@example.com and see if it works. You can give the "-v" option to the mail(1) command if you want verbose output on the client side.

Here's what I got--replaced my machine's name with "myhost", my domain name with "mydomain.net", and my gmail address with "******":

Code:

May 18 15:58:28 myhost sendmail[44411]: 04IJwSkh044411: from=root, size=75, class=0, nrcpts=1, msgid=<202005181958.04IJwSkh044411@myhost.mydomain.net>, relay=root@localhost
May 18 15:58:28 myhost sendmail[44411]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 18 15:58:28 myhost sm-mta[44912]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 18 15:58:29 myhost sm-mta[44912]: 04IJwSpK044912: from=<root@myhost.mydomain.net>, size=419, class=0, nrcpts=1, msgid=<202005181958.04IJwSkh044411@myhost.mydomain.net>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 18 15:58:29 myhost sendmail[44411]: 04IJwSkh044411: to=******@gmail.com, ctladdr=root (0/0), delay=00:00:01, xdelay=00:00:01, mailer=relay, pri=30075, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (04IJwSpK044912 Message accepted for delivery)
May 18 15:58:29 myhost sm-mta[45650]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 18 15:58:30 myhost sm-mta[45650]: 04IJwSpK044912: to=<******@gmail.com>, ctladdr=<root@myhost.mydomain.net> (0/0), delay=00:00:01, xdelay=00:00:01, mailer=esmtp, pri=30419, relay=gmail-smtp-in.l.google.com. [172.217.197.27], dsn=2.0.0, stat=Sent (OK  1589831910 c19si6143147qko.159 - gsmtp)

And it worked! Gmail dumped it my spam folder, but it worked! Thank you so much for your help!

donallen said:
I agree with much of what you said. A few comments:

I did not mean to suggest that OpenBSD has no purpose in life. Certainly in network-facing roles where security is paramount, it's probably the best choice.

As for losing data with ext2 -- first, I presume you haven't been using it recently, since ext3 and ext4 are much safer. ext2 was always async by default, whereas OpenBSD's ufs is sync by default. So if you use the default settings on each, OpenBSD is much safer in terms of protecting your data. The performance hit of doing file-system operations synchronously can be significant, however. When I used OpenBSD, I tended to set up most of the file-systems with softdep enabled and /home and /tmp async. I usually have multiple machines running and have scripts to rsync changes from one to another that just take a moment to run, so I never left myself with a lot of un-backed-up work in an async directory on /home. And it did improve the performance. But they still haven't really gotten their smp act together and I don't think a unified buffer cache has been implemented (I could be wrong; I haven't checked in a long time and it wouldn't make a difference to me if they had implemented it).

Systemd was the reason I stopped using Arch, but Slackware is still a very viable choice. Patrick hasn't released in almost 4 years, but I run current, updating occasionally and it works beautifully (and no systemd). But I agree completely about the Linux development model -- chaos -- and Torvalds is no walk in the park either. I think both he and de Raadt suffer from a syndrome I've observed over years of working with very smart people -- they forget that there's a difference between being right most of the time and being right all the time. And so they will too often close their ears; not always, but too often. And the arrogance and nastiness is just so unnecessary. I've had very pleasant and helpful interchanges with Patrick Volkerding and Matt Dillon (leader of the Dragonfly project; Matt has done amazing work on that system and I'd use it in a heart-beat if they could keep Rust up-to-date; I have a suite of financial management tools that I wrote for myself in Rust that I depend on and don't want to be subjected to yesterday's compiler bugs).

I didn't think you were trying to suggest the OpenBSD had no purpose and I'm sorry if it came off that way. I was merely trying to say that I intend to keep using OpenBSD in the roles it excels at and move to FreeBSD for the roles it does not.

I moved from Linux to OpenBSD with the release of OpenBSD 3.0, so sometime between December of 2001 and May of 2002. I was aware of the development of ext3, but it was only merged into the Linux kernel in November of 2001. I'm fairly certain I never used a single Linux system with ext3. I have used ext4; my current Linux workstation uses it, and I have actually lost recently saved data with it and had it corrupt the filesystem once. I do run Linux in a VM, so I can't be 100% sure it's ext4's fault, but I'm not particularly enthused by it. I do use softdep with OpenBSD and have never had it lose data I actually care about. It could be that I've been lucky with OpenBSD and unlucky with Linux, I suppose.

As far as systemd, only Debian-based and Redhat-based OSes (Fedora/RHEL) are supported at work, and I'm pretty sure they all use systemd. I don't use a *NIX desktop at home, they're all Windows.

Mjölnir · May 21, 2020

If you only need a local mailer (receice local, send to the internet), choose dma, it's in the base system.
In /etc/rc.conf:

Code:

sendmail_enable="NO"
sendmail_submit_enable="NO"
sendmail_outbound_enable="NO"
sendmail_msp_queue_enable="NO"

Zaragon · May 21, 2020

I spoke too soon. It sent the test message, and it sent the overnight messages once. Now /var/log/maillog has some very odd things in it.

First:

Code:

May 21 03:10:14 myhost sendmail[61236]: gethostbyaddr(192.168.1.35) failed: 1
May 21 03:10:28 myhost sendmail[83382]: gethostbyaddr(192.168.1.35) failed: 1
May 21 03:11:13 myhost sendmail[64451]: gethostbyaddr(192.168.1.35) failed: 1

I don't know why it's checking this interface, it's not connected to anything. I used it to connect to the server's built-in management interface.

Code:

igb1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
        options=e507bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWFILTER,VLAN_HWTSO,RXCSUM_IPV6,TXCSUM_IPV6>
        ether 00:25:90:ca:fd:4d
        inet 192.168.1.35 netmask 0xffffff00 broadcast 192.168.1.255
        media: Ethernet autoselect
        status: no carrier
        nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>

Second, the contents of the log indicate that it's having trouble sending the message, but it's not entirely clear why. I see some odd messages, but none are pinpointing exactly why the message isn't going out.

Code:

May 21 03:11:13 myhost sendmail[48215]: 04L7BDVT048215: from=root, size=2846, class=0, nrcpts=1, msgid=<202005210711.04L7BDVT048215@myhost.mydomain.net>, relay=root@localhost
May 21 03:11:13 myhost sendmail[48215]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 03:11:13 myhost sm-mta[98470]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 03:11:20 myhost sendmail[96094]: 04L7BJLA096094: from=root, size=3262, class=0, nrcpts=1, msgid=<202005210711.04L7BJLA096094@myhost.mydomain.net>, relay=root@localhost
May 21 03:11:20 myhost sendmail[96094]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 03:11:20 myhost sm-mta[98625]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 03:11:35 myhost sm-mta[98470]: 04L7BDuK098470: from=<root@myhost.mydomain.net>, size=3190, class=0, nrcpts=1, msgid=<202005210711.04L7BDVT048215@myhost.mydomain.net>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 03:11:35 myhost sm-mta[98470]: 04L7BDuK098470: to=<root@myhost.mydomain.net>, delay=00:00:00, mailer=local, pri=33190, dsn=4.4.3, stat=queued
May 21 03:11:35 myhost sendmail[48215]: 04L7BDVT048215: to=root, ctladdr=root (0/0), delay=00:00:22, xdelay=00:00:22, mailer=relay, pri=32846, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (04L7BDuK098470 Message accepted for delivery)
May 21 03:11:42 myhost sm-mta[98625]: 04L7BK2F098625: from=<root@myhost.mydomain.net>, size=3606, class=0, nrcpts=1, msgid=<202005210711.04L7BJLA096094@myhost.mydomain.net>, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 03:11:42 myhost sm-mta[98625]: 04L7BK2F098625: to=<root@myhost.mydomain.net>, delay=00:00:01, mailer=local, pri=33606, dsn=4.4.3, stat=queued
May 21 03:11:42 myhost sendmail[96094]: 04L7BJLA096094: to=root, ctladdr=root (0/0), delay=00:00:23, xdelay=00:00:22, mailer=relay, pri=33262, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (04L7BK2F098625 Message accepted for delivery)
May 21 07:13:05 myhost sm-mta[39263]: 04L7BDuK098470: 04LBCi2F039263: sender notify: Warning: could not send message for past 4 hours
May 21 07:13:06 myhost sm-mta[39263]: 04LBCi2F039263: to=<root@myhost.mydomain.net>, delay=00:00:01, mailer=local, pri=34562, dsn=4.4.3, stat=queued
May 21 07:13:06 myhost sm-mta[39263]: 04L7BK2F098625: 04LBCi2G039263: sender notify: Warning: could not send message for past 4 hours
May 21 07:13:06 myhost sm-mta[39263]: 04LBCi2G039263: to=<root@myhost.mydomain.net>, delay=00:00:00, mailer=local, pri=34978, dsn=4.4.3, stat=queued
May 21 15:00:15 myhost sendmail[90511]: 04LJ0FDK090511: from=root, size=511, class=0, nrcpts=1, msgid=<202005211900.04LJ0FDK090511@myhost.mydomain.net>, relay=root@localhost
May 21 15:00:15 myhost sendmail[90511]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:00:15 myhost sm-mta[90818]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:00:57 myhost sendmail[90511]: 04LJ0FDK090511: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 15:00:57 myhost sendmail[90511]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=00:00:42, xdelay=00:00:42, mailer=relay, pri=30511, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 15:00:57 myhost sm-mta[90818]: 04LJ0FXv090818: collect: premature EOM: unexpected close
May 21 15:00:58 myhost sm-mta[90818]: 04LJ0FXv090818: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 15:00:58 myhost sm-mta[90818]: 04LJ0FXv090818: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 15:12:45 myhost sm-msp-queue[99952]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:12:45 myhost sm-mta[267]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:13:27 myhost sm-msp-queue[99952]: 04LJ0FDK090511: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 15:13:27 myhost sm-msp-queue[99952]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=00:13:12, xdelay=00:00:42, mailer=relay, pri=120511, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 15:13:27 myhost sm-mta[267]: 04LJCjhP000267: collect: premature EOM: unexpected close
May 21 15:13:27 myhost sm-mta[267]: 04LJCjhP000267: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 15:13:27 myhost sm-mta[267]: 04LJCjhP000267: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 15:15:14 myhost sendmail[2663]: 04LJFEbN002663: from=root, size=1010, class=0, nrcpts=1, msgid=<202005211915.04LJFEbN002663@myhost.mydomain.net>, relay=root@localhost
May 21 15:15:14 myhost sendmail[2663]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:15:14 myhost sm-mta[3085]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:15:57 myhost sendmail[2663]: 04LJFEbN002663: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 15:15:57 myhost sendmail[2663]: 04LJFEbN002663: to=root, ctladdr=root (0/0), delay=00:00:43, xdelay=00:00:43, mailer=relay, pri=31010, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 15:15:57 myhost sm-mta[3085]: 04LJFEKQ003085: collect: premature EOM: unexpected close
May 21 15:15:57 myhost sm-mta[3085]: 04LJFEKQ003085: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 15:15:57 myhost sm-mta[3085]: 04LJFEKQ003085: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 15:42:45 myhost sm-msp-queue[89175]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:42:45 myhost sm-mta[89845]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 15:43:28 myhost sm-msp-queue[89175]: 04LJFEbN002663: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 15:43:28 myhost sm-msp-queue[89175]: 04LJFEbN002663: to=root, ctladdr=root (0/0), delay=00:28:14, xdelay=00:00:43, mailer=relay, pri=121010, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 15:43:28 myhost sm-mta[89845]: 04LJgj59089845: collect: premature EOM: unexpected close
May 21 15:43:28 myhost sm-mta[89845]: 04LJgj59089845: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 15:43:28 myhost sm-mta[89845]: 04LJgj59089845: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 15:43:28 myhost sm-msp-queue[89175]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=00:43:13, xdelay=00:00:00, mailer=relay, pri=210511, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred
May 21 16:12:45 myhost sm-msp-queue[61626]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 16:12:45 myhost sm-mta[62245]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 16:13:28 myhost sm-msp-queue[61626]: 04LJFEbN002663: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 16:13:28 myhost sm-msp-queue[61626]: 04LJFEbN002663: to=root, ctladdr=root (0/0), delay=00:58:14, xdelay=00:00:43, mailer=relay, pri=211010, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 16:13:28 myhost sm-mta[62245]: 04LKCjb5062245: collect: premature EOM: unexpected close
May 21 16:13:28 myhost sm-mta[62245]: 04LKCjb5062245: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 16:13:28 myhost sm-mta[62245]: 04LKCjb5062245: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 16:13:28 myhost sm-msp-queue[61626]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=01:13:13, xdelay=00:00:00, mailer=relay, pri=300511, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred
May 21 16:42:46 myhost sm-msp-queue[11054]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 16:42:46 myhost sm-mta[11141]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 16:43:28 myhost sm-msp-queue[11054]: 04LJFEbN002663: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 16:43:28 myhost sm-msp-queue[11054]: 04LJFEbN002663: to=root, ctladdr=root (0/0), delay=01:28:14, xdelay=00:00:43, mailer=relay, pri=301010, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 16:43:28 myhost sm-mta[11141]: 04LKgkgb011141: collect: premature EOM: unexpected close
May 21 16:43:28 myhost sm-mta[11141]: 04LKgkgb011141: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 16:43:28 myhost sm-mta[11141]: 04LKgkgb011141: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 16:43:28 myhost sm-msp-queue[11054]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=01:43:13, xdelay=00:00:00, mailer=relay, pri=390511, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred
May 21 17:12:45 myhost sm-msp-queue[75992]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 17:12:45 myhost sm-mta[76397]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 17:13:27 myhost sm-msp-queue[75992]: 04LJFEbN002663: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 17:13:27 myhost sm-msp-queue[75992]: 04LJFEbN002663: to=root, ctladdr=root (0/0), delay=01:58:13, xdelay=00:00:42, mailer=relay, pri=391010, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 17:13:27 myhost sm-mta[76397]: 04LLCjoY076397: collect: premature EOM: unexpected close
May 21 17:13:27 myhost sm-mta[76397]: 04LLCjoY076397: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 17:13:27 myhost sm-mta[76397]: 04LLCjoY076397: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 17:13:28 myhost sm-msp-queue[75992]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=02:13:13, xdelay=00:00:00, mailer=relay, pri=480511, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred
May 21 17:42:46 myhost sm-msp-queue[27855]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 17:42:46 myhost sm-mta[28245]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 17:43:28 myhost sm-msp-queue[27855]: 04LJFEbN002663: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 17:43:28 myhost sm-msp-queue[27855]: 04LJFEbN002663: to=root, ctladdr=root (0/0), delay=02:28:14, xdelay=00:00:43, mailer=relay, pri=481010, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 17:43:28 myhost sm-mta[28245]: 04LLgjvK028245: collect: premature EOM: unexpected close
May 21 17:43:28 myhost sm-mta[28245]: 04LLgjvK028245: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 17:43:28 myhost sm-mta[28245]: 04LLgjvK028245: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 17:43:28 myhost sm-msp-queue[27855]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=02:43:13, xdelay=00:00:00, mailer=relay, pri=570511, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred
May 21 18:12:45 myhost sm-msp-queue[85229]: STARTTLS=client, relay=[127.0.0.1], version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 18:12:45 myhost sm-mta[85843]: STARTTLS=server, relay=localhost [127.0.0.1], version=TLSv1.3, verify=NO, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 18:13:28 myhost sm-msp-queue[85229]: 04LJFEbN002663: SYSERR(root): timeout writing message to [127.0.0.1]
May 21 18:13:28 myhost sm-mta[85843]: 04LMCjYn085843: collect: premature EOM: unexpected close
May 21 18:13:28 myhost sm-msp-queue[85229]: 04LJFEbN002663: to=root, ctladdr=root (0/0), delay=02:58:14, xdelay=00:00:43, mailer=relay, pri=571010, relay=[127.0.0.1] [127.0.0.1], dsn=4.0.0, stat=Deferred: Name server: [127.0.0.1]: host name lookup failure
May 21 18:13:28 myhost sm-mta[85843]: 04LMCjYn085843: collect: unexpected close on connection from localhost, sender=<root@myhost.mydomain.net>
May 21 18:13:28 myhost sm-mta[85843]: 04LMCjYn085843: from=<root@myhost.mydomain.net>, size=267, class=0, nrcpts=1, proto=ESMTPS, daemon=Daemon0, relay=localhost [127.0.0.1]
May 21 18:13:28 myhost sm-msp-queue[85229]: 04LJ0FDK090511: to=root, ctladdr=root (0/0), delay=03:13:13, xdelay=00:00:00, mailer=relay, pri=660511, relay=[127.0.0.1], dsn=4.0.0, stat=Deferred

I especially don't understand the "host name lookup failures" for 127.0.01, since it looks fine when I check manually. localhost, however, doesn't resolve on my FreeBSD machine but does on both of my OpenBSD machines:

FreeBSD result:

Code:

myhost:/usr/local/sbin# nslookup 127.0.0.1
1.0.0.127.in-addr.arpa  name = localhost.

myhost:/usr/local/sbin# nslookup localhost
;; Got SERVFAIL reply from 192.168.1.1, trying next server
;; connection timed out; no servers could be reached

Here's the OpenBSD result:

Code:

openhost:/root# nslookup 127.0.0.1
Server:         192.168.1.1
Address:        192.168.1.1#53

1.0.0.127.in-addr.arpa  name = localhost.

openhost:/root# nslookup localhost
Server:         192.168.1.1
Address:        192.168.1.1#53

Name:   localhost
Address: 127.0.0.1

The original example test mail isn't working any more either. The relevant lines from that seem to be:

Code:

May 21 18:46:27 myhost sm-mta[3870]: STARTTLS=client, relay=gmail-smtp-in.l.google.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 18:46:27 myhost sm-mta[3870]: 04LMk5kZ003832: SYSERR(root): timeout writing message to gmail-smtp-in.l.google.com.
May 21 18:46:28 myhost sm-mta[3870]: STARTTLS=client, relay=alt1.gmail-smtp-in.l.google.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 18:46:29 myhost sm-mta[3870]: 04LMk5kZ003832: SYSERR(root): timeout writing message to alt1.gmail-smtp-in.l.google.com.
May 21 18:46:30 myhost sm-mta[3870]: STARTTLS=client, relay=alt2.gmail-smtp-in.l.google.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 18:46:30 myhost sm-mta[3870]: 04LMk5kZ003832: SYSERR(root): timeout writing message to alt2.gmail-smtp-in.l.google.com.
May 21 18:46:31 myhost sm-mta[3870]: STARTTLS=client, relay=alt3.gmail-smtp-in.l.google.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 18:46:31 myhost sm-mta[3870]: 04LMk5kZ003832: SYSERR(root): timeout writing message to alt3.gmail-smtp-in.l.google.com.
May 21 18:46:32 myhost sm-mta[3870]: STARTTLS=client, relay=alt4.gmail-smtp-in.l.google.com., version=TLSv1.3, verify=FAIL, cipher=TLS_AES_256_GCM_SHA384, bits=256/256
May 21 18:46:32 myhost sm-mta[3870]: 04LMk5kZ003832: SYSERR(root): timeout writing message to alt4.gmail-smtp-in.l.google.com.
May 21 18:46:32 myhost sm-mta[3870]: 04LMk5kZ003832: to=<******@gmail.com>, ctladdr=<root@myhost.mydomain.net> (0/0), delay=00:00:06, xdelay=00:00:06, mailer=esmtp, pri=30419, relay=alt4.gmail-smtp-in.l.google.com. [172.217.218.27], dsn=4.0.0, stat=Deferred: Name server: alt4.gmail-smtp-in.l.google.com.: host name lookup failure

Yet nslookup of all of those addresses works fine:

Code:

myhost:/usr/local/sbin# nslookup gmail-smtp-in.l.google.com.
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   gmail-smtp-in.l.google.com
Address: 173.194.207.26
Name:   gmail-smtp-in.l.google.com
Address: 2607:f8b0:400d:c09::1a

myhost:/usr/local/sbin# nslookup alt1.gmail-smtp-in.l.google.com.
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   alt1.gmail-smtp-in.l.google.com
Address: 64.233.186.27
Name:   alt1.gmail-smtp-in.l.google.com
Address: 2800:3f0:4003:c00::1a

myhost:/usr/local/sbin# nslookup alt3.gmail-smtp-in.l.google.com.
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   alt3.gmail-smtp-in.l.google.com
Address: 172.253.120.26
Name:   alt3.gmail-smtp-in.l.google.com
Address: 2a00:1450:400c:c01::1a

myhost:/usr/local/sbin# nslookup alt4.gmail-smtp-in.l.google.com.
Server:         192.168.1.1
Address:        192.168.1.1#53

Non-authoritative answer:
Name:   alt4.gmail-smtp-in.l.google.com
Address: 172.217.218.27
Name:   alt4.gmail-smtp-in.l.google.com
Address: 2a00:1450:4013:c08::1a

I'm at a loss for why nameservice seems to be not working for sendmail and only for sendmail. Has anyone got any ideas? I haven't even rebooted the machine since it worked:

Code:

myhost:/usr/local/sbin# uptime
 6:52PM  up 4 days, 21:40, 16 users, load averages: 0.47, 0.56, 0.53

Jose · May 22, 2020

That's very odd because localhost should be in /etc/hosts. Have you messed with it? What does your /etc/nsswitch.conf say?

mark_j · May 22, 2020

Zaragon said:
I spoke too soon. It sent the test message, and it sent the overnight messages once. Now /var/log/maillog has some very odd things in it.

First:

Code:

May 21 03:10:14 myhost sendmail[61236]: gethostbyaddr(192.168.1.35) failed: 1 May 21 03:10:28 myhost sendmail[83382]: gethostbyaddr(192.168.1.35) failed: 1 May 21 03:11:13 myhost sendmail[64451]: gethostbyaddr(192.168.1.35) failed: 1

I don't know why it's checking this interface, it's not connected to anything. I used it to connect to the server's built-in management interface.

It's just sendmail being officious. It can be ignored or fixed by adding a /etc/hosts entry OR setting DontProbeInterfaces=True in sendmail.cf

Read more about it here: https://docstore.mik.ua/orelly/other/Sendmail_3rd/1565928393_ch24-74854.html

PMc · May 22, 2020

Zaragon said:
I spoke too soon. It sent the test message, and it sent the overnight messages once. Now /var/log/maillog has some very odd things in it.

First:

Code:

May 21 03:10:14 myhost sendmail[61236]: gethostbyaddr(192.168.1.35) failed: 1 May 21 03:10:28 myhost sendmail[83382]: gethostbyaddr(192.168.1.35) failed: 1 May 21 03:11:13 myhost sendmail[64451]: gethostbyaddr(192.168.1.35) failed: 1

I don't know why it's checking this interface, it's not connected to anything. I used it to connect to the server's built-in management interface.

It checks every interface it can find, and reverse resolves it, in order to obtain all possible hostnames for which it should accept mails.

Then, sendmail works best with a concludent nameserver (that is, one that never gives back SERVFAIL, only NXDOMAIN - because for every name it can figure out if it exists or not - forward and reverse). But then, to configure such a nameserver correctly is a bit of an effort.
I seem to remember that there were cases when sendmail would not care about /etc/hosts and only consult the nameserver - but that was long ago and I don't know what has become of that.

Zaragon · May 26, 2020

I actually did solve the problem. How's that old saw go?

1. It's not DNS.
2. There's no WAY it's DNS.
3. It was DNS.

What I don't understand is why FreeBSD was so insistent on trying to use igb1, even though it had no carrier. Shutting that interface down was enough to get sendmail to start throwing different errors, which were actually helpful. I'm guessing sendmail may have been trying to route DNS queries out the disconnected interface?

Because this system is a replacement for an existing system, I gave it the same name as the original (I've had too many cases of issues changing the name later, not that I really expected FreeBSD to give me issues but better safe than sorry). The problem is I need to run both machines at once, so they can't have the same IP address. So I gave it the IP address of a web server I used to have... which had a different name. So when it queries the nameserver for reverse lookup, that's the name it gets. Which doesn't match. And then sendmail has a fit.

I solved that problem by massaging /etc/hosts:

Code:

127.0.0.1               localhost
::1                     localhost
192.168.1.2             myhost.mydomain.net myhost

If you ask the nameserver, it tells you that myhost.mydomain.net is 192.168.1.3, which is the old server. and if you reverse lookup 192.168.1.2 it tells you that's webserver.mydomain.com. Which is why the /etc/hosts had to be massaged.

Now I just need to remember to change it when I put the machine into server and take the other one down.

Incidentally, if I'd given it an IP address that my nameserver didn't know about, I think it would have worked the minute I shut down the igb1 interface, because my nameserver DOES return NXDOMAIN. But I had to be clever.

Code:

myhost:/root# nslookup nonexistent.mydomain.net
Server:         192.168.1.1
Address:        192.168.1.1#53

** server can't find nonexistent.mydomain.net: NXDOMAIN

Code:

myhost:/root# nslookup 192.168.1.4
** server can't find 4.1.168.192.in-addr.arpa: NXDOMAIN
myhost:/root# nslookup 192.168.1.35
** server can't find 35.1.168.192.in-addr.arpa: NXDOMAIN

I ended up running into other DNS issues which I was only able to solve with subdomains, but that had nothing to do with getting sendmail or FreeBSD working (that was all on the BIND side). and it still works.

While all this was going on I had drives start losing data in the original server (again with both halves of a mirrored pair going bad), so this machine is going to be pressed into service a little sooner than I would have liked. I've been pulling data off for the last week as I shuffle drives around and storing it on some RAIZ2 pools I've made. Nothing on the zroot mirror, that's going to be for the OS only.

I have automated scrubs and snapshots working (I didn't like any of the existing snapshot solutions so I rolled my own in python). I haven't set up automated SMART scans since I'm still using it to test all of my remaining hard drives, but as soon as that's done, I'll set them up, then I'll set up Samba.

Thanks everyone for all of your help! I couldn't have gotten some of these things working without the help provided by all of you in this thread.

Jose · May 26, 2020

Zaragon said:
I actually did solve the problem. How's that old saw go?

1. It's not DNS.
2. There's no WAY it's DNS.
3. It was DNS.

Haha! I'm gonna use this one.

Zaragon said:
Because this system is a replacement for an existing system...The problem is I need to run both machines at once...

I feel you, brother. I'm currently moving from Gentoo Linux to Freebsd, decommissioning LDAP and implementing Kerberos. I have two split-horizon domains for a total of 4 BIND configs. They sort-of cross resolve. Sometimes. It has caused me a few headaches.

Zaragon said:
While all this was going on I had drives start losing data in the original server (again with both halves of a mirrored pair going bad), so this machine is going to be pressed into service a little sooner than I would have liked. I've been pulling data off for the last week as I shuffle drives around and storing it on some RAIZ2 pools I've made.

I hate this Catch-22. Putting load on the old hardware causes it to fail, but you have to put load on it to migrate off it.

Zaragon · May 26, 2020

I'm not running LDAP or Kerberos but I am dealing with two split-horizon subdomains that used to be in two separate top level-domains, oh and both gateways have dynamic IP addresses on their public facing interfaces. I tried to make it work without subdomains but it was just impossible for me to figure out how to do it since both sites have their own nameservers that need to be authoritative for their own domain (once the nameservers were up, neither side would query their secondary nameservers or even the root nameservers to determine the IP of the other side, since they were both authoritative for the same domain).

The data loss got caused by a panic on the OpenBSD fileserver when it hit a bad sector on one of the drives in a mirrored pair, which then caused it to kernel panic. (Have I mentioned how tired I am of OpenBSD kernel panicking due to read errors on non-root volumes?) That caused two of the three mirrors to degrade on reboot; the one that hit the error and another one just because it could. I started a rebuild on both mirrors; it puked and died again trying to rebuild the damaged mirror and now neither side will come up at all. (Let's leave out how this is a mirror and it should at least bring up one half of it in a degraded state.) So now all data on that mirror appears unrecoverable because it won't even attempt to bring the mirror up. Both drives are up and running; I should be able to pull off most of the data despite the bad sectors (there's only a couple on each drive, and I doubt they're in the same file on both drives) but it won't even let me try.

This is the second time this has happened with mirrors on OpenBSD. They only seem to handle it well when an entire drive dies. Data read errors off either drive seem to just be the kiss of death, often leading to kernel panics and degrading other random other mirrors. Ironically I've lost more data with a mirrored pair of drives than I would have lost with a single non-redundant disk. Fortunately ZFS will handle this better (especially this case).

Zaragon · May 30, 2020

Actually nevermind, this has devolved into something sendmail specific, so I'm going to repost into the correct forum. If anyone has sendmail specific advice as to why things aren't working, the new thread is at:

Trying to forward root to my GMail account

Hi all, I originally posted this in a different thread in the General forum, but this has stopped being about general FreeBSD issues and started being specifically about sendmail, so I thought I would move it to what looks like the correct subforum. I have FreeBSD installed on my fileserver...

forums.freebsd.org

Moving server from OpenBSD to FreeBSD

Attachments