Take Control of OS X Server, Chapter 3: Preparation and Installation
This is the most important chapter in “Take Control of OS X Server,” because getting OS X Server properly installed and configured on a clean installation of OS X 10.9 Mavericks is essential for future reliability and stability. These instructions don’t always take the most obvious route because hard-won experience has shown that extra effort at the start can prevent significant troubles later on.
I think you hit your goals with this chapter -- certainly seem to have hit mine. I found that the Apple tutorials told me *what* I could do, but gave me absolutely no clue as to *why* I might want to use any of these services, or in which order I should approach them. I more or less skipped dealing with DNS, on the presumption that I already had perfectly good name servers working for me.
It never occurred to me -- and I don't believe Apple raises the issue in their tutorials -- that I might want to route my server's DNS request through its own service.
After reading this article, I am already planning to consider my current, limping OS X Server experiment as v0.5 on the way to a fresh installation on a new partition. Or maybe even repurposing another Mac just for this.
Thanks!
Matt, thank you very much for this feedback and I hope others will write in as well to let us know how far on or off the mark we are. We can't write one book that covers all use cases (that's for sure!) and we are finding it challenging to not only define which core readership we most want to help but also to make sure the information makes sense for that group, keeping in mind that for some readers this will be an ultimate geek challenge while for other readers it will be the first step in a long journey with OS X Server.
Another challenge is helping readers through areas where just because OS X server has a feature, that doesn't mean the feature is known to work reliably or is generally recommended or likely to work well on typical home or SOHO installations.
And, then there are use cases for which this book flat out won't go far enough. And Charles has soooo much real-world experience that readers might like to tap. Alas. But there is room in the comments here for questions and answers, certainly, and the final manuscript for the final ebook is far from locked down.
When I ran OS X Server (ending with Tiger Server, IIRC), I found it worked well for simple scenarios, and supported more complicated ones, but each time I stepped outside the simple realm, I risked breaking Server Admin. I used aliases and a bunch of virtual hosts, and Server Admin became less and less reliable, until I had to do all my httpd management through text files because the GUI just didn't work.
Some general guidance about what OSXS is suitable for would probably be useful. I don't know my experience is still relevant, but people who read a book about OS X server could probably benefit from at least a paragraph or two on good uses for OSXS, and places where it's technically possible but just not a good idea...
It's interesting how Apple is trying to suggest that it's so easy to set up, mainly by not telling you the complex stuff. I have wasted many hours through not understanding the underlying structures. There are enough problems with wizards not working (such as importing users from an old server being very flaky) without them offering Server Tutorials that skip straight to configuring Calendar Server without mentioning basic set up, let alone Open Directory.
It's also odd that there are so few 3rd party resources. The official Apple training documentation is almost useless in the real world. So well done with this book: I look forward to the rest. fwiw it made me finally pay to become a Tidbits subscriber.
I totally second Andrew's points!
Now I can't wait to read the next chapter on Open Directory since this is what I'm struggling most with.
E.g. I can't get wiki r calendar logins authenticate against our company wide OD records. I hope to get the clues...
I'd agree, getting DNS working right was the biggest hurdle to my understanding of Server back in the Leopard days. Really looking forward to the OD chapter now, as I still struggle with getting this running right, find that following the same steps on two different servers leaves me with different results - obviously not quite the same steps :).
I hope Charles goes into the whole issue of Certificate use with some depth. I can't get my head round the interaction between Certificates in Server, and those in the System Keychain. I find I import a certificate identity into server, and that it does not 'take' in the system keychain. Trying to use Profile Manager in that case is an exercise in repetitive frustration!
I echo Henry Harrison: I hope that there is a comprehensive section on procuring and installing certificates... along with whys and got-chas.
And thank you for this Mavericks Server manual!
3 names? "A server actually has three names: the LocalHostName, and the HostName and the ComputerName, which are frequently the same." Maybe a sidebar explaining what the differences are and why 3 names exist would be useful.
Adding!
I don't get why you use the same name for HostName and ComputerName. Since this is sth. to set up very early I would love to know the reasoning behind this practice asap. Is this explained somewhere on the net, that I can read right now to get a better understanding?
THX for your excellent Server Guide (the best I found so far on the internet).
For DNS settings on server and client, what would you enter for search domain in your example setup? mavserver.pretendco.lan or just pretendco.lan?
We'll see what Charles says, but I don't think the search domains list is particularly relevant to most installations. Basically, whatever you enter there is used to complete typed domains, so if you had apple.com in the field, you could theoretically type "store" in Safari and the Mac would go to store.apple.com. I say theoretically, because Safari would probably do a Google search on that now, as would other browsers. I'm not certain what apps would use the search domains in a helpful fashion.
I'd just leave it blank - it's only a minor help if it were to work as advertised, since most Internet apps provide shortcut or bookmarking capabilities that obviate the need for typing abbreviated names.
http://support.apple.com/kb/PH6373
Correct. Search domain is really to make it easier to find things for your users. Therefore, if you set it as pretendco.lan, then they can hit the server just by using the name mavserver. It's a nice-to-have if there's a consistent domain name in use. You can also have multiple entries in here and distribute them via DHCP, to further make things easier. Good luck!
I just want to confirm, you use "sudo scutil --set ComputerName mavserver.pretendco.lan"
Then, when you've launched server.app, it shows the computer name as "mavserver" in your screenshot.
Is that correct? I used a different set of names, test.miller.lan (hostname & computername) and test (local host name) and when I launched server, it showed test.miller.lan for both the host name and the computer name. So i'm afraid that there is a typo in your instructions? However, interestingly, after turning on "enable screen sharing and remote management", the overview screen showed a computer name of "test". wacky
Yes, I also have a query in to Charles on this due to further testing that happened after this chapter went live. It seems that when you enter a standard domain-style name for ComputerName, it's later truncated to just the initial part of the name. He hasn't looped back to that chapter in the book yet, but we'll see what he says.
I usually use a Fully Qualified Domain Name as the ComputerName. The Apple books say to use a single line name (e.g. mavserver). I've found that the only thing this usually impacts is how the server appears in sidebars and as mentioned earlier, remote management. Never seen it cause any problems. But when I use the FQDN it often smooths some of the sanity checking. Hope that helps!
everywhere and "The Apple books say to use a single line name (e.g. mavserver)" for MachineName.
vs.
"But when I use the FQDN it often smooths some of the sanity checking."
I have been reSEARCHing and reading lots of hours on that very topic and could not find any evidence for your suggestion. But I value your reputation and your experience - so could you please explain what you mean with "to smooth sanity checking" ???
I've had Open Directory pass upgrade checks when using the FQDN rather than the single line domain name. You can change this later, so your HostName when you set it up and if you have any issues upgrading an ODM later, use the FQDN temporarily (scutil makes it pretty easy to change) and put the single line back in when you're done.
This doesn't matter nearly as much as it used to, when the password field had the name of the PasswordServer in it. Hope that helps.
My guess is that this used to be a big deal, but at some point Apple changed something under the hood, hence the conversion of the FQDN to the short version.
One thing I've come to realize about OS X Server is that there's a ton of spaghetti down in the works that's entirely undocumented, and as a result, the community has learned certain behaviors from hard-won experience. Since Apple does dip down into the spaghetti periodically to clean up specific issues, some of the lessons learned by the community may no longer be relevant in every situation going forward. The problem is that you never quite know until you run into the issue. :-)
@cEdge318 @AdamEngst:
Thank you for your helpful explanations. Very useful to me.
When using the FQDN as the ComputerName, the full FQDN is shown in the sidebars of the client macs. Such a long name is annoying in the sidebar.
A note on the DNS section: When I opened the DNS service, I found that the button for adding a record was labeled "+." instead of "+", and I was taken to a screen that configured Primary and Secondary Zones. I finally figured out on my own that I was seeing a filtered view. The "gear" button menu at the bottom of the main DNS screen allowed me to "Show All Records", the dot next to the "+" was retired, and I was then able to follow the instructions for adding a DNS record.
This may have had to do with my uninstalling and reinstalling Server, so I could start configuring from scratch, but I suspect other readers will run into this puzzling side road.
I'm guessing that your previous installation had some part in this; Server can be a little squirrelly about starting clean. For this chapter, things are easier if you deselect Show All Records.
Thanks, Adam. I agree with you on that. My point is that on my first foray into Server I didn't do anything with the DNS service, and had no idea what I was seeing with a "+." button. A single sentence instructing the reader to click the gearbox and deselect "Show All Records" would help. (I think there's a sentence like that in Chap. 4, but of course it's out of sequence for where it's first needed.) Thanks!
Thanks - I'll look at that next time I'm in the file. This book is tricky that way, since there are a lot of things in Server that look different if you've gone out of order. :-)
In the section titled "Verify That the IP and Hostname Match", I found that the changeip command did not work for me until I did a second restart of my Mac once Server was running. Since you imply that additional Unix commands are installed with Server, that wasn't too hard to troubleshoot, but a mention would be helpful for readers who are stymied, since in Chapter 4 you warn them not to proceed with Open Directory configuration until changeip shows that their DNS names match.
Yeah, there's some funny stuff going on there. The changeip command is located within the Server app itself, so that has to be installed and seen by the system to be accessible. The order of the previous chapter and this one were fairly carefully designed so that should work, but it sounds like it's not always consistent. We'll add some information about potentially needing another restart.
Dynamic DNS services give you a domain name consisting of three parts. If I understand aright, this results in a HostName like:
mavserver.myhost.example.com
I don't think there's any inherent restriction on what a domain name managed via dynamic DNS has to look like. It's possible that some dynamic DNS providers require a four-part domain name.
Alerts aren't working for me (Yosemite beta). Do I need to turn the mail server on for them to be sent? I don't want push alerts, because they'll get sent to all my devices, right? I just want emails.
Just so others see this - alerts don't seem to be working at all in the Yosemite beta. As push notifications, they are working in the current version of OS X Server, but it doesn't appear that they're sent to all your devices. I got an alert for the recent upgrade to v3.2.1, and it appeared only on the server Mac.
I'm looking into whether the mail server needs to be active, since I didn't get an email alert for the upgrade like I should have, but I don't have the mail server enabled, and I'm not sure how OS X Server could know where to point for SMTP without it.
The changeip command is no longer available in my configuration!! I installed a fresh 10.9.5 today, but the command: "which changeip" gives no result!
So verifying Hostname and IP no longer work.
Weird!
I did some research because I expected that this was the commandline tool that was somewhere deep down the server app.
Indeed it is! There is indeed a warning in your instructions, but even while I followed those precisely, that "changeip" tool is only available inside the app package. Can I copy it myself? to the usr/sbin location?
Finally I found out that the PATH to this app for some reason was not included in the PATH. After issueing an echo $PATH command, it finally showed up and afterwards the command worked.
Still I don't understand what has happened.
I'd just call it directly. Things change here and there, so might have been true in a .1 or .2 release and not later. I'll try and update the text to include the full uri to the file instead. Since you only really need it during setup I don't think I'd bother putting it in the path every time.
Thanks for the heads up!
I have ML server set up in a HO environment and wanted to transition to 10.10 and Server v4.0 with fresh install new Yosemite features etc. Good info but the audience this book is addressed to is so much different from typical TC book. I would much rather have a TC of your home network including OS X server v4.0. In the intro you said "Charles focuses in this book on smaller installations, such as a home user looking to set up a personal server". . . that is me and this just doesn't reach me on my level.
I fear that the simple fact is that the average user should not be running OS X Server. We can explain a lot, but running a server requires more technical experience and pretending otherwise is a recipe for confusion. That's not to say that OS X Server is inappropriate for a home office, just that you'll need to know a bit more than the average person who reads email and browse the Web to get much out of it.
I guess this is a pretty basic question, but I don't see it addressed here. Can I access my server remotely, other than using Screen Sharing? In other words, can I install the Server app on another Mac, and control my server from it? If so, what's the setup?
The Server app can work from another machine via Bonjour if remotely controlling from the same lan. I have done an ssh tunnel to access it from the wan as well. Should be port 311 and shouldn't need any special setup on the server side other than ssh.
After I posted my comment, I found an Apple support document. But I think this should be in the book; it seems like one of the most basic things to know.
This is an artifact of how the book was streamed to TidBITS - we added a sidebar about using Server as a console to another Mac in the next chapter, but in the final book it's moving to this chapter where it belongs.
In short, yes you can do it, but the book recommends against it, since it's all too easy to end up installing and enabling services on your personal Mac. It's safer to stick with screen sharing.
Hi Charles; I asked over on the TidBITS mailing list if there was a Server guru and Adam recommended I just ask you here since I’m a TidBITS member. I’m having trouble getting my Yosemite/Server 4.0 combo to login correctly. Here’s the situation
I have a current generation mini running Server 4.0 and Yosemite with all software up to date. I migrated this using Apple’s “Migration to Yosemite Server on new hardware” KB article from an older mini running Mountain Lion and Server 3.whatever was current before 4.0 was released.
The mini is always logged in with an admin account so that iTunes sharing will work, has a static IP and RJ45 connected Ethernet, and has only File Sharing and Time Machine services enabled. There’s a non admin user that is normally used for afp connections from our two daily driver laptops; both of those are running Yosemite and all updates. The server is normally managed by connecting using Screen Sharing from the laptops then launching the Server app.
Once the server was migrated back in November; all worked perfectly until a few days ago. I logged into check something and on launching Server I get the “Choose a server to connect to” dialog box. I choose This Server like always but instead of connecting to the server services to manage them I get an authentication dialog. The dialog is pre-filled out with the credentials for the admin user (susanh) that are stored in the keychain. Pressing OK gives me the login dialog again instead of connecting…like I had typed in the wrong password. I’ve tried manually typing in both the username and password, have verified the entries in the keychain to be correct, and the password hasn’t been changed in probably a year or more.
Throughout file services and Time Machine services for the laptops continue to work…so Server itself is working, I just can’t get into it to reconfigure anything.
The login keychain for the user susanh has 3 Application Password entries for the user susanh; all have the same password (verified correct)…they’re named 127.0.0.1, flatfish, and flatfish.local (flatfish is the mini hostname).
The computer identity, drive names, IP and all other settings were transferred from the old machine to the new one using Migration Assistant per the Apple KB for doing the migration. This procedure basically says to use Migration Assistant to migrate the settings from the old Mountain Lion server hardware to the new Yosemite hardware then install Server v4, then run it for auto import of the settings from the old Server 3.x installation that Migration Assistant moved over.
Things I’ve tried
-deleting and recreating the keychain entries.
-deleting and reinstalling the Server app on the mini.
-downloading the Server app to my laptop and tried to manage the remote server from the laptop.
-rebooted everything.
-verified no software updates not installed.
-tried using both a different pre-existing admin user to login to the Server app as well as a newly created (post Server 4.0 installation) admin user.
-hooked up a keyboard directly to the mini and retyped the passwords on it just in case something was getting lost via Screen Sharing; although typing in the username in the Server app as well as typing into TextEdit and other apps works fine so I didn’t expect this to help.
It looks like an authentication issue on the server itself…like I put in the wrong password.
One thing I did think of is maybe the server services aren't actually running; in which case maybe I just need to unconfigure and reconfigure it…but I don't know how to do that.
Looking in the normal System Preferences Sharing pane I see that File Sharing is turned on and all the right shares are listed…but the main data share doesn't have anything listed under Users and permissions; and doing a Get Info on that directory I see permissions for wheel and everyone but instead of the group that has normal r/w access to it and is used for mounting the share I just see the word "fetching" under the user column. This used to show the actual group name and permissions.
Is there a way to remove the configuration that Server app is using and force it to allow me to rebuild the Server configuration?
At this point…the only other thing I can think of is to nuke the boot drive on the server, reinstall Yosemite from scratch and then recreate the server services. I would rather not do this unless I have to because I don’t want to have to recreate the dozen or so CarbonCopyCloner scheduled tasks that back up the various shared directories on the server to other places. Before I go that route I wanted to check and see if the server gurus had any other suggestions I might try.
Do you have any idea what might be wrong or any suggestions to try?
Hey Neil,
I've had a couple of scenarios very similar and have a fix that might work for you:
http://krypted.com/mac-os-x-server/unresponsive-server-after-mavericks-upgrade-reset-server-app/
If that doesn't work then you could check out the launch daemons and see if they're running and possibly restart or go digging in some plists to see what's wrong. But the steps in the link have worked really well for me in similar scenarios, so maybe it'll help. Especially since you know that the password is good as it connects you via Screen Sharing.
Anyway, let us know and good luck! :)
Charles
Thanks Charles…I happened across both this suggestion yesterday as well as something I thought of and fortunately my idea worked; although it looks like this would have done the same thing.
As you know; the server settings are in a folder at /Library/Server, my copy of this folder was about 6 GB or so (mostly in the wiki folder) and there's a setup folder with a plist file in it. I figured something might be messed up in there; so I made a .zip file copy of the Server folder as well as copying it to another drive just in case. Then I deleted just the plist file and relaunched Server app…this gave me the "Install Server" option and it ran for a minute or two reinstalling the Server services stuff. Launching Server.app then allowed me to login correctly and all the previous shares came back (I guess they're not contained within the plist file but somewhere else in the configuration folder).
So it was either a damaged plist file (although I didn't see anything obviously wrong with it when I opened it in TextEdit) or one of the server services files got damaged somehow.
Glad I didn't have to rebuilt it:-) Thanks again.