I’d written an efi version checker. But the lovely Andrew Seago texted me one that’s better than mine. So I present it here:
current_efi_version=`/usr/libexec/efiupdater | grep "Raw" | cut -d ':' -f2 | sed 's/ //'`
echo "current_efi_version $current_efi_version"
latest_efi_version=`ls -La /usr/libexec/firmwarecheckers/eficheck/EFIAllowListShipping.bundle/allowlists/ | grep "$current_efi_version"`
echo "latest_efi_version $latest_efi_version"
if [ "$latest_efi_version" == "" ]; then
echo "EFI FAILED"
echo "EFI PASSED"
krypted November 2nd, 2017
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment, Uncategorized
efi checker, high sierra, MAC, macos
A bootable installer is one of the fastest ways to install a Mac. Rather than copy the installer to a local drive you can run it right off a USB disk (or Thunderbolt if you dare). Such a little USB drive would be similar to the sticks that came with the older MacBook Air, when we were all still sitting around wondering how you would ever install the OS on a computer with no optical media or Ethernet otherwise. Luckily, Apple loves us.
To make a bootable USB/flash drive of High Sierra like the one that used to come with the MacBook Air, first name the USB drive. I’ll use hsinstall for the purposes of this article. The format should be Mac OS Extended Journaled, although the new system drive will be apfs on the target volume. The installer is called Install macOS Sierra and is by default located in the /Applications directory. Inside the app bundle, there’s a new binary called createinstallmedia (nested in Contents/Resources).
Using this binary you can create an installation drive (similar to what we used to do with InstallESD). To do so, specify the –volume to create the drive on (note that the target volume will be erased), the path of the “Install macOS High Sierra” app bundle and then we’re going to select –nointeraction so it just runs through the whole thing
/Applications/Install\ macOS\High\ Sierra.app/Contents/Resources/createinstallmedia --volume /Volumes/hsinstall --applicationpath /Applications/Install\ macOS\ High\ Sierra.app --nointeraction
Note: You’ll need to elevate your privileges for this to run.
Once run you’ll see that it erases the disk, copies the Installation materials (InstallESX, etc) and then makes the drive bootable, as follows:
Erasing Disk: 0%... 10%... 20%... 100%...
Copying installer files to disk...
Making disk bootable...
Copying boot files...
Then you can either select the new volume in the Startup Disk System Preference pane or boot the computer holding down the option key to select the new volume.
Note: If you can do this on a system with a solid state drive it will be faster. Although this took 17 minutes last I ran it even then so be patient for the files to copy.
krypted September 28th, 2017
Posted In: Mac OS X
create a bootable installer, high sierra, Installer, MAC, macos
The first thing you’ll want to do on any server is setup the networking for the computer. To do this, open the System Preferences and click on Network. You usually want to use a wired Ethernet connection on a server, but in this case we’ll be using Wi-Fi. Here, click on the Wi-Fi interface and then click on the Advanced… button.
At the setup screen for the interface, provide a good static IP address. Your network administrator can provide this fairly easily. Here, make sure you have an IP address and a subnet mask. Since we need to install the Server app from the Mac App Store, and that’s on the Internet, you’ll also need to include a gateway, which provides access to the Internet and using the DNS tab, the name servers for your Internet Service Provider (ISP).
Once you have provided a static IP address, verify that you can route to the Internet (e.g. open Safari and visit a website). Provided you can, the first step to installing macOS Server onto High Sierra is to download the Server app from the Mac App Store. To do so, open the App Store app and search for Server. In the available apps, you’ll see the Server app from Apple. Here, click on Buy and let the app download. That was pretty easy, right. Well, the fun has just gotten started. Next, open the app.
When you first open the Server app, you’ll see the Server screen. Here, you can click on the following options:
- Other Mac: Shows a list of Macs with the Server app that can be remotely configured. Choosing another system does not complete the setup process on the system you’re working on at the moment.
- Cancel: Stops the Server app setup assistant and closes the Server App.
- Continue: Continues installing the Server app on the computer you are using.
- Help: Brings up the macOS Server manual.
Click Continue to setup macOS Server on the machine you’re currently using. You’ll then be prompted for the licensing agreement from Apple. Here, check the box to “Use Apple services to determine this server’s Internet reachability” and click on Agree (assuming of course that you agree to Apple’s terms in the license agreement).
Installing macOS Server must be done with elevated privileges. At the prompt, enter the credentials for an account with administrative access and click on the Allow button.
The services are then configured as needed and the command line tools are made accessible. This can take some time, so be patient. When the app is finished with the automation portion of the configuration, you will be placed into the Server app for the first time. Your first order of business is to make sure that the host names are good on the computer. Here, first check the Host Name. If the name doesn’t resolve properly (forward and reverse) then you will likely have problems with the server at some point. Therefore, go ahead and click on Edit Host Name… Here, enter the fully qualified address that the server should have. In the DNS article, we’ll look at configuring a good DNS server, but for now, keep in mind that you’ll want your DNS record that points to the server to match what you enter here. And users will use this address to access your server, so use something that is easy to communicate verbally, when needed.
At the Change Host Name screen, click Next. At the “Accessing your Server” screen, click on Internet and then click on the Next button.
At the “Connecting to your Server” screen, provide the Computer Name and the Host Name. The Computer Name is what you will see when you connect to the server over Bonjour and what will be listed in the Sharing System Preference pane. The Host Name is the fully qualified host name (fqdn) of the computer. I usually like to take the computer name and put it in front of the domain name. For example, in the following screen, I have osxserver as the name of the computer and osxserver.krypted.com as the host name.
Once you have entered the names, click on the Finish button. You are then prompted to Change Host Name. Click on Change Host Name at this screen.
Next, let’s open Terminal and run changeip with the -checkhostname option, to verify that the IP and hostname match:
sudo changeip -checkhostname
Provided that the IP address and hostname match, you’ll see the following response.
sudirserv:success = “success”
If the IP address and hostname do not match, then you might want to consider enabling the DNS server and configuring a record for the server. But at this point, you’ve finished setting up the initial server and are ready to start configuring whatever options you will need on the server.
krypted September 28th, 2017
Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment
Apple, high sierra, install server app, MAC, macos, Servers
A nifty little feature of nvram is the ability to delete all of the firmware variables you’ve created. This can get helpful if you’ve got a bunch of things that you’ve done to a system and want to remove them all. If you run nvkram followed by a -p option you’ll see all of the configured firmware variables:
If you run it with a -d you’ll delete the given variables that you define (e.g. boot-args):
nvram -d boot-args
But, if you run the -c you’ll wipe them all:
krypted September 27th, 2017
Posted In: Mac OS X
Firmware, high sierra, Installer, MAC, macos, update nvram
macOS Server 5.4 (for High Sierra) comes with the /usr/sbin/serverinfo command (which was originally introduced in Mountain Lion Server). The serverinfo command is useful when programmatically obtaining information about the very basic state of an Apple Server.
The first option indicates whether the Server app has been downloaded from the app store, which is the –software option:
When used, this option reports the following if the Server.app can be found:
This system has server software installed.
Or if the software cannot be found, the following is indicated:
This system does NOT have server software installed.
The –productname option determines the name of the software app:
If you change the name of the app from Server then the server info command won’t work any longer, so the output should always be the following:
The –shortversion command returns the version of the Server app being used:
The output will not indicate a build number, but instead the version of the app on the computer the command is run on:
To see the build number (which should iterate with each update to the Server app from the Mac App Store, use the –buildversion option:
The output shows the build of server, which doesn’t necessarily match the macOS build number:
Just because the Server app has been downloaded doesn’t mean the Server setup assistant has been run. To see if it has, use the –configured option:
The output indicates whether the system is running as a server or just has the app installed (e.g. if you’re using it to connect to another server:
This system has server software configured.
You can also output all of the information into a single, easy to script against property list using the –plist option:
The output is a list of each of the other options used:
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
The Server Root can reside in a number of places. To see the path (useful when scripting commands that are relative to the ServerRoot:
By default, the output is as follows, which is basically like a dirname of the ServerRoot:
You can also see whether the system is running on actual hardware desgnated by Apple for servers using the –hardware option:
The output simply indicates if the hardware shipped with OS X Server on it from Apple:
This system is NOT running on server hardware.
The –perfmode option indicates whether or not the performance mode has been enabled, dedicating resources to binaries within the Server app:
If the performance mode has not been enabled then the output will be as such:
Server performance mode is NOT enabled.
Note: Performance mode doesn’t seem to be support any longer, as none of the options will actually enable the service.
krypted September 27th, 2017
Posted In: Mac OS X Server
high sierra, MAC, macos, macos server, programmatically interact with macOS server, serveradmin, serverinfo, set performance mode
A wiki is a repository of dynamically created and managed content, or content created or edited by multiple users collaboratively. This article is about using the wiki service in macOS Server 5.4 (the Apple Server app running on 10.13/High Sierra). I reference file services with WebDAV because it is a very nice integration piece that I think a lot of people will find pretty beneficial.
To get started with the Wiki service, first turn it on. This one isn’t heavily dependent on host names (other than being able to access the server from a browser) or directory services (other than being able to authenticate users, but local accounts are perfectly functional) and it doesn’t require the Websites service to be running as well. One should always have good working directory services and host names, still…
To enable the service, open the Server app and click on Wiki in the list of SERVICES in the List Pane.
There are two configuration options. The first is to select who is able to create wikis. Use the “Wikis can be created by” drop-down list to select “all users” if anyone with an account on the server should be able to create a wiki or “only some users” to bring up the Wiki Creators screen.
If only some users can create new wikis, use the plus sign (“+”) at the Wiki Creators screen to add users and/or groups to the list of users that can create wikis. Click on OK when all users and groups that can create wikis are added. In a school I would imagine that only teachers or IT staff would be able to create wikis. Once a wiki is created, pages inside the wiki can still be created by non-wiki creators.
The other option available is the handy dandy WebDAV interface to the wikis. When you enable this option, you can connect to a server from macOS or iOS via WebDAV and access files in each wikis document repository. To be clear, this option doesn’t provide access to the user documents, but does provide access to the wiki documents. We’re going to check the box for “Enable WebDAV access to Wiki files” and then click the ON button.
Once the service starts, click on the View Wiki link in the Wiki workspace in Server app.
Here, click on the Log in button and enter a user with access to the server, preferably one who can create wikis.
At the Wikis page, you will then see a list of all wikis you have access to. Note that the previous screen showed one wiki and now we see two. That’s because one of the wikis has permissions that allow “All unauthenticated users” access to the wiki, which we’ll describe shortly. The first thing most administrators will do is create a wiki. To do so, click on the plus sign (“+”) icon on the web page and at the resultant screen, click on New Wiki.
At the “Create a new wiki” prompt, provide a name for the wiki and a brief description for it.
Click on Continue.
At the Set permissions screen, enter each user or group to provide access to edit and view wiki pages. Here, you’ll have the options for Read & Write (users can view and edit pages in the wiki), Read only (users can only view the contents of your pages) and No access (users have no access to the wiki). There is a group for All logged in users, which includes every user with access to the server and another for All unauthorized users, which includes guests to the server. Once you’ve given the appropriate permissions, click on Continue.
Note: You don’t have to get this perfect now as you can always edit these later.
At the Set Appearance screen, you can choose an icon for the wiki (shown in the wiki list and when you open the wiki) as well as a color scheme for the wiki. Choose the appropriate appearance for your wiki (again, you can always change this later) and then click on the Create button.
Once the setup is finished, you’ll see the Setup complete modal. Here, you can click on Go to Wiki button.
Once you’ve created your first wiki, let’s edit it and customize the content. To do so, click on it from the list of available wikis. Click on the cog-wheel icon and then Wiki Settings… to bring up the Wiki Settings page.
Here, you’ll see the previously entered name and description as well as options to enable Calendar (only available if Calendar Server is running on the server) and Blog, which enables a blog service for the wiki (wiki administrators can post blog entries to the wiki). Click on Appearance.
Here, you will have the previous two options as well as the ability to upload a banner (which should be 62 pixels high) and background for each wiki.
Click on Permissions. Here, you’ll see the permissions previously configured as well as options to configure who can comment on articles (nobody disables comments completely) in the wiki and whether comments require approval (moderation).
Click on Save. Now, let’s edit the splash page. To do so, click the pencil icon in the top navigation bar.
At the edit screen, the top nav bar is replaced by a WYSIWIG editor for managing the page. Here you can justify, link, insert media and of course edit the text you see on the screen. I recommend spending some time embedding links, inserting tables, making text look like you want it to and editing the content to reflect the purpose of the wiki. Click Save when you’re done. Click the pencil again to edit it, and let’s create a new wiki page. Keep in mind that link wikipedia, each page should be linked to from other pages in the order they should be read. Unlike most wikis, there’s actually an index page of all the articles, which can come in handy.
From the edit page, to create a new page and link to it, enter some text (or lasso some) that you’ll use as the link to access the new page you’re creating. Then click on the arrow and select “New page.”
Note: Use Enter URL to link to an existing page or an external website, instead of creating a new page.
At the New Page screen, provide a name for the new page (the lasso’d text automatically appears as the Page Title) and click on the Add button.
Click Save and then click on the newly created link. You can now edit the new page the same way you edited the previous pages. Click on the disclosure triangles in the right sidebar to Comment on articles, link articles to related articles, tag articles and view editing history.
Now for the fun part. Click on Documents. Here, you’ll see the pages you already created. Click on the plus sign and select the option to Upload File to the wiki.
At the Upload File dialog, click on Choose File and then select a file to upload.
Click Upload when selected.
Then from the Finder of a macOS client, use the Go menu to select “Connect to Server”. Enter the name or IP of the server and then click on Connect.
Assuming you can access the server, you should then be prompted for a username and password. Enter it and click Connect. Eventually, the file(s) will display (it can take awhile according to your network speeds and how many files are in the directory). You can connect to this same screen through an iPad using a 3rd party WebDAV client or the build in options in Pages.
Managing wikis is as easy as its ever been, with the new options for appearance being a nice add-on. Active Directory integration is as easy as binding the server to Active Directory and using the accounts listed in Permissions of pages.
Now that iOS devices can edit wikis and many of the traditional word processing options are available in the wiki editor, consider what the Wiki can be. Could it replace text editing apps for iOS? Could the Wiki allow for more collaborative documents than a Word or other document editor? Could it keep from getting eaten like the rest of the homework? Could the comments in the Wiki be a good way for teachers to have students write responses to materials? Could the Wiki and the document management features allow your workers to access human resources documents and employee manuals? I know plenty of tech firms that use wikis to track information about the systems they manage.
Once you have all of this information, upgrading can seem downright scary. But fear not, there’s Carbon Copy Cloner. And once you’ve cloned, there’s wikiadmin. When doing an upgrade in place, the Wiki service is pretty straight forward to upgrade, but in many cases, due to aging hardware, wiki services are moving from an older computer to a newer computer. This can be done in one of two ways. The first is to “migrate” the data by copying the Collaboration folder onto the new system. The second is to “export” and “import” the data. I usually recommend doing a migrate where possible, so we’ll start with that method.
Note: Before getting started, make sure that the directory services side of things is good. If a user or group lookup for an object that owns, edits or has commented on a wiki fails then that wiki probably shouldn’t be migrated. Use the dscl or id commands to confirm that lookups are functioning as intended.
To migrate wikis from one server to another, first copy the Collaboration directory to the new server. In this example, the directory has been dropped onto the desktop of the currently logged in user. To migrate the data once copied, use the wikiadmin command, along with the migration option. The option requires the path to the Collaboration folder, defined with -r, as follows:
sudo /Applications/Server.app/Contents/ServerRoot/usr/bin/wikiadmin migrate -r ~/Desktop/Collaboration
When moving wikis, you can take the opportunity to get rid of a few you don’t want (such as that test wiki from way back when). Or administrators may just choose to move a single wiki to a new server in order to split the load across multiple hosts. When doing so, use the same command as earlier, along with the name of each wiki that is being moved, along with the -g option. For example, if moving the Legal wiki:
sudo /Applications/Server.app/Contents/ServerRoot/usr/bin/wikiadmin migrate -r ~/Desktop/Collaboration -g Legal
The second way of moving wikis around is to export and then import them. To do so, first export wikis on the old server, using the wikiadmin command along with the export option, which requires an –exportPath option and needs to be done, on a wiki-by-wiki basis. So to export that Legal wiki to a file called LegalWikiTMP on the desktop:
sudo /Applications/Server.app/Contents/ServerRoot/usr/bin/wikiadmin export -g Legal --exportPath ~/Desktop/LegalWikiTMP
Next, copy the wiki to the new server and import it, using the import option along with –importPath to identify where the file being imported is located. Using the same location, the command would then be:
sudo /Applications/Server.app/Contents/ServerRoot/usr/bin/wikiadmin import -g Legal --importPath ~/Desktop/LegalWikiTMP
Note: The ability to import a wiki also allows for an API of sorts, as you can programmatically create wikis from other sources. The ability to export also provides a way to move into another wiki tool if you happen to outgrow the options provided in Server and need to move to something more robust.
There is another way to move wikis, using pg_dump, copying the data and then using pg_restore to import the data once you’ve created the tables. This way is, in my opinion, the last resort if the standard wikiadmin commands aren’t working. In my experience, if I’m doing the migration this way then I’ve got other, bigger issues that I need to deal with as well.
These commands work best when the wiki service has been started so that the databases are fully built out. To start the wiki service from the command line, use the serveradmin command instead of the wikiadmin command. The serveradmin command is used with the start option and then wiki is used to indicate the wiki service, as follows:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin start wiki
The service can also be stopped, swapping out the start option with a stop option:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin stop wiki
In a few cases (this is the main reason I’m writing this article), the attachments to wikis don’t come over during a migration. To migrate the files that are used for QuickLook, downloading attachments, etc, use the serveradmin command to locate the directory that these objects are stored in:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin settings wiki:FileDataPath
The output identifies the directory where these objects are stored. Placing the contents in the same relative path as they are to the output of the same command on the target server usually results in restoring them. Once moved, use the fixPermissions option to repair the permissions of any files from the source (if any changes to account IDs are encountered such as an export/import rather than an archive/restore in OD this can lead to odd issues:
Also use the rebuildSearchIndex option with the wikiadmin command to fix any indexing, once the permissions have been repaired:
And finally use resetQuicklooks to clear any cached Quicklook representations of objects that have been inserted into a wiki and might not display properly using Quicklook (you know you might need to do this if they look fine when downloaded but look bad with Quicklook even though QuickLook on the server can view the files just fine):
When done properly the migration can take awhile. Keep in mind that every tag, every article, every edit to every article and basically everything else is tracked inside the tables that you’re moving. While there might not be a ton of data in the Collaboration directory or in an export, all of the data needs to go to the right location. This can take a little time in environments that have a lot of articles, even if they’re really short articles…
krypted September 26th, 2017
Posted In: Mac OS X, Mac OS X Server
Apple, Apple Devices, arp, MAC, Mac Servers, macos server, serveradmin, webdav, wiki, wikiadmin, wikis
Open Directory has never been this easy to setup for a basic environment as it is in macOS Server 5.4 (for macOS 10.13 running on High Sierra). As with almost any previous version of macOS Server and Open Directory, once you’ve installed the Server app, run the changeip command along with the -checkhostname option to verify that the IP, DNS and hostname match. If (and only if as it will fail if you try anyway) you get an indication of “Success.” I know, I know, you’ve been told that you didn’t have to do this kind of command line stuff any more… But really, you should – and if you don’t believe me, check out the contents of the attributes in the OD database… And besides, all you have to do is paste it in…
bash-3.2# sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/changeipchangeip -checkhostname
Which should respond as follows if all your DNS stuff is configured to match your host name:
dirserv:success = "success"
Initially, you no longer see Open Directory in the sidebar of the Server app. Simply click on the entry in View to see it. Then, to set up the Open Directory Master, click on the Open Directory service. From here, click on the ON button.
For the purposes of this example, we’re setting up an entirely new Open Directory environment. At the “Configure Network Users and Groups” screen, click on “Create a new Open Directory Domain” and click on the Next button.
Note: If you are restoring an archive of an existing Open Directory domain, you would select the bottom option from this list.
At the Directory Administrator screen, enter a username and password for the directory administrator account. The default account is sufficient, although it’s never a bad idea to use something a bit less generic.
Once you’ve entered the username and password, click on the Next button. Then we’re going to configure the SSL information.
At the Organization Information screen, enter a name for the organization in the Organization Name field and an Email Address to be used in the SSL certificate in the Admin Email Address field. Click on Next.
At the Confirm Settings screen, make sure these very few settings are OK with you and then click on the Set Up button to let slapconfig (the command that runs the OD setup in the background, kinda’ like a cooler dcpromo) do its thing. When the Open Directory master has been configured, there’s no need to reboot or anything, the indicator light for the Open Directory service should appear. If the promotion fails then look to the preflight options I wrote up awhile back.
Clicking on the minus (“-”) button while a server is highlighted runs a slapconfig -destroyldapserver on the server and destroys the Open Directory domain if it is the only server. All domain information is lost when this happens.
Next, let’s bind a client. Binding clients can be done in a few different ways. You can use a script, a Profile, the Users & Groups System Preference pane or build binding into the imaging process. For the purpose of this example, we’ll use the System Preference pane.
To get started, open up the System Preference pane and then click on Users & Groups. From here, click on Login Options and then unlock the lock in the lower left corner of the screen, providing a username and password when prompted.
Click on the Edit… button and then the plus sign (“+”).
Then, enter the name of the Open Directory Master (the field will expand with options when you enter the host name.
It’s probably best not to use the IP address at this point as the master will have an SSL certificate tied to the name. Click OK to accept the certificate (if it’s self-signed) and then the system should finish binding. Once bound, I like to use either id or dscl to verify that directory accounts are properly resolving before I try logging in as an Open Directory user.
Provided everything works that’s it.
Next, use dscl to browse users and verify that you can see items in Open Directory as well as your local database. The following will do so, using your hostname in place of mine, and with your password:
dscl -u diradmin -P <PASSWORD> /LDAPv3/macosserver.krypted.com -read /Users/diradmin
Once configured and tested, the devil is of course in the details. There is very little data worth having if it isn’t backed up. Notice that you can archive by clicking on the cog wheel icon in the Open Directory service pane, much like you could in Server Admin. Or, because this helps when it comes to automating backups (with a little expect), to run a backup from the command line, run the slapconfig command along with the -backupdb option followed by a path to a folder to back the data up to:
sudo slapconfig -backupdb /odbackups
The result will be a request for a password then a bunch of information about the backup:
bash-3.2# sudo slapconfig -backupdb /odbackups
2016-09-08 04:31:13 +0000 slapconfig -backupdb
Enter archive password:
2016-09-08 04:31:17 +0000 1 Backing up LDAP database
2016-09-08 04:31:17 +0000 popen: /usr/sbin/slapcat -l /tmp/slapconfig_backup_stage1769HtaFE7/backup.ldif, "r"
55ee6495 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
2016-09-08 04:31:17 +0000 popen: /usr/sbin/slapcat -b cn=authdata -l /tmp/slapconfig_backup_stage1769HtaFE7/authdata.ldif, "r"
55ee6495 bdb_monitor_db_open: monitoring disabled; configure monitor database to enable
2016-09-08 04:31:17 +0000 popen: /bin/cp /var/db/openldap/openldap-data/DB_CONFIG /tmp/slapconfig_backup_stage1769HtaFE7/DB_CONFIG, "r"
2016-09-08 04:31:17 +0000 popen: /bin/cp /var/db/openldap/authdata//DB_CONFIG /tmp/slapconfig_backup_stage1769HtaFE7/authdata_DB_CONFIG, "r"
2016-09-08 04:31:17 +0000 popen: /bin/cp -r /etc/openldap /tmp/slapconfig_backup_stage1769HtaFE7/, "r"
2016-09-08 04:31:17 +0000 popen: /bin/hostname > /tmp/slapconfig_backup_stage1769HtaFE7/hostname, "r"
2016-09-08 04:31:17 +0000 popen: /usr/sbin/sso_util info -pr /LDAPv3/127.0.0.1 > /tmp/slapconfig_backup_stage1769HtaFE7/local_odkrb5realm, "r"
2016-09-08 04:31:18 +0000 popen: /usr/bin/tar czpf /tmp/slapconfig_backup_stage1769HtaFE7/krb5backup.tar.gz /var/db/krb5kdc/kdc.conf /var/db/krb5kdc/acl_file.* /var/db/krb5kdc/m_key.* /etc/krb5.keytab , "r"
tar: Removing leading '/' from member names
2016-09-08 04:31:18 +0000 2 Backing up Kerberos database
2016-09-08 04:31:18 +0000 popen: /bin/cp /var/db/dslocal/nodes/Default/config/KerberosKDC.plist /tmp/slapconfig_backup_stage1769HtaFE7/KerberosKDC.plist, "r"
2016-09-08 04:31:18 +0000 popen: /bin/cp /Library/Preferences/com.apple.openldap.plist /tmp/slapconfig_backup_stage1769HtaFE7/, "r"
2016-09-08 04:31:18 +0000 3 Backing up configuration files
2016-09-08 04:31:18 +0000 popen: /usr/bin/sw_vers > /tmp/slapconfig_backup_stage1769HtaFE7/version.txt, "r"
2016-09-08 04:31:18 +0000 popen: /bin/cp -r /var/db/dslocal /tmp/slapconfig_backup_stage1769HtaFE7/, "r"
2016-09-08 04:31:18 +0000 Backed Up Keychain
2016-09-08 04:31:18 +0000 4 Backing up CA certificates
2016-09-08 04:31:18 +0000 5 Creating archive
2016-09-08 04:31:18 +0000 command: /usr/bin/hdiutil create -ov -plist -puppetstrings -layout UNIVERSAL CD -fs HFS+ -volname ldap_bk -srcfolder /tmp/slapconfig_backup_stage1769HtaFE7 -format SPARSE -encryption AES-256 -stdinpass /odbackups
2016-09-08 04:31:25 +0000 Removed directory at path /tmp/slapconfig_backup_stage1769HtaFE7.
2016-09-08 04:31:25 +0000 Removed file at path /var/run/slapconfig.lock.
To restore a database (such as from a previous version of the operating system where such an important option was actually present) use the following command (which just swaps backupdb with -restoredb)
sudo slapconfig -restoredb /odbackups
Both commands ask you for a password to encrypt and decrypt the disk image created by them.
krypted September 26th, 2017
Posted In: Mac OS X, Mac OS X Server
10.13, Apple, create an open directory master, high sierra, MAC, macos server
Yosemite brought Xsan 4, which included a whole new way to add clients to an Xsan. Xsan Admin is gone, as of El Capitan, but unchanged from then to macOS Sierra (other than a couple of binaries moving around). These days, instead of scanning the network using Xsan Admin. we’ll be adding clients using a Configuration Profile. This is actually a much more similar process to adding Xsan clients to a StorNext environment than it is to adding clients to Metadata Controllers running Xsan 3 and below. But instead of making a fsnameservers file, we’re plugging that information into a profile, which will do that work on the client on our behalf. To make the Xsan configuration profile, we’re going to use Profile Manager. With macOS Server 5, 5.2, and now 5.4 this trend continues.
To get started, open the Profile Manager web interface and click on a device or device group (note, these are scoped to systems so cannot be used with users and user groups). Then click on the Settings tab for the object you’re configuring Xsan for.
Click Edit for the profile listed (Settings for <objectname>) and scroll down until you see the entry for Xsan.
From the Xsan screen, click Configure.
This next screen should look a little similar, in terms of the information you’ve plugged into the Xsan 4 setup screen. Simply enter the name of the Xsan in the Xsan Name field, the IP address or host names of your metadata controllers in the File System Name Servers field and the Authentication Secret from the Xsan screen in the Server app into the Authentication Secret field. Click OK to close the dialog.
Click Save to save your changes. Then you’ll see the Download button become clickable. Choose the Mac option, and the profile will download to your ~/Downloads directory as Settings_for_<OBJECTNAME>.mobileconfig.
So this was called test and will result in a name of Settings_for_test.mobileconfig. That profile will automatically attempt to install. If this is an MDC where you’re just using Profile Manager to bake a quick profile, or if you don’t actually want to install the profile yet, click Cancel.
If you haven’t worked with profiles that much, note that when you click Show Profile, it will show you what is in the profile and what the profile can do.
Simply open this file on each client (once you test it of course) and once installed, they’ll automatically configure to join your Xsan. If you don’t have a Profile Manager server, you can customize this file for your environment (YMMV): Settings_for_test.mobileconfig
krypted September 26th, 2017
Posted In: Xsan
Apple, deploy settings, MAC, macos, macos server, Xsan
« Previous Page
The statshares option has an -m option to look at a mount path for showing the path to the mount (e.g. if the mount is called krypted this should be something like /Volumes/krypted):
smbutil statshares -m /Volumes/krypted
When run, you see a list of all the attributes OS X tracks for that mount path, including the name of the server, the user ID (octal), how SMB negotiated an authentication, what version of SMB is running (e.g. SMB_1), the type of share and whether signing, extended security, Unix and large files are supported.
Additionally, if you’d like to see the attributes for all shares, use the -a option after statshares:
smbutil statshares -a
You’ll then see the SHARE, ATTRIBUTE TYPE, and VALUE for each share mounted.
Overall, this is a nice health check type of verb to the smbutil command that can be added to any monitoring or troubleshooting workflow.
krypted September 26th, 2017
Posted In: Mac OS X, Mac OS X Server, Mac Security
Apple, DFS, MAC, macos, SMB, smbutil, statshares
— Next Page »