Yes, Apple has restored the ability to set a user and system umask in OS X 10.10.3. This is a huge fix for users of shared storage. Xsan and all SANs where users want to be able to share files, projects and all things without using ACLs or any LDAP directory. This is great. I am jumping up and down. So happy. So many people wanted this. Anyone using shared storage have been demanding this since the upgrade to Yosemite. 10.10.3 is out today and we will be happy.
Recently Munki v2.01 was released and now more than ever with the help of other apps it is easier to automate software deployment. With help with AutoPkg (and AutoPkgr) you can quickly set up a Munki server to deliver software to all your Macs. In the time it takes to download one new app and update each of your client workstations you could instead put it in your Munki repo and have it ready to deploy to everyone.
Munki allows you to automate software deployment. When you have more than one or two Macs to ensure that they are up to date with security, Flash, Java or other app updates you being to realize that an automated system can save you time and maybe even your sanity. You don’t backup manually, of course, you automate it. When it’s important and you want it done right, then some planning ahead of time and automation will make your life much easier.
If you have not yet set up a Munki server then follow along as I walk you through setting Munki 2.01 with AutoPkgr 1.1 in part 1 of this blog post of Munki and AutoPkg. In part 2 I will go into further detail of how to use MunkiAdmin (Mac app) and Mandrill (a node.js web server) to edit and maintain your Munki set up. Pros and cons of each method will be touched upon. Using the command line in the past was required but I will show you how some really good apps and web services can help you maintain your automated software deployment workflow.
Note: Munki requires only a web server to deploy software, while traditionally the munki tools ran on a Mac. You can put your software repo on any web server. I will show you the set up on a Mac for the purposes of this blog post.
Steps to a basic Munki server set up on a Mac running 10.8, 10.9, or 10.10:
3. Set your Munki repo to some folder (for example, /Users/Shared/munki_repo)
Munki repo
4. Set up web services on OS X by manually editing httpd.conf document root to your Munki repo or with Server.app, setting your munki_repo as where you store your site files.
Server.app Website document root munki repo
6. Add recipes to AutoPKGr and choose apps. Set a schedule for AutoPkgr.
Configure AutoPkgr
7. Check for apps manually the first time, and let AutoPKG download them to your repo
Configure AutoPkgr schedule
8. Check your repo for a manifests folder, and if it is not there, create it
Munki repo manifests
9. Download icon importer, move to /usr/local/munki folder, run against your repo
cd /usr/local/munki ; sudo ./iconimporter.py /Users/Shared/munki_repo/
iconimporter munki repo
Next, go to the icons folder in your repo, pick a fav icon and rename if necessary (some have more than one icon with name with “_1, _2, etc”).
10. Open MunkiAdmin and add packages to catalogs as needed, edit package info (add developer and category info, descriptions etc as needed), then create a client manifest.
11. Choose apps to install for clients (choose from installs, optional installs, uninstalls)
Done. Your munki server is set up and ready for clients to connect. Next up, in part 2, we will look at Munki’s client facing app, the Managed Software Center. We will also look at how to use Munki Admin (Mac app) and Mandrill (a node.js web server) to edit and maintain your Munki set up. Pros and cons of each method will be touched upon. Using the command line with Munki was required in the past but the Munki ecosystem has grown and there are some really good apps and web services can help you maintain your automated software deployment workflow.
Apple released Yosemite (OS X 10.10) today. The big news for me is the built-in version of Xsan is v.4. But don’t get too excited and upgrade your OS without some planning (and backups). If your systems are in production then please leave them as is. Install OS X 10.10 on a test system first. Install a test Xsan and play with that. Don’t test in production. ‘Nough said.
What you need to know is, if you upgrade your Mac to 10.10 then it is officially incompatible with Xsan 3. You can NOT have Xsan 3 (10.9) clients on a 10.10 Xsan, and I don’t think that 10.10 (Xsan 4) clients will work on a Xsan 3 based SAN. There may be a hack to get incompatible versions working together but that’s left to imaginative tinkerers and not useful for production where deadlines are involved.
I’ve done some basic testing with Xsan 4 and it does away with the Xsan Admin app, all setup is done in the Server.app. Also, it depends on Open Directory (and DNS, of course). If there is no OD master set up then it will create one (same with DNS). If you have OD then join your Xsan controllers to it as replicas or else they will create a new OD master on the first Xsan controller and a replica on the second. You were warned.
To configure the clients you export a config profile and install it on the clients, or alternatively you can enrol the Xsan controller in MDM (Profile Manager, for example) and push out the config to the clients.
I have not tested Xsan 4 with StorNext but I expect there is compatibility, as usual.
In Summary:
More testing is needed, but strictly speaking Xsan 4 is not going to work with Xsan 3 and vice versa. If an Xsan 3 (10.9 client) is part of Xsan 4 (10.10) then it may work but commands and configs will not come across (unmount / mount the volume, the volume is destroyed stop looking for it, etc).
And now for some screenshots of the actual setup.
Step 1. Install Server. Turn on Xsan and get ready to rumble.
Step 2. Change your name. If you’re using dot-local change it.
Step 3. Set up valid DNS
Step 4. Set up a new SAN
Step 5. Choose a SAN name
Step 6. Configure Users and Groups (OD)
Step 7. Choose your organization name
Step 8. Create the Xsan volume
Step 9. Add LUNs to your storage
Step 10. Save a configuration profile
Step 11. Deploy config to clients
Use MDM or manually deliver the file to your clients.
Summary: On OS X create “exports” text file describing your share that you want to export over NFS. Server.app is not necessary or needed. On the client the fstab file will describe the client end where the share gets mounted. Note: use whatever text editor you wish, whether it is vi, nano or TextWrangler, etc.
Server:
1. “sudo vi /etc/exports” example:
/MySharedFolder -maproot=nobody
2. “sudo nfsd checkexports”
Check the correctness of exports file
3. “sudo nfsd enable”
Start nfsd
Note: run “sudo kill -1 `cat /var/run/mountd.pid`” is nfsd had been running previously and you want to reread exports.
4. “/usr/bin/showmount -e”
Test the share. It should show something like: “/MySharedFolder Everyone”
Client:
1. “mkdir /MyShare”
Make the mount point for the NFS share
2. “vi /etc/fstab”
Edit the fstab file to show the mounts you wish to have
