Results tagged “10.9” from Bill's Words

I’m not impressed with Mavericks Server or Yosemite server, either, for that matter. First, Apple has moved all of the standard binaries and settings from their usual homes into the Server.app bundle and into /Library. While this certainly lines up better with the Apple “way,” it makes it a royal pain in the butt for those of us who have half a clue and know their way around a LAMP (or MAMP) system.

I decided to update our server from an Xserve to a mini about three months ago. The new mini arrived, and I thought, “This should be ‘Apple simple,’” and tried to migrate. It was a disaster, mitigated only by the fact that I had a backup of the original system—somewhere in the migration process, files on the original server get mangled. This shouldn’t be, of course, but…

I tried various methods of upgrading and none were successful. Open Directory gave me fits, and I spent hours trying all sorts of things, none of which were successful. So today, I decided to go nuclear: start from scratch on the new server. That way, nothing could go wrong.

Right?

Sigh…

Since Open Directory gave me many fits, and since I knew OD is somewhat finicky about DNS entries, I decided I’d start with the basics.

Setting the Hostname

What is the name of my host? Well, Apple, in their infinite wisdom, asked my DNS to tell what the host name is, instead of asking me. So the host name was wrong because it was based on an outdated entry in the upstream DNS. So the self-signed certificate had the wrong data, too. To fix this, I changed the upstream DNS name, deleted Server, deleted /Library/Server/, and rebooted. I then reinstalled Server.app and this time the server name and self-signed certificate data were correct.

As it turns out, I could have used Server.app to change the name and the self-signed certificate would have been regenerated. But I found that out too late.

Server.app Pro Tip: When changing hostnames, Server.app will generate a new self-signed certificate.

Setting Up DNS

Next step: DNS. This should be simple. I should just be able to import a zone file, but, alas, unless I migrated the server, nope. I thought about just typing in all the hosts and whatnot, but what a pain in the rear that would be. Also, you can’t use wildcards in hostnames. So instead, I turned on DNS, set the forwarders to 127.0.0.1 and the upstream servers, and looked at the files in /Library/Server/named.

Complaint: There’s no way to reorder the forwarding servers in Server.app, without retyping the whole list.

Complaint: You can’t type in an asterisk (wildcard) when editing a host name. So aliases like “*.eccles.net” can’t be used without manually editing the hosts file. Still true in Yosemite.

Complaint: Manually-entered wildcards get deleted from the hosts file if you edit the zone with Server.app.

Server.app Pro Tip: Editing zone files is possible, but any changes made in Server.app will overwrite most (if not all) edits.

Now for Open Directory

OK, now that my server knows who it is, it’s time to turn on Open Directory. A few clicks and that was done. I now had a fresh Open Directory master running. Now let’s import some users. (Since I never really monkeyed around with OD in any other version of Server, a plain vanilla OD Master is fine for me here.)

Server.app Pro Tip: Set the Directory Administrator user to diradmin and set the password to be the same as the server administrator password. If you’re like me, you’ll stand a much better chance of remembering these credentials that way.

Importing Users

I exported the users from my 10.6 server (select the users in Workgroup Manager, then use some other command which I can’t remember) and tried to import them using 10.9.

Server.app Pro Tip: Importing users is not found in the “Users” pane in the “gear.” (Why not?) Instead, it’s here:

in the Manage menu. Server.app kept griping about my username and password. My question is, What username and password? The dialog says “Admin Name” and “Password” but doesn’t give a clue which thing it is I’m trying to authenticate into. I assumed it was the server, and several times, I was wrong. I then decided it might be the OD server that I’m trying to authenticate into, and that turned out to be right.

Complaint: Server.app could use a better prompt than “Admin Name”. How about “Open Directory Server Administrator Name”? It’s long, yes, but it’s better to try to fit that into the window than frustrate the user, don’t you think?

Complaint: If that’s too long to fit, how about improving the error message? “Credentials could not be verified. Username or password is invalid” could just as easily say, “Open Directory server credentials…” to save me a few tries and Googling.

Server.app Pro Tip: This dialog:

is asking for the Open Directory administrator username and password (which you just created—see above).

While the import was a success, it left me with questions. First, I have several users with more than one shortname (most, in fact). What happened to these additional shortnames? And what do I do with the blank “E-mail address” box in each user’s information? Does something go there? Does something have to go there? What’s up with that? Let’s tackle each one of these separately.

About those multiple shortnames: It turns out that they are, indeed, imported into the new Open Directory server, but only the first (primary) shortname is displayed. I verified this by making test SMTP sessions and watching the SMTP logs. Messages to all of a user’s shortnames were successfully delivered. Yosemite note: not true anymore. See below.

Managing these shortnames is tricky, though, and can probably be accomplished with a command line tool of some sort, though I was unable to figure out how to do it. (I gave up after ten minutes of Googling.) I stumbled upon an Apple support page which describes how to edit Open Directory records with Directory Editor.

“Directory Edi… wha…? you’re saying, I’m sure. Yes, one of the older apps hidden away from most users is Directory Utility, which I never use other than to enable root user. So what’s changed to make it useful? It has a new pane called “Directory Editor” which allows Open Directory directories to be edited. (Clever name.)

You can find Directory Utility using the Apple-given instructions at the link above, or you can…

Server.app Pro Tip: Make an alias to /System/Library/CoreServices/Directory Utility and stick it in your dock.

In DU, you can edit everything about an OD entry (hence the reason it’s probably hidden from most users’ attention). Since the server is local (it’s on the same machine), authenticate into the node at “/LDAPv3/127.0.0.1”, as shown below:

Each user will have a RecordName which will correspond to the primary shortname. If you have any users with multiple shortnames, you’ll see that they have more than one RecordName. If you want to add another shortname, you can do so with the “+” button out to the right of RecordName, as shown below:

Server.app Pro Tip: Multiple user shortnames can be added, edited and deleted in Directory Utility. But this isn’t really useful in Yosemite.

How about that “Email Address” field in Server.app? What does it do?

I have no idea. [Though it turns out to be useful in Yosemite.]

When a user is created, it suggests the E-mail address based on the user’s shortname. If you change it to be different from the suggested address, it does end up being reflected in the OD entry, but PostFix (the mail server) has no idea what to do with it. E-mails addressed to the different address will bounce. E-mails addressed to shortname@domain.tld will be delivered.

Server.app Pro Tip: Leaving the E-mail address field in a user record blank is OK. Except in Yosemite, that is.

Yosemite update: I upgraded from Mavericks to Yosemite. It now ignores the multiple shortnames specified in Directory Utility (see above). For example, my primary E-mail address might be administrator@somedomain.net and I might have an alternate shortname, bill.eccles@somedomain.net specified in DU. In Mavericks, I had to add the bill.eccles shortname manually using DU, per the above. I could successfully receive E-mail to either address. The E-mail address field meant nothing.

However, when I updated to Yosemite, PostFix doesn’t have any idea about these other shortnames/addresses anymore, even though they do show in Directory Editor. Panic ensues when incoming mail to these alternate shortnames bounces. This problem is reasonably-easily fixed by adding them to the users in the User editor in Server.app. But if you’re confused because the “+” button is grayed out for the user you’re trying to edit, it’s because you’re not authenticated into the appropriate directory node.

At the top of the list of users, you’ll need to filter to show only the “Local Network Users.” Then you’ll be able to double-click and edit a user. The “+” sign will be enabled for adding more E-mail addresses to the user. This has the same effect as editing the “EmailAddress” for the user in Directory Utility and does not effect the “RecordName” list. It might be a good idea to go back and remove the extra shortnames in the “RecordName” list, but I don’t know. And I haven’t done that yet, either.

About Users’ Passwords

Passwords are lost in the export/import process. It seems that it should be possible to find the various hashes in the older version of the server using mkpassdb, but I can’t find enough corresponding entries to know that I’d make the new server totally happy. The next question is how to handle passwords, since my users use the server only for mail (via IMAP or POP) and won’t have OS X’s native password changing dialogs.

It turns out that there’s a reasonably easy way to handle that, too. If I turn on the default SSL website (in the Website pane, naturally), I have the option to let users change their passwords. I tested this path, and it works well. But because my users come from outside the local network and have to traverse my firewall (which means all port 80 or port 443 access can be directed to one machine only), I have to either (a) migrate all the web services from the old server to the new or (b) set up a special port for accessing this server for password changes. I’ve chosen this latter method in order to make accessing the password change page more difficult. There is no way to change the default server port number, so this change will be done entirely at the firewall, redirecting port N to port 443.

Moving Mail Services

Mail services are somewhat tricky, but now that you have your users moved over, you can pretty easily move the mail to follow them.

First, turn off mail services on both the new and old servers using the Server.app. Then, we have to move the data from machine to machine.

Mail data exists in two places. There’s the Postfix SMTP spool files (mail which is in the process of being delivered) and the Dovecot IMAP spool files (mail which has been delivered to the users’ mailboxes).

First, get the SMTP files from the old server:

sudo tar cf smtp.tar /var/spool/postfix

(ignore the warnings about tar format cannot archive this (type=0140000): Inappropriate file type or format These are sockets and won’t archive, nor would you want them to.)

Get the mailboxes:

sudo tar cf mail.tar /var/spool/imap/dovecot/mail/

Copy them to the new machine somehow, e.g.:

scp smtp.tar admin@192.168.1.2:~/smtp.tar
scp mail.tar admin@192.168.1.2:~/mail.tar

Now put them where they belong.

Most likely, you already have mail directories where they belong, but they need to be cleaned out to prepare for new data. So here we’ll delete the mail data directory (i.e., clean it out… permanently!) and repopulate it with the mail from the original server:

sudo rm -R /Library/Server/Mail/Data/mail
mkdir -p /Library/Server/Mail/Data/mail
cd /Library/Server/Mail/Data/mail
sudo tar xf ~/mail.tar --strip-components=5
cd ..
sudo chown -R _dovecot:mail mail

Then we’ll make the spool directory (if it isn’t there already) and populate it with the spool data from the original server:

sudo mkdir -p -m 755 /Library/Server/Mail/Data/spool
cd /Library/Server/Mail/Data/spool/
sudo tar xf ~/smtp.tar --strip-components=3

I think this all I did, but you may have to jigger your permissions and ownership so it looks like this:

home:spool admin$ ls -la
total 0
drwxr-xr-x  16 root      wheel      544 May 26  2014 .
drwxr-xr-x  13 root      wheel      442 Aug 10 12:17 ..
drwx------   2 _postfix  wheel       68 Jan  2 19:15 active
drwx------   2 _postfix  wheel       68 Dec  8 08:00 bounce
drwx------   2 _postfix  wheel       68 Feb 19  2010 corrupt
drwx------  18 _postfix  wheel      612 Aug 10 12:33 defer
drwx------  18 _postfix  wheel      612 Aug 10 12:33 deferred
drwx------   3 _postfix  wheel      102 Dec  2 13:55 flush
drwx------   2 _postfix  wheel       68 Feb 19  2010 hold
drwx------   2 _postfix  wheel       68 Jan  2 19:15 incoming
drwx-wx---   2 _postfix  _postdrop   68 Aug  8 02:01 maildrop
drwxr-xr-x  24 root      wheel      816 Aug 10 13:19 pid
drwx------  27 _postfix  wheel      918 Jan  1 14:01 private
drwx--x---   7 _postfix  _postdrop  238 Jan  1 14:01 public
drwx------   2 _postfix  wheel       68 Feb 19  2010 saved
drwx------   2 _postfix  wheel       68 Dec 31 21:59 trace
home:spool admin$

So what’s next? PHP, web services, and other things… but that will have to wait until a future article. This one’s already long enough.