The directory services options in macOS has quietly been going through some slow changes over the past couple of years. Many of the tools we use to manage accounts look similar on the outside but sometimes work a little differently under the hood. Account information is still stored in the /var/db/dslocal/nodes directory. Here, the local directory service pulls files from within directories recursively when accountsd loads. You can still create a second instance of the local directory service by copying the Default directory. For example, here we’ll copy the Default directory node to a directory node called NEW:
sudo cp -prnv /var/db/dslocal/nodes/Default /var/db/dslocal/nodes/NEW
If you killall accountsd then wait (this is slower than doing a killall of DirectoryService was), you’ll then see and be able to use this new directory node:
<code>sudo killall accountsd</code>
This is one way to go about forklifting large collections of accounts from one system to another. The dsmemberutil account can still be used to obtain certain information from accounts. For example, you can check group membership by feeding in a uid with the -u option (here using the uid of 509) and a gid with the -g (here a gid of 10) option:
<code>dsmemberutil checkmembership -u 509 -g 10</code>
Each account still has a uuid. This can be obtained with -u for a user or -g for a group (ids):
<code>dsmemberutil getuuid -u 509</code>
And, you can use dsmemberutil to flush the directory services cache resolver, using the flushcache verb:
The files that comprise accounts can also be viewed and changed manually. Here, we’re going to just look at an account called charles:
<code>sudo defaults read /var/db/dslocal/nodes/Default/users/charles.plist</code>
If we used a tool like defaults, plistbuddy or plutil to manually augment one of these accounts, we’d also need to kill accountsd as we did earlier.
krypted October 3rd, 2016
OS X Mavericks Server (Server 3) comes with the /usr/sbin/serverinfo command (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 OS X 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:
IsOSXServerVolume IsOSXServerVolumeConfigured IsServerHardware
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.
To enable performance mode, you can also use serverinfo. This is the only task that the command does that can make any changes to the system and as such is the only time you need to elevate privileges:
sudo serverinfo —setperfmode 1
Or set the boolean value back to 0 to disable.
sudo serverinfo —setperfmode 0
krypted October 22nd, 2013
Posted In: Mac OS X Server
Tags: base name, build version, configured, dirname, get build number, hardware, Mac Server, Mac Servers, mavericks, Mavericks Server, OS X Server, os x server 3, performance mode, plist, prefix, property list, server 2.2, server 3, serverinfo, serverroot, short version, xml
You can obtain a pretty decent amount of information about leases your OS X computer gets just by looking in the Network System Preference pane, for each interface.
However, you can get a little lot more information, as with most things, from the command line. First, we’re going to take a look at en0 on our host and see what the MAC address is:
ifconfig en0 ether
Now, we can look in the /var/db/dhcpclient/leases directory to see a list of all of the leases we have running on our system. Based on the MAC address of our computer, we should see a file there that starts with the name of our interface and finishes with our MAC address. Let’s cat this file:
The output is similar to the following (a standard plist):
<?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”>
This shows us the amount of time our lease is valid for, when the lease what provided to us, what IP was provided and the IP of our router. We can then key off of that information as needed (e.g. for other scripts/tools).
krypted October 7th, 2013
You can remotely start ARD with kickstart, which I have previously covered at length. But Screen Sharing is a bit of a different little beast. To start up Screen Sharing, you can just use the following command:
echo -n enabled > /Library/Preferences/com.apple.ScreenSharing.launchd
I still prefer kickstart, but this method functions when you need something quick and easy. To then disable Screen Sharing, you can just toss the launchd item:
Once you have Screen Sharing started, you can then open the Screen Sharing application from a client by using the open command, followed by the protocol, which would be vnc and then the IP address. As with FTP you can also inject the user name and password into the open, following the //, by placing the user name followed by a colon (:) followed by the password and then the @ symbol (all before the IP address). For example, to connect to a computer with an IP address of 192.168.200.2 using the username of krypted and the password of mypass you would use the following command.
You may encounter an encryption error, which if you are attempting to script can be annoying to click on. To suppress it, use defaults to set the dontWarnOnVNCEncryption key of the com.apple.ScreenSharing.plist to True:
defaults write com.apple.ScreenSharing dontWarnOnVNCEncryption -bool TRUE
krypted January 26th, 2010
PlistCheck is a very small, very fast application that checks preferences (aka – property lists) to make sure that they are properly formatted. There are a few other tools out there that do this and it’s easier to just use the command line, but if you are not command line savvy (or working with someone who isn’t) then you can use this tool to check property lists (preferences) rather than using the command line to do so.
PlistCheck will be made available on the Apps page as well.
krypted January 21st, 2010
krypted December 2nd, 2009
Posted In: Mac OS X