# Moving server from OpenBSD to FreeBSD



## Zaragon (May 12, 2020)

Hey all,

My file server is currently running OpenBSD (using RAID1 2-way mirrors) and I'm planning on moving it over to FreeBSD to take advantage of ZFS, since I'm going to be using a 24-bay rackmount Supermicro now instead of the old tower case I've been using.

Aside from the change to using ZFS, which I've been heavily researching, are there any major gotchas I should be aware of when moving to FreeBSD? I've been using OpenBSD for my servers for something close to 20 years (whenever the first version of pf was released), but I've never touched FreeBSD, and almost all the migration guides seem to be focused on Windows or Linux users, not NetBSD or OpenBSD users.

I don't intend to run X or desktop applications on it, so I expect that'll make the migration easier, and I'd imagine most of the packages I use on OpenBSD are available on FreeBSD (and if not, I can find alternatives). I'm primarily looking for differences in the main OS that might trip me up.

TIA for any help you can provide!


----------



## Jose (May 12, 2020)

The biggest difference I can think of is how anything you install out of a package or port is going to want to be configured in /usr/local/etc. Openbsd AFAICT keeps everything in /etc as do most Linuxes. This includes startup scripts, which live in /usr/local/etc/rc.d on Freebsd.

Network config is a little different in that you do it in /etc/rc.conf instead of in hostname.ifname files. Oh, and you edit /etc/rc.conf, not /etc/rc.conf.local. The default values in Freebsd are in /etc/defaults/rc.conf.

Keep in mind your pf ruleset might not work in Freebsd. The version of pf in Freebsd is based on the pf that was released in Openbsd 4.5, and has been "heavily modified" according to the man page.

I'm sure I'm forgetting things, but I doubt you'll have much trouble with the migration. ZFS seems magical to me after years of struggling with LVM on Linux. Well worth the change.


----------



## k3y5 (May 12, 2020)

My servers are currently running OpenBSD, and now (finally) a personal laptop running FreeBSD. I would say that working with `ports` and pkg in generally has been a wonderful process. I would be careful mixing ports/pkg libraries, things can get interesting. You can find any every OpenBSD package within the ports library. 

I've taken to using OpenBSD as the firewall/gatekeeper, and FreeBSD as the data manager/ admin. I think you will be pleasantly surprised with the progress that FreeBSD has made. 
Also, documentation, on documentation. OpenBSD has the manual, FreeBSD covers everything. They've even got their own developer handbook! Anything you may need can (usually) be solved by checking the docs. Its one of the main reasons I chose FreeBSD on my personal laptop. Even if I can't find the exact right thing, I can find out how to diagnose the problem, and build what I need.


----------



## Zaragon (May 12, 2020)

Yeah, I'm aware of the PF differences, but I have a separate physical machine that's going to remain on OpenBSD that functions as my firewall/nameserver/ntp server/http server/dhcp server/VPN endpoint (it might do a few more things, that's just all I remember offhand. The file server is only accessible via the LAN (and by extension, to anyone connected via the VPN) and so doesn't run any sort of packet filter--in fact the current machine only runs Samba, NFS, and NTP. I'm not really using NFS anymore and probably won't enable it on the new FreeBSD server.

I wasn't aware about the differences in the network/rc.conf configuration or the existence of /usr/local/etc,  that's exactly the sort of thing I'm talking about as gotchas. If anyone has any more keep them coming, that's very helpful.


----------



## Zaragon (May 14, 2020)

I've gotten started setting up my machine. and ran into a few gotchas.

First the good news though. Guided ZFS on root from the install was a piece a cake; it was so much fun I did it twice! Couple of binaries were packages on OpenBSD but are part of the base system on FreeBSD (like `bzip2`, `lz4`, and `xz`) not really a surprise. Didn't find a single thing I needed that wasn't either already in the system or available in a package or port just like on OpenBSD. Then again, I didn't expect I would.

The network config was a non-issue, after seeing how the setup configured the first interface it was easy. Same for the hostname, also configured via /etc/rc.conf, which is also different on OpenBSD (stored in the file /etc/mygate).

And I'd originally posted that I wouldn't be using any sort of packet filter, but I forgot that `sshguard` just hooks in to the packet filter of your choice (which is the only reason my original file server has `pf` running). Fortunately, the pf.conf from the old server is so simple that the only thing I needed to do was change the name of the network interface, and FreeBSD accepted it as-is.

The /usr/local/etc keeps biting me; sometimes files are in /etc (syctl.conf, rc.conf), sometimes they are in /usr/local/etc (sshguard.conf, zshenv), and sometimes they're in /etc/default, with the expectation that you'll overwrite with additional config in either /etc or /usr/local/etc (`periodic` in particular seems to scatter stuff everywhere). I understand the purpose of having /usr/local/etc but it is sure making my life more difficult right now when I go to configure things.

One that wasn't mentioned was /etc/crontab; OpenBSD doesn't use that and just uses root's crontab. Ran into this one when I was trying to figure out where `periodic` was getting started from and `crontab -e` as root just gave me an empty file.

Everything else remaining is either ZFS specific (such as difficulties mounting the zroot created by the default installer from the LiveCD) or package specific (having difficulties making any sense out of smartd.conf).


----------



## richardtoohey2 (May 14, 2020)

I run both and couldn't think of any _major_ issues you'd have so didn't post before and doesn't sound like you've encountered anything dire.

On FreeBSD I miss OpenBSD's enhanced systat but both OSs are very good in my experience.  Similar enough it's not too hard to switch from one to the other as needs be.  But I'm straying into the non-FreeBSD discussion so 

Thanks for posting the update on how it went for you.


----------



## mark_j (May 14, 2020)

Zaragon said:


> [...]
> The /usr/local/etc keeps biting me; sometimes files are in /etc (syctl.conf, rc.conf), sometimes they are in /usr/local/etc (sshguard.conf, zshenv), and sometimes they're in /etc/default, with the expectation that you'll overwrite with additional config in either /etc or /usr/local/etc (`periodic` in particular seems to scatter stuff everywhere). I understand the purpose of having /usr/local/etc but it is sure making my life more difficult right now when I go to configure things.
> 
> One that wasn't mentioned was /etc/crontab; OpenBSD doesn't use that and just uses root's crontab. Ran into this one when I was trying to figure out where `periodic` was getting started from and `crontab -e` as root just gave me an empty file.
> ...



Well done on the move.

First, probably a quick read of hier(7) is in order. This will tell you rather quickly what is what and what goes where.

Basically, you should disregard ANYTHING in /etc/defaults as it's for the system startup; don't be tempted to edit files in there unless you really know what you're doing.

All ports and packages keep their configuration information in /usr/local/etc, never /etc. I've not personally encountered any exception to this rule.

I guess it can be confusing when /etc/rc.conf and /etc/rc.conf.local exist. I'm not convinced of the benefit of the latter.


----------



## VladiBG (May 14, 2020)

It would be better to take another test server and play / learn with it. Don't rush to migrate a running server to the OS that you 


Zaragon said:


> never touched FreeBSD


----------



## rootbert (May 14, 2020)

you will get used to the fact that ports/packages configuration is under /usr/local/etc and base system stuff is in /etc. This has a nice effect: before a major upgrade on ports and packages, you could take a snapshot of /usr/local and simply rollback an upgrade if something is completely broken.
And one more thing: I encourage you to use jails if you feel the need to setup more services ... it's really great to work with those "networked chroots on steroids"


----------



## Zaragon (May 14, 2020)

Ah, I suppose I wasn't clear; I'm more "cloning and then replacing" than I am technically migrating. I've purchased a new server (Supermicro 846 chassis), which is going to take the place of the old server (generic PC with HBA), which is still up. The old server is going to remain up until I'm satisfied that the new server is performing the way I want it to, then I'll power off the old server, change the IP of the new server, and then power it down and replace the old server with it. That's probably at least two weeks away. In the meantime the new server sits on my desk and serenades me while I work with its lovely droning fans.

I've already wiped and reinstalled once after messing around with the root zpool, I'm not afraid to do it again (though now that I have things setup mostly the way I want them, I'd much rather rollback to a snapshot, instead). I'm still working on shuffling data around off the old server so I can steal 6 of its drives and start using those to learn ZFS better. I'll probably copy (not move) some of that data to the new zpool just to mess with and test things.

I'm definitely using this time to learn and mess with the new OS, though it looks like having used OpenBSD for nearly two decades has given me a leg up on switching to FreeBSD (compared to people switching from Linux). I went through the Linux to BSD pain when I originally switched to OpenBSD. I haven't found this to be NEARLY as bad.

mark_j, thanks for the tips on hier(7), after scanning through that the filesystem hierarchy isn't much different than OpenBSD (with the exception of /usr/local/etc and /etc/defaults). It doesn't really explain the purpose of /usr/local/etc or how the config files layer. Kind of a new concept for me, I'm used to there being one config file per service, even if the locations vary. That especially seems to be giving me grief with `periodic`; nothing I've put in the config seems to be doing anything. Still got to dig into that. Running `periodic daily` manually does something, but it doesn't do (for example) the periodic ZFS scrub I tried to configure. I'm assuming it's only doing the stuff that's configured in the base install.

I'm not sure why /etc/rc.conf.local exists on FreeBSD either, maybe someone else can chime in. In OpenBSD /etc/rc.conf is the base configuration script and gets replaced with every upgrade, and /etc/rc.conf.local is the local configuration. Instead on FreeBSD the base configuration script is in /etc/defaults/rc.conf and the local configuration is just in /etc/rc.conf. It's basically the same division, but with different locations. I suppose I could get behind the idea of an /usr/local/etc/rc.conf, if any ports or packages needed to add stuff to rc.conf, but I don't understand the need for a third rc configuration file in etc.

Edit: The discussion of /etc/defaults and /etc/rc.conf.local actually let me track down what was wrong with `periodic`; it works the same way as `rc`. I had my changes in /usr/local/etc/periodic.conf, which it doesn't seem to read. Moving them to /etc/periodic.conf made the scrubs work.


----------



## Jose (May 14, 2020)

Zaragon said:


> Everything else remaining is either ZFS specific (such as difficulties mounting the zroot created by the default installer from the LiveCD) or package specific (having difficulties making any sense out of smartd.conf).


Here's mine, in case it helps:

```
DEVICESCAN -R 194 -R 231 -a -o on -S on -s (S/../.././02|L/../../6/03) -m root
```
It took a while to come up with it based on the man page and the old version from my Linux server. I've honestly forgotten what most of it means. I only remember that the -s (S/...) part schedules (S)hort and (L)ong tests, and that "-m root" mean email root when there's a problem.

As an aside, I hate these "self-documenting" config files that wind up being hundreds of lines of commented-out stuff. Makes it really hard to figure out what, if anything, you should change on upgrade. The worst offender is php.ini. It took me hours to come up with a reasonable one. I keep it (and other configs) in git now just to stay sane.


----------



## VladiBG (May 14, 2020)

Jose 





						HOWTO Remove comments and blank lines in a config file
					






					linuxreviews.org


----------



## Jose (May 14, 2020)

VladiBG said:


> Jose
> 
> 
> 
> ...


Thanks! Sed works too:

```
sed '/^;/d' php-fpm.d/www.conf | sed '/^$/d'
```


----------



## ralphbsz (May 14, 2020)

Zaragon said:


> I've already wiped and reinstalled once after messing around with the root zpool, I'm not afraid to do it again (though now that I have things setup mostly the way I want them, I'd much rather rollback to a snapshot, instead).


That is exactly the correct attitude. Right now, recreating or just partly reconfiguring the machine is still easy. So invest the time now to get it to the way you like it. Once you have it in production, making major changes will be much more painful and risky.

I transitioned my home server from OpenBSD to FreeBSD about 8 or 10 years ago, and it was not painful at all, very much like your experience.


----------



## PMc (May 15, 2020)

Zaragon said:


> I'm not sure why /etc/rc.conf.local exists on FreeBSD either, maybe someone else can chime in. In OpenBSD /etc/rc.conf is the base configuration script and gets replaced with every upgrade, and /etc/rc.conf.local is the local configuration.



Finally it will depend on each individual how they handle these files, so this is in part only the way I made up to handle things.
The basic rule is: in /etc lives the base system, and everything that comes via ports goes to /usr/local; this includes their start/stop scripts /usr/local/etc/rc.d, their periodics /usr/local/etc/periodic, etc.
Then there is a couple of default configs in /etc/defaults - these do only concern the base system, not any ports, and these will be replaced on every upgrade. If you need to change or add things, only the changes go to the same file in /etc, and these will not be replaced on upgrades. But, as these do only concern the base system, the respective configurations for the ports might be put in similar files with the suffix .local, e.g. /etc/rc.conf.local, /etc/periodic.conf.local, etc.
If you prefer to instead have files like /usr/local/etc/rc.conf and /usr/local/etc/periodic.conf, that is also possible by adding such files to the respective variables in the base configuration (but there is to consider that there might be a point in time where the system needs to read certain files for initialization, while /usr/local is not yet mounted!).
It is also possible (and I prefer to do it), to create a third place for things that are neither base system nor ports, but other locally written or vendor specific components.


----------



## Jose (May 15, 2020)

This is an interesting point. Even though the rc script lives in /usr/local/etc/rc.d it examines /etc/rc.conf to determine if it should run at all, and for additional settings. I examine the rc script to figure out what to put in /etc/rc.conf. Usually it's a straightforward `portname_enable="YES"`, but not always:

```
mdnsresponderposix_enable="YES"
mdnsresponderposix_flags="-n $hostname"
```


----------



## tingo (May 15, 2020)

you can also do `service name-of-script rcvar` and it will tell you. Examples:

```
tingo@kg-core2$ service mysql-server rcvar
# mysql
#
mysql_enable="NO"
#   (default: "")

tingo@kg-core2$ service calibre rcvar
# calibre
#
calibre_enable="NO"
#   (default: "")
```


----------



## PMc (May 15, 2020)

Jose said:


> I examine the rc script to figure out what to put in /etc/rc.conf. Usually it's a straightforward `portname_enable="YES"`, but not always:



There are also some common settings. For instance, you can put in something like

```
portname_env="PGGSSENCMODE=disable"
```
to make a port run with a specific environment variable, which can be very helpful.
Read the comments in /etc/rc.subr for further features.


----------



## Phishfry (May 15, 2020)

I think it is worth noting that /boot/loader.conf is another common settings file.
The scheme used there commonly is:
modulename_load="YES"
loader.conf is commonly is used for starting kernel modules for hardware enablement.
For example I use Chelsio 10G cards for ethernet.
They required both the module and firmware in /boot/loader.conf to get usable interfaces.
if_cxgbe_load="YES"
t4fw_cfg_load="YES"


----------



## Zaragon (May 15, 2020)

Before I get into replies I wanted to state how impressed I am with the stability of this system! I happened to bump one of the SATA cables (without noticing it) while unplugging the network cable from the wall. That caused one of the two drives in zroot to drop out. ZFS and the mirrored swap partition handled it without a hiccup. I onlined the drive again and it came back online with no issue.

Then I decided to see how robust this system is, so I unplugged (at the drive end) the SATA cable I thought was the problem. Turns out I guessed wrong and bumped the other cable while plugging it back in. Entire pool goes offline, but _the system keeps chugging along_. Go back to the command line, clear the zpool and bring it back online, and everything's back to normal like nothing ever happened. Even the swap partition came back like nothing happened.

Considering my OpenBSD file server _kernel panicked_ when both drives in a data mirror died at the same time, then refused to finish booting because it couldn't check the filesystem on the drives that weren't there anymore, color me *thoroughly* impressed.



Jose said:


> This is an interesting point. Even though the rc script lives in /usr/local/etc/rc.d it examines /etc/rc.conf to determine if it should run at all, and for additional settings. I examine the rc script to figure out what to put in /etc/rc.conf. Usually it's a straightforward `portname_enable="YES"`, but not always:
> 
> ```
> mdnsresponderposix_enable="YES"
> ...



Yeah, that's what threw me hard with `zfs-periodic`. The important parts reside in /usr/local/etc, but you have to add the options that enable it in /etc/periodic.conf.

I get what FreeBSD is trying to do with separating /etc and /usr/local/etc, I'm just not convinced of the benefit yet. It seems to be primarily for ease of upgrade, but I configure things more often than I upgrade.

I'm still not wild about /etc/crontab instead of just using root's crontab either, and unlike /usr/local/etc, I don't understand the rationale for this one.



Jose said:


> Here's mine, in case it helps:
> 
> ```
> DEVICESCAN -R 194 -R 231 -a -o on -S on -s (S/../.././02|L/../../6/03) -m root
> ...



Thanks, that's helpful except for one thing--mail that goes to the local root account may as well go straight to /dev/null. I don't think I've ever once checked the `Mail` on any of the three OpenBSD boxes that I maintain, since they're all headless servers jammed in data closets.

I would love to have some way to actually get it to email my actual Gmail account, but I imagine that involves `sendmail` and I've never been able to make `sendmail` do anything I've ever tried. And I configured my own BIND 9 server! (If anyone can actually point me to a guide that will help me do this, I'd be eternally grateful.)

Failing that, at least a way to send it to the system log somewhere, since I do at least periodically `grep` through those looking for interesting things.


----------



## Jose (May 16, 2020)

Zaragon said:


> Thanks, that's helpful except for one thing--mail that goes to the local root account may as well go straight to /dev/null. I don't think I've ever once checked the `Mail` on any of the three OpenBSD boxes that I maintain, since they're all headless servers jammed in data closets.
> 
> I would love to have some way to actually get it to email my actual Gmail account, but I imagine that involves `sendmail` and I've never been able to make `sendmail` do anything I've ever tried. And I configured my own BIND 9 server! (If anyone can actually point me to a guide that will help me do this, I'd be eternally grateful.)
> 
> Failing that, at least a way to send it to the system log somewhere, since I do at least periodically `grep` through those looking for interesting things.


I always alias `root` to a real mail account in /etc/mail/aliases

```
# $FreeBSD: releng/12.1/etc/mail/aliases 243752 2012-12-01 15:11:46Z rwatson $
#       @(#)aliases     5.3 (Berkeley) 5/24/90
#
#  Aliases in this file will NOT be expanded in the header from
#  Mail, but WILL be visible over networks.
#
#       >>>>>>>>>>      The program "newaliases" must be run after
#       >> NOTE >>      this file is updated for any changes to
#       >>>>>>>>>>      show through to sendmail.
#
#
# See also RFC 2142, `MAILBOX NAMES FOR COMMON SERVICES, ROLES
# AND FUNCTIONS', May 1997
#       http://tools.ietf.org/html/rfc2142

# Pretty much everything else in this file points to "root", so
# you would do well in either reading root's mailbox or forwarding
# root's email from here.

root: me@my.domain

# Basic system aliases -- these MUST be present
MAILER-DAEMON: postmaster
postmaster: root
...
```
That plus a `newaliases` should get you off to the races with mail going to root if you didn't mess with the stock Sendmail config. I stopped trying to get Sendmail to do things about 20 years ago. I recommend Postfix if you need an MTA.

Edit: This is the same on Openbsd, BTW.


----------



## donallen (May 17, 2020)

Very good thread with a lot of useful information and discussion. And yes, the system is very, very stable. I started using 12.1 a few weeks ago as a desktop system in place of Slackware Linux on a few of my systems, one a laptop (Thinkpad X250). I've tried to do this over a number of years, periodically testing FreeBSD and, in the past, always found a showstopping problem. This version, while not perfect (what is?), has finally done the job for me and it's really a pleasure to use. ZFS is magic (one of my systems has multiple SSDs and I went through the LVM pain with Linux; this was a piece of cake) and I really like being able to back up a running system with a ZFS snapshot that I then zfs send to a backup drive. I shut my Linux systems down to back them up to avoid them wiggling around while doing so. Not necessary with ZFS and FreeBSD. I also like the performance and generally up-to-date packages. 
I've also used OpenBSD off and on, mostly off, over the years and found that I was bothered by the sluggishness. And the lack of a modern filesystem. And packages being somewhat out-of-date, though running current helps with that. The system is generally behind the times, perhaps because of the total emphasis on security. Linus Torvalds had something pungent to say about that, as I recall. My biggest issue with OpenBSD, though is de Raadt. He's undeniably brilliant, but perhaps not quite as brilliant as he thinks he is, and his nastiness has rubbed off on some of his lieutenants. They are doing good work, but it's not good enough for me to put up with the unpleasantness.


----------



## Zaragon (May 18, 2020)

Jose said:


> I always alias `root` to a real mail account in /etc/mail/aliases
> 
> ```
> # $FreeBSD: releng/12.1/etc/mail/aliases 243752 2012-12-01 15:11:46Z rwatson $
> ...



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?



donallen said:


> Very good thread with a lot of useful information and discussion. And yes, the system is very, very stable. I started using 12.1 a few weeks ago as a desktop system in place of Slackware Linux on a few of my systems, one a laptop (Thinkpad X250). I've tried to do this over a number of years, periodically testing FreeBSD and, in the past, always found a showstopping problem. This version, while not perfect (what is?), has finally done the job for me and it's really a pleasure to use. ZFS is magic (one of my systems has multiple SSDs and I went through the LVM pain with Linux; this was a piece of cake) and I really like being able to back up a running system with a ZFS snapshot that I then zfs send to a backup drive. I shut my Linux systems down to back them up to avoid them wiggling around while doing so. Not necessary with ZFS and FreeBSD. I also like the performance and generally up-to-date packages.
> I've also used OpenBSD off and on, mostly off, over the years and found that I was bothered by the sluggishness. And the lack of a modern filesystem. And packages being somewhat out-of-date, though running current helps with that. The system is generally behind the times, perhaps because of the total emphasis on security. Linus Torvalds had something pungent to say about that, as I recall. My biggest issue with OpenBSD, though is de Raadt. He's undeniably brilliant, but perhaps not quite as brilliant as he thinks he is, and his nastiness has rubbed off on some of his lieutenants. They are doing good work, but it's not good enough for me to put up with the unpleasantness.



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.


----------



## drhowarddrfine (May 18, 2020)

Zaragon said:


> I'm not sure why /etc/rc.conf.local exists on FreeBSD either


`man rc.conf`


----------



## Phishfry (May 18, 2020)

drhowarddrfine said:


> man rc.conf


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.


----------



## 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:

```
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?
> 
> 
> 
> ...



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.
> ...



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:
> 
> ```
> 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)
> ...



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

```
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.
> 
> ...



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:

```
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:

```
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.


```
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.


```
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:

```
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:

```
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:


```
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:


```
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:


```
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:
> 
> ...



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:
> 
> ...



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:


```
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.


```
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
```


```
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


----------

