8 Replies Latest reply: Dec 7, 2013 9:34 AM by MrHoffman
Ralston Champagnie Level 1 Level 1 (105 points)

In a few days, I'll be buying my first Mac Mini to use as a server for my home office and media room. I plan to borrow a monitor so I can set and configure the Mac Mini. However, I don't plan to have a monitor...actually, I don't want to have one. So, I wanted to be very clear that I can control and monitor the server from my MacBook Pro...not just share the screen.

 

Also, Since the Mac Mini will have Mavericks, I wanted to sync itune that will be on the server with my AppleTV.  Alternatively, I could run a twenty-five feet HDMI cable and attach the Mac Mini via a HDMI switcher to my LED projector. I could then use a wireless keyboard with the built-in track pad if I need to but that a last resort.

 

I am eager (maybe anxious) to set the server up. I have been reading the post here for a few days now. I think I will buy the base Mac Mini and eventually replace the hard drive with may be a 64 - 128 SSD, since I have a 10TB G-Raid Pro to attach to the Mini. Is there any preferred non-Apple SSD for the Mac Mini?

  • 1. Re: Controling and Monitoring Server with MacBook Pro
    MrHoffman Level 6 Level 6 (12,455 points)

    Server is unrelated to and does not particularly contribute to iTunes or AppleTV, beyond what Mavericks itself provides and maybe Caching Server 2.

     

    You can use Server.app on the client to connect to the server box, as well as screen sharing and ssh command line sessions.

     

    I would recommend having a keyboard and display handy for the initial configuration, but you've covered that.

  • 2. Re: Controling and Monitoring Server with MacBook Pro
    Ralston Champagnie Level 1 Level 1 (105 points)

    Thank you MrHoffman for responding. To be clear, are you saying that when I purchase the Server 3.0 app, I should install it on both my MacBook Pro (client) as well as the Mac Mini, so controlling and monitoring would be seamless?  I am new to Server app.

     

    Also, I am glad that I will able to put Mavericks on the Mac Mini to use (AppleTV, iTune, iPhoto, etc.).

  • 3. Re: Controling and Monitoring Server with MacBook Pro
    MrHoffman Level 6 Level 6 (12,455 points)

    Ralston Champagnie wrote:

     

    Thank you MrHoffman for responding. To be clear, are you saying that when I purchase the Server 3.0 app, I should install it on both my MacBook Pro (client) as well as the Mac Mini, so controlling and monitoring would be seamless?  I am new to Server app.

     

    Yes, you will use the tool known as Server.app to connect to and manage your server both locally (directly on the server) and remotely (from your MacBook Pro), though you do not want to perform the installation that will offered by Server.app on any systems other than on your server.  You'll be connecting to another host (your server), which will be one of the options offered by Server.app when you invoke it.  This will probably be rather more clear when you first see the Server.app launch screen.

     

    General caveats for new users of OS X Server:

     

    Assuming a typical NAT'd network, you will want to get DNS services going on your server and on your network first, and this is local DNS services.  DNS should be configured and stable before starting any other services.  You can verify this by launching Terminal.app from Applications > Utilities and issue the following diagnostic command:

     

    sudo changeip -checkhostname 

     

    The usual expedient of referencing ISP DNS servers will not work here, as your server will want both forward (name to IP address) and reverse (IP address to name) and ISP DNS and Google DNS and such cannot provide reverse DNS. 

     

    I'd recommend registering a real domain for your network, or using a subdomain of one you already have registered.

     

    Do not use .local as your top-level domain.

     

    Also in general: stay out of the 192.168.0.0/24 and 192.168.1.0/24 IP subnets if you might ever use a VPN to connect into your network.  There are many other good private subnets to choose from.  The earlier you get out of those subnets and into some other subnet within one of the private IP blocks, the better.

  • 4. Re: Controling and Monitoring Server with MacBook Pro
    MrHoffman Level 6 Level 6 (12,455 points)

    OK; was in Mavericks Server.app just now and thought to grab the startup display...  On the MacBook Pro client, invoke Server.app and select the leftmost Other Mac button to connect to and manage the server.   Don't click the Continue button here...

    Server.png

  • 5. Re: Controling and Monitoring Server with MacBook Pro
    Ralston Champagnie Level 1 Level 1 (105 points)

    Thank you MrHoffman for responding with detail insight. I have a Mikrotik 450G (master) to which I have an Apple Extreme (my private network) and a Linksys access point (my guess network) connected. The Mikrotik is set up to do DNS cache and I had planned to put the Mac Mini on my private network (Apple Extreme) through either a VLAN or a VPN on the Mikrotik so that on the Apple Extreme I could enable DHCP-NAT. Then I should be able to set the Server to DNS cache. Would that pose any issues?

     

    Also, on the client side (MacBook Pro) would I am able to control the Server (Mac Mini) via GUI? I am not very proficient with the Terminal command line but realize it would definitely be an opportunity to learn more.

  • 6. Re: Controling and Monitoring Server with MacBook Pro
    MrHoffman Level 6 Level 6 (12,455 points)

    You need a DNS server.    A DNS cache and a DNS forwarder are not DNS servers. 

     

    Anything that you might cache and anything you might forward will not have your LAN-local IP addresses and LAN-local host names.

     

    Most folks know about name to IP address, but it's IP address to name — the reverse translation — that's key to running a server, and to server authentication and local network security.

     

    Please set up OS X Server as a DNS server, or obtain and configure some other box that will provide local DNS services on your LAN.  (Consumer-level network devices usually do not include a DNS server.)

     

    Please do not skip this step.  Skipping the local DNS set-up usually means you'll eventually have to reset and reload Server.app, and start over again.

     

    As for the GUI, once the connection is made to the server, there's no difference with Server.app, whether it's running on the client or on the server.  Same GUI, same capabilities.

  • 7. Re: Controling and Monitoring Server with MacBook Pro
    Ralston Champagnie Level 1 Level 1 (105 points)

    MrHoffman, thank you for sharing such great info. I have purchased the Mac Mini, the Server 3.0 app, as well as a personal domain name. However, I want to know what you do about SSL certificate. The prices for one don't support personal noncommercial use. I know of the option to create one; however, a third-party one raises legitimacy, so what does most folks generally do here?

  • 8. Re: Controling and Monitoring Server with MacBook Pro
    MrHoffman Level 6 Level 6 (12,455 points)

    Different question and probably better as a different discussion.

     

    Warning: long-winded response follows.

     

    Certificates?  That's a question that depends on what you're up to with the web site, and what sort of data you're securing, and who might be attacking you or your users.  It depends on how paranoid you are, and how much you're worth to an attacker, and how much you're willing to pay.  In various ways, security is like insurance.

     

    Full disclosure: I'm a commercial certificate skeptic.  As should become obvious.

     

    There's no difference in the practical network security between a self-signed certificate and a commercial certificate, in terms of what happens with network encryption and related processing.  What you're paying for — beyond the generation of the key, which is just some CPU cycles, and probably also part of why some of the certificate providers can be so sleazy-looking — is having the root certificate already loaded into the remote clients. 

    It's that root certificate and particularly a trusted path to load that root certificate into the clients that is the keystone to the whole implementation, and the target of attack when you're running current security; TLS 1.3.   (Older SSL and TLS are cryptographically weaker, beyond just the initial key exchange.)  That's what you're really paying for.   The commercial providers already have those root certificates already loaded into the most common clients.  

     

    Yes, self-signed certificates can also have a certificate chain and a root certificate and the signing and all the rest, and the root cert can be manually loaded into the clients via command line or via Keychain or via Profiles, and that'll be just as secure as a commercial cert.   That'll be just as secure.

     

    I'd generally avoid loading and generally trusting somebody else's self-signed root cert.  The attack against self-signed certificates involves getting an untrusted root cert or leaf cert loaded.   But then some of the certificate authorities have already been compromised, so even the supposed imprimatur of a commercial certificate is probably not be worth all that much against a determined adversary.  (If you're paranoid and/or if you're a target, "trust, but pin.")

     

    In practice, a certificate provider that's in your list can do the same thing, by issuing bogus certificates.  You're effectively trusting all the providers in your keystore, as well as all the delegates they've authorized.   (Put another way, if you're considering defending against a national-level security agency and you have any trusted certs that a national entity or a criminal organization might have access to, well, you're toast.)

     

    There's a whole discussion of communications intercepts — what's called man-in-the-middle or MiTM attacks — and certificate pinning and related details, too.  This is how a rogue certificate provider can be used to attack network encryption, and pinning can be used to detect these attacks.  But I digress.

     

    If you control the clients that need security, then you can run your own private certificate chain if you're so inclined.  I've set that up at various locations.   If you're maintaining your own clients and not serving much to the web (and are not serving via HTTPS / SSL  / TLS), then using a self-signed certificate works fine.  Now if you're dealing with financial data or credit card data or other sensitive data, then you'll be purchasing a certificate.

     

    If you're serving to random external web clients — clients that you don't have influence or control over, and can't load the cert or the root cert in a trusted path — then you can either serve just HTTP (TCP port 80) and ignore it all and run a self-signed certificate internally, or you can run HTTPS (TCP 443) with a self-signed cert and let the remote users decided what they want to do here (and whether they are willing to add trust for your certificate — if they're smart, they will either look at the cert and decide for themselves, or they won't accept and won't use the cert, and probably switch to 80 — or you acquire a commercial certificate and the air of trust that such a purchase supposedly somewhat sorta-kinda conveys.

     

    Been meaning to post a certificate how-to for a while, but haven't gotten that done yet.  I do have an SSL-related article posted for another operating system, and that same OpenSSL library and SSL / TLS support is underneath what OS X uses for its network security.  The non-OS-specific bits of that do apply to OS X and OS X Server.