Posted: February 5, 2012 | Author: Kyle Crawford | Filed under: Deployment, dockutil, Mac OS X, Mac OS X Server, Python, Scripting |
Version 1.1 of dockutil is out:
- fixes many issues with paths (should now work with Default User Template and other paths with spaces)
- adds option to not restart the dock (–no-restart)
- fixes issue where item would be added multiple times (use –replacing to update an existing item)
- resolves deprecation warnings
- adds option to remove all items (–remove all)
- fixes issue with removals when a url exists in a dock
- adds option –version to output version
Posted: November 29, 2011 | Author: Kyle Crawford | Filed under: http, Mac OS X, Mac OS X Server, Unix | Tags: apache, key, Pass phrase incorrect, Snow Leopard, ssl |
If you are getting errors “Pass phrase incorrect” in your apache logs on Snow Leopard server, it is because the key is protected by a password. I found the answer here.
The password for the key is stored in the System Keychain. It is a password entry called “Mac OS X Server certificate management”. You can open the entry and select “Show Password”. You may also use the security command line tool to dump the password.
security find-generic-password -l "Mac OS X Server certificate management" -g
or
security dump-keychain -d # look in data for password which will look like a GUID
Once you have the password, you can create a copy of the key without the password using openssl:
openssl rsa -in /etc/certificates/server.domain.com.uniqueid.key.pem \
-out /etc/certificates/server.domain.com.uniqueid.passwordlesskey.pem
You can then replace the password protected key with the passwordless key or point apache to the passwordless key in your /etc/apache2/sites/sitename.conf file.
Posted: February 4, 2011 | Author: Kyle Crawford | Filed under: Deployment, Hardware, Mac OS X, Mac OS X Server, Scripting, Unix | Tags: Apple Remote Desktop, ARD, Asset Collection, Facter, hardware, parse, plist, Puppet, report, sysinfocachegen, System Profiler, system_profiler |
It is pretty cool how Apple System Profiler has a command line equivalent (system_profiler). And it is pretty cool how system_profiler has a -xml option to allow for easier parsing. You might use this info for extracting asset information into a database or for puppet facter facts.
However if you’ve ever looked at that xml, you know that it is a tree full of unpredictable semi-structured data that was designed specifically for the GUI app. So even though you can parse it with your favorite plist parser, there is still a lot more work to do to get to the data you care about.
The tree structure is nice for a browsing through on a single machine, but not so good for reporting across many machines.
Apple stores most of the same data as key value pairs in its database for ARD reporting, but they do a lot of massaging of the data to get it that way.
It is possible to get at this data in an ARD database if you have an ARD collection server, but an ARD collection server isn’t for everyone and doesn’t serve every use case.
You can still get at the nicely formatted ARD information. ARD client includes a tool that outputs most, if not all of the asset information you care about in a much nicer structured format for reporting.
The tool is called sysinfocachegen and you use it like this:
sudo /System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Support/sysinfocachegen -p /tmp/com.yourorganization.systeminfo.plist
Just use your favorite language’s plist parser to read the plist.
Posted: April 14, 2010 | Author: Kyle Crawford | Filed under: Mac OS X, Mac OS X Server, Scripting, Unix | Tags: listen, lsof, Mac OS X, Mac OS X Server, netstat, ports, processes |
lsof -i | grep LISTEN | grep "TCP \*:" | sort
Or to find out what processes have open connections use
lsof -i | grep ESTABLISHED | sort
Nothing ground breaking, but useful. netstat gives you similar info, but doesn’t include the process.
Posted: December 8, 2008 | Author: Kyle Crawford | Filed under: Active Directory, Mac OS X, Mac OS X Server | Tags: Active Directory, AD, debug, debug level, defaults, DirectoryService, Mac OS X, USR1 |
Apple’s document on Extending and Troubleshooting Directory Services has a lot of good info.
One correction though is that the debug level must be an integer.
sudo defaults write /Library/Preferences/DirectoryService/DirectoryServiceDebug "Debug Logging Priority Level" -integer 2
I’ve notified Apple, so this may be fixed by the time you read this.
Update: That link is dead. Here is an article that offers some similar information.
Posted: July 15, 2008 | Author: Kyle Crawford | Filed under: Mac OS X, Mac OS X Server, Scripting, Unix | Tags: AFP, dscl, forensics, grep, gunzip, log, Mac OS X Server |
Mac OS X Server’s AFP server access logs aren’t the greatest (no full paths is a glaring omission), but if you have them enabled, they can be useful for finding who deleted a file or folder for example.
If the item’s name starts with “Important File”, this command gives us the ip address of the client that deleted the item :
file_server:~ root# grep -i "Delete Important File*" /Library/Logs/AppleFileService/AppleFileServiceAccess.log
IP 10.1.21.6 - - [08/Jul/2008:14:26:14 -0500] "Delete Important File 2009.xls" 0 0 0
Then we pass the ip address into this command to give us the login of the user:
file_server:~ root# grep 10.1.21.6 /Library/Logs/AppleFileService/AppleFileServiceAccess.log | grep Login
IP 10.1.21.6 - - [08/Jul/2008:09:05:43 -0500] "Login mpickens" 0 0 0
Finally we can use dscl to lookup the full name the user:
file_server:~ root# dscl localhost read /Search/Users/mpickens RealName
RealName: Pickens, Mary Ellen
Older logs are available too in zipped form. Use gunzip -c to read the contents.
file_server:~ root# gunzip -c '/Library/Logs/AppleFileService/AppleFileServiceAccess.log 12.11.07.gz' | grep Login | grep mpickens
IP 10.1.21.143 - - [14/Dec/2007:19:12:38 -0500] "Login mpickens" 0 0 0
IP 10.1.21.143 - - [14/Dec/2007:19:24:32 -0500] "Login mpickens" 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:09:21:38 -0500] "Login mpickens" 0 0 0
IP 10.1.21.143 - - [17/Dec/2007:10:37:49 -0500] "Login mpickens" 0 0 0
...
Posted: March 15, 2008 | Author: Kyle Crawford | Filed under: Mac OS X, Mac OS X Server | Tags: bless, diskutil, hfs.util, UUID, verbose |
If you run into waiting for root device when booting in verbose mode or you get a flashing question mark, etc, it could be that your volumes have duplicate UUIDs. The UUID is the primary means that is used to locate the boot volume to root from. If you have duplicate UUIDs, your Mac may not be able to determine which volume to boot from. If you suspect this may be the case, boot from another disk or CD and run diskutil list to get a list of all volumes. Then run diskutil info on each to get the UUIDs. Check for duplicates.
kserver:~ pbuffer$ diskutil list
/dev/disk0
#: TYPE NAME SIZE IDENTIFIER
0: GUID_partition_scheme *74.5 Gi disk0
1: EFI 200.0 Mi disk0s1
2: Apple_HFS int_1 19.8 Gi disk0s2
3: Apple_HFS int_2 19.8 Gi disk0s3
4: Apple_HFS int_3 34.5 Gi disk0s4
kserver:~ pbuffer $ diskutil info disk0s2 | grep UUID
Volume UUID: A1F5866F-8286-359A-B19F-58910918AC5A
kserver:~ pbuffer$ diskutil info disk0s3 | grep UUID
Volume UUID: A1F5866F-8286-359A-B19F-58910918AC5A
kserver:~ pbuffer $ diskutil info disk0s4 | grep UUID
Volume UUID: CBB0B1F8-07D5-3BFC-9B50-4F99033B01D6
If you do find a duplicate, you can generate a new UUID and set it using the following command:
unmount the disk first
diskutil unmountDisk disk0
/System/Library/Filesystems/hfs.fs/hfs.util -s disk0s2
substitute your own device for disk0s2
Once you’ve done this, re-bless the volume.
Duplicate UUIDs shouldn’t happen, but somehow it happened to one of our Xserves with a hardware raid card.
Posted: February 17, 2008 | Author: Kyle Crawford | Filed under: Active Directory, Deployment, Mac OS X, Mac OS X Server | Tags: 10.5, Active Directory, AD plugin, bugs, Directory Utility, domain, dseditgroup, hosts, Leopard, nest groups, workarounds |
The Active Directory plugin is finally usable in 10.5.2, but some environments require workarounds.
1.) Your domain must resolve to the ip address of a domain controller. This was not a requirement in previous versions, but Apple is apparently making it a requirement as they closed my bug stating that it was a configuration issue with Active Directory since creation of a domain sets up this dns info by default. If your domain does not resolve to an ip, you need to fix it, or as a workaround, edit your /etc/hosts file to point the ip of one of your domain controllers.
for example if you know you have a domain controller at 10.3.1.23 and your fully qualified domain is domain.forest.com, you’d add this line to /etc/hosts
10.3.1.23 domain.forest.com
2.) Allow Authentication from any domain in forest does not work. Uncheck this box in Directory Utility or using the corresponding flag in dsconfigad. If you don’t do this, the join may succeed, but you won’t be able to lookup or authenticate users or even use dscl on Active Directory. When you uncheck this option, just be sure to add the correct domains to your authentication search path in Search Policy of Directory Utiltity.
3.) Allow Administration by Active Directory Groups does not seem to work. In 10.4, this option seems to nest the AD group you want to allow for administration into the local admin group, so the workaround is to do the same in 10.5 manually using dseditgroup.
sudo dseditgroup -o edit -a “DOMAIN\group name” -t group admin
replacing DOMAIN\group name with your domain and group that you want to give admin access.
This group nesting method gives members of your AD group admin access for both Apple’s Authorization APIs and sudo.
These workarounds got me working, logins are painfully slow, but that may be due to the hosts hack.
Update: Under 10.5.3, most of these problems are resolved. If you are still having slow logins/joins, there are possible workarounds.
Posted: January 4, 2008 | Author: Kyle Crawford | Filed under: Mac OS X, Mac OS X Server, rsync, Scripting, Unix | Tags: ACLs, backup bouncer, checksum, chflags, extended attributes, man page, metadata, resource forks, rsync, rsyncx, uchg, xattr |
A little while back, I mentioned the sad state of rsync in Mac OS X. Well I’ve had a chance to test rsync 3.0 prerelease 7 and I am very pleased with the results.
To test for yourself, download the source, extract the source, cd into the extracted directory, run ./configure, run make, and then make install. You’ll find the new rsync installed at /usr/local/bin/rsync. View the man page using man -M /usr/local/share/man rsync.
Use -X for extended attributes ( and resource forks )
Use -A for ACLs
Don’t use -E, which was Apple’s flag for these as it is used for executability
Here are my test results:
Resource Fork Handling: For testing resource forks, I used to keep a copy of SimpleText around as it is all resource fork and no data fork, but a text clipping, which is also all resource fork is a great test. rsync 3 syncs the resource fork exactly the way you’d like. It retains the fork during the initial copy, and only re-copies the file if the fork has changed. This is quite awesome since Apple’s bundled rsync always copies the fork causing major speed hits even when no files have changed. I haven’t looked at the source code to see how rsync determines if the resource fork changed, but it seems efficient so far, though they may be doing checksums because using the -X flag adds time to the compare phase.
I dragged a text clipping into my source folder. I verified its resource fork using cat somefile/rsrc. I ran rsync and verified the destination’s resource fork. I re-ran rsync and no files were copied. I appended some data to the fork and rsynced again. rsync detected the file as changed and re-copied it with the changed resource fork. You can test it yourself. Using the –stats or -v option, try running Apple’s rsync, then rsync 3 and you’ll see the number of files transferred.
Metadata tests: I recently found backup bouncer, which runs a multitude of tests on metadata preservation.
------------------ rsync-3.0pre7 ------------------
This copier exited with error code 23
This copier produced log output in:
/Volumes/Dst/11-rsync-3.0pre7/log
Verifying: basic-permissions ... ok
Verifying: timestamps ...
Sub-test: modification time ... ok
ok
Verifying: symlinks ... ok
Verifying: symlink-ownership ... ok
Verifying: hardlinks ... ok
Verifying: resource-forks ... ok
Verifying: finder-flags ... ok
Verifying: finder-locks ... FAIL
Verifying: creation-date ... FAIL
Verifying: bsd-flags ... ok
Verifying: extended-attrs ...
Sub-test: on files ... ok
Sub-test: on directories ... ok
Sub-test: on symlinks ... ok
ok
Verifying: access-control-lists ...
Sub-test: on files ... ok
Sub-test: on dirs ... ok
ok
Verifying: fifo ... FAIL
Verifying: devices ... FAIL
Verifying: combo-tests ...
Sub-test: xattrs + rsrc forks ... ok
Sub-test: lots of metadata ... ok
ok
Overall it fares pretty well.
The lack of support for finder-locks (aka flags like uchg) is unfortunate. Files on the destination are simply unlocked. This solves the problem of rsync not being able to delete locked (uchg) files, but it is kind of worse because that metadata is just plain lost and a lot of old time Mac users are accustomed to using that feature since it is right there in the GUI Finder Get Info panel.
I suppose a workaround would be to find all the files that have the flag and create a transcript of them before running rsync for later re-locking.
I need to do some performance testing compared to rsyncx, but so far, rsync 3 looks good to me.
Posted: December 13, 2007 | Author: Kyle Crawford | Filed under: Active Directory, Mac OS X, Mac OS X Server | Tags: Active Directory Sites, AD plugin, dig, Domain Controllers, forest, Kerberos, LDAP, ldapsearch, syntax |
The AD Plugin uses information in Sites in your Active Directory Configuration to get a list of Domain Controllers to use for LDAP and Kerberos connections. Sites are a method of configuring Active Directory based on a physical or network based location. Clients connecting to Active Directory use this information to determine which domain controllers are nearby and therefore likely to respond the fastest. Plus if you have Domain Controllers in remote or distant locations, without using Sites, you are pushing traffic over a WAN unnecessarily.
This is one of the steps you’ll see when joining a machine to AD. Locating Domain Controllers… or something like that.
First it uses DNS to lookup SVR records to locate ANY domain controller. You can do the same using the dig command:
dig any _kerberos._tcp.yourdomain.yourforest.com
This will give you a list of domain controllers to choose from. Once you have one of your domain controllers to talk to, you can read the same information that the AD Plugin does to figure out your Site by querying AD with ldapsearch and your subnet:
ldapsearch -x -h "somedomaincontroller.yourforest.com" -b "CN=Subnets,CN=Sites,CN=Configuration,dc=yourforest,dc=com" -D "username@yourdomain.yourforest.com" -W "(cn=10.31.0.0/16)" siteObject
From this you will get your Site, which you can then use with ldapsearch again to get a list of domain controllers for your site:
ldapsearch -x -h "somedomaincontroller.yourforest.com" -b "CN=SERVERS,CN=YOURSITENAME,CN=Sites,CN=Configuration,dc=yourforest,dc=com" -D "username@yourdomain.yourforest.com" -W dNSHostName | grep dNSHostName
Pretty cool. Takes some more of the mystery out of the AD plugin.
Notes: Enter each command as a single line. Substitute ‘yourdomain’ with your own domain and ‘yourforest’ with your own forest and ‘username’ with a your username for your domain and ’10.31.0.0/16′ with your own subnet and ‘YOURSITENAME’ with the site name you found in the previous step. Also, using ldapsearch in this way does a simple BIND authentication which sends your password in CLEAR TEXT. Change your password after using this command if you are in a secure environment.
Update: I was using this method recently and realized I was getting domain controllers that were in my site, but weren’t hosting my specific domain. If you want to get just the servers hosting your domain, you need to filter the ldapsearch like so, but you won’t get the fully qualified dNSHostName:
ldapsearch -x -h "somedomaincontroller.yourforest.com" -b "CN=SERVERS,CN=YOURSITENAME,CN=Sites,CN=Configuration,dc=yourforest,dc=com" -D "username@yourdomain.yourforest.com" -W msDS-HasDomainNCs="DC=subdomain,DC=forest,DC=com" dn | grep dn:
