When running a DNS/BIND server on Linux or macOS, you can check the version number by running a simple named command with the -v option.
The output is as follows:
BIND 9.9.7-P3 (Extended Support Version)
krypted September 11th, 2016
You can find the version of the Server app that an OS X Server is running using the serveradmin command. To do so, run the serveradmin command followed by the -version option:
sudo /Applications/Server.app/Contents/ServerRoot/usr/sbin/serveradmin --version
The output would be as follows:
krypted April 21st, 2016
There are a number of ways to see information about what version of Linux that you’re running on different
Which returns the distribution information, parsed as follows:
DISTRIB_DESCRIPTION="Ubuntu Precise Pangolin (LTS)"
LSB_release can also be run as a command, as follows:
Which returns the following:
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu Precise Pangolin (LTS)
lab_release can be used as a command as well:
Ubuntu Precise Pangolin
In Debian, you can simply look at the version file:
Which returns the following:
Or Red Hat Enterprise can also be located with /etc/issue.net:
With many variants, including OS X, you can also use uname to determine kernel extensions, etc:
The thing I’ve learned about Linux is that there’s always a better way to do things. So feel free to comment on your better way or favorite variant!
krypted March 5th, 2015
OS X Yosemite running the Server 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 16th, 2014
Posted In: Mac OS X Server
In Mac OS X Lion, applications can make use of a feature to auto-save and version files. This feature locks files that are inactive for editing and when the file is unlocked then starts automatically saving versions. If you have a problem with the file you can then always step back to a previous version of the file. The feature is manifested in the title bar and the file menu of applications that make use of it. When you open a file, it can be locked. Viewing the file in the Finder also shows that it is locked. Clicking on locked provides the option to unlock. Once unlocked you can make changes as you normally would. The next time you save the file, a version is created. Hovering the mouse over the title of a file results in a disclosure triangle. clicking that results in some options otherwise located in the file menu.
Clicking on the Lock option again locks the file. Files inactive can automatically be locked as well. The Duplication option is similar to that of Save As. You are asked where you want to duplicate the file to. No versioning information is sent with the file. These same options are in the File menu as well.
The command-S will still save a file, and in fact now it does more and it saves a new version of the file (also done as part of the auto-save routine). The Revert to Saved options in the File menu and title bar menu will bring up an interface similar to that of Time Machine. You can navigate through here to find a version that you want to restore and restore your data.
Versioning information is persistent across a restore. In fact, once restored, you can revert back to a more recent save than that which was restored. In my testing so far, versioning information is not always persistent across restores of files (works with Time Machine, doesn’t work with 3 other applications I’ve tested). But YMMV there as patches are introduced in (hopefully) the next few weeks. Versions data is stored in /.DocumentRevisions-V100. In the /.DocumentRevisions-V100/db-V1 directory is a sqlite database with information and pages files are stored in containers by UID of local users in the /.DocumentRevisions-V100/PerUID directory. Permissions here are owner of root, group of wheel and d–x–x–x.
bash-3.2# cd /.DocumentRevisions-V100/
bash-3.2# ls -al
d--x--x--x 7 root wheel 238 Jul 18 22:39 .
drwxr-xr-x 36 root wheel 1292 Jul 28 23:24 ..
drwx------ 5 root wheel 170 Jul 28 23:27 .cs
drw------- 2 root wheel 68 Jul 18 22:39 ChunkTemp
d--x--x--x 3 root wheel 102 Jul 18 22:39 PerUID
drwx------ 4 root wheel 136 Jul 28 23:27 db-V1
drwx--x--x 2 root wheel 68 Jul 18 22:39 staging
Changing the permissions to 000 causes the feature to report no versions for the files but then you also cannot save changes to files. If you remove the .DocumentRevisions-V100 directory altogether it does not automatically recreate itself at the creation of a new document; however, it does not create itself initially until the first time you’re saving a document. Putting the directory structure back in place resolves any saving problems (is all this sounding a bit like how Spotlight indexes work to anyone???). Versioning is saved locally for files that are stored on network volumes. If you move a file that was versioned locally to a network volume and back then it will loose versioning information. If you open a file from a network share there is no versioning information in the file unless the local computer you are using had been used to make those versions. When you save a file stored on a network volume you are informed that the volume does not support permanent version storage. If you open the file and start editing it on another host and changes occur on both hosts (which the system will allow to happen) then at the next save you will get an alert that states that the file has been changed by another application. Clicking Save Anyway will overwrite changes from the other computer and Revert will revert to the last saved document or more likely error out with a complaint about permissions (even if those permissions are 777). Continuing to make changes on both hosts will eventually cause a “GSLibraryErrorDomain error 1” error code; however, the file will remain open so you can copy your changes off into another file. A few other points of information:
You can still mv a file to a .zip, unzip it and extract images and raw index data; however the versioning information is not actually saved there. Scanning the file system for changes during a version change only nets the file itself and the temp file (nested within /tmp) as having been altered. The Apple Developer Library explains Versioning as follows:
In the applications that ship as part of Mac OS X v10.7, users no longer need to save documents explicitly or be concerned about losing unsaved changes. Document-based Cocoa applications can opt into this autosaving behavior with a simple override. With automatic saving enabled, the system automatically writes document data to disk as necessary so that data displayed in a document window is, in effect, always the same as the document data on disk. A file coordination mechanism maintains sequential access to files. (See “Mac OS X File Coordination.”) Applications that support automatic saving also support document version history browsing. To browse previous versions of a document, choose Browse All Versions from the pull-down menu at the right end of the menu bar.
For more on NSDocumentController here’s Apple’s page for that.
Overall, Versions has taken me a little while to get used to. Especially in TextEdit. But I’ll take the latency in exchange for the ability to roll back changes. If you are rolling out Lion in a larger environment, you’re going to want to check out whether or not users expect this to persist across network shares, copying files to additional computers or even backups in many cases.
krypted July 28th, 2011
Posted In: Mac OS X
There are a lot of versions of the popular perl scripting language out there, and depending on what version you may have written a script with you might find that using a different version than the one that comes with an OS by default can have a drastic impact on a script. In Mac OS X you can change the default version of perl that the perl and a2p command will use. Before doing so you should check the version of perl being used by default, which can be done using the perl command, followed by the -v option:
By default, the OS currently uses version 5.10.0. To change the version, you would use the defaults command to change the com.apple.versioner.perl defaults domain. You will add a key called Version with a string of the version you would like to use. For example, to switch to 5.8.8:
defaults write com.apple.versioner.perl Version -string 5.8.8
To change it back to 5.10.0:
defaults write com.apple.versioner.perl Version -string 5.10.0
You can also set perl to run in 32 bit mode:
defaults write com.apple.versioner.perl Prefer-32-Bit -boolean TRUE
To put it back:
defaults write com.apple.versioner.perl Prefer-32-Bit -boolean FALSE
Python provides the same functionality:
defaults write com.apple.versioner.python Version -string 2.6
Or to run Python in 32-bit mode:
defaults write com.apple.versioner.python Prefer-32-Bit -boolean TRUE
krypted June 8th, 2010
Posted In: Mac OS X
Ever need to have a program check a file to tell you what version of Mac OS X you’re running to do a quick sanity check? In /System/Library/CoreServices/SystemVersion.plist you’ll find a key for ProductVersion. The value in this key is the version of Mac OS X you’re using. Keep in mind that the path should be relative to the volume that houses the operating system. Therefore, if you’re using a volume during imaging and you’re running a postflight or preflight script make sure you check the path relative to the operating system you’re augmenting.
krypted January 15th, 2007