>> Also, I would like to influence the host, domain, and old for the >> auto-configuration. Is there a way to do that? I would like to run the >> mail-server configuration stage again with the correct names > > Answering myself: in Server.app: set 'Computer Name’ to th eFQDN (just as > Host Name, so something like host.domain.tld and not just ‘Host’). > /bin/hostname reports the 'Computer Name' field, not the ‘Host Name’ field.
This out-of-scope for MacPorts, but here’s a few comments about what it sounds like you’re trying to do. Migration from old macOS Server. I’ve done this myself, trying to follow https://developer.apple.com/support/macos-server/macOS-Server-Service-Migration-Guide.pdf. This Apple migration guide is helpful, but deficient in several key aspects, e.g. DNS, VPN, Calendar and Contacts, and Mail. FWIW, here are my own notes on migration: • https://github.com/essandess/macOS-Open-Source-Server • https://github.com/essandess/macOS-Open-Source-Server/blob/master/macOS%20Server%20Migration%20Notes.md Also, I could be wrong, but it sounds like your trying to migrate your services on the same server as your old, running Server.app version 5.7. This would be a Very Bad Idea. Rather, buy a new box, configure it as a sandbox, harden everything, migrate user data, then deploy. Or at least do this on a VM with its own independent DNS address, then be prepared to save the disk image and write over the old box. It’s easiest and best just to get a new box, and keep the old one around just in case. The new Minis are great for this, and used 2012 Minis that can be upgraded to 10.14 are available quite inexpensively. Running a Mail Server. There is no more Server.app Mail server. If you decide to run one yourself, it means knowing what every line in the postfix and dovecot and rspamd configuration does, and knowing and checking the user and group permissions of all files and directories used for the mail server. You can’t assume that the MacPorts mail-server example—or any other—configuration is appropriate for your own network or users. You have to check it line-by-line and test it before you adopt and deploy it. If you’re not willing to embrace these steps, you should purchase a commercial mail server, or use a cloud service email provider, for which there are many options. Aside from the basic rtfm’s on the MTAs and MDAs, here’s a few helpful background links on configuring a BSD/Linux mail server: • https://www.c0ffee.net/blog/mail-server-guide/ • https://arstechnica.com/information-technology/2014/02/how-to-run-your-own-e-mail-server-with-your-own-domain-part-1/ Whether or not you decide to run your own mail server, transitioning from the old Server.app version 5.7 that’s running a full suite of services means configuring a new box from bare metal up. You’ll need to do this step-by-step. One thing that’s still useful useful with the latest Server.app is TLS certificate management, whose cents can be dropped straight into the postfix and dovecot configuration used in the mail-server port. Getting back to your specific MacPorts question above, yes, if you change your network settings the Portfile activation stage will detect this and change default settings appropriately. However, as mentioned, it’s on you to make sure the settings in this example configuration are the ones you actually want for your own network and mail server, and edit the actual configuration appropriately. I’ve had my own mail server transition from Server.app for about six months now, and it’s much nicer than the old one, and, I believe, more secure: postfix run in chroot, up-to-date MTA and MDA services, a blazingly fast anti-spam capability with much-improved spam/ham training workflow, and DKIM configured on the box. After I got it configured and running, I haven’t had to touch it through multiple MacPorts upgrades of postfix and dovecot.
