krypted.com

Tiny Deathstars of Foulness

In case you’re using DEP and haven’t noticed this, you need to accept the latest terms of service in the Apple license agreement for DEP if you’re going to continue using the service. I don’t usually post emails I get from Apple, but I can easily see orgs using accounts that don’t have email flowing to anyone that is capable of responding, so I strongly recommend you go in and accept the latest and greatest agreements so your stuff doesn’t break!

Here’s the email I got from Apple:

Apple Deployment Programs

Thank you for participating in the Device Enrollment Program. On September 13 Apple will release updated software license agreements. Your Program Agent must go to the deployment website and accept the following agreements to continue to use the program:

  • iOS 10 Software License Agreement
  • Software License Agreement for macOS Sierra

For more information please see this support article:https://support.apple.com/kb/HT203063.

Note: If you’re using Casper, then the errors you’ll see will be something along the lines of:

Unable to Contact https://mdmenrollment.apple.com

September 12th, 2016

Posted In: iPhone, JAMF, Mac OS X, Mac OS X Server, Mac Security, MacAdmins Podcast

Tags: , , , , ,

May 6th, 2016

Posted In: Mac OS X, Mac OS X Server

Tags: , , , , , , ,

Spotlight just kinda’ works. Except when it doesn’t. Which is luckily pretty rare, for the use cases that Spotlight was designed for. But when it doesn’t work, you have a few tools that I’ve highlighted over the years to help you out, including articles on shared volumes, manually indexing, disabling Spotlight, and a few others. But what if you need to go in more depth to isolate an issue? For this, Apple has provided us with a tool called mddiagnose, in /usr/bin. In the following command, we’ll run an mddiagnose to dump a bunch of system statistics that we can then look at. Here, we’ll do that to a folder called test in our current working directory:

/usr/bin/mddiagnose -f test

The output is then test.mdsdiagnostic, a directory with a CrashReporter, spindump, Samples, DiagnosticReports, a few system.log exports, and a diagnostic.log.

You can then view your log using the more command (or cat or less or whatevers)

more ~/test.mddiagnostic/diagnostic.log

Here, you’ll see the output of a bunch of scripts that were run. I find that this is the most informational aspect of what I get from the mddiagnose output. Every time I’ve actually fixed an issue here, it’s been with this output.

The other aspect of mddiagnose that I’ve found useful is checking permissions and paths. Here, you can answer the simple question of whether mdutil has permissions to check a path. We’ll do so using the -p option:

mddiagnose -p /Library/Application\ Support/Appifitizer

Enjoy!

Screen Shot 2015-12-09 at 11.11.01 AM

December 15th, 2015

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , , ,

Apple has released the client and server updates for Apple Remote Desktop. Both are now available on the App Store. For official information of the server update, see http://support.apple.com/kb/HT5896?viewlocale=en_US.

New features include:

  • Support for OS X Mavericks
  • A shared clipboard which allows automatic copy and paste between local and remote computers
  • Improved support for Mac systems with multiple displays or multiple IP addresses
  • Enhanced multi-observe with gesture support for swiping between screens
  • Output of remote UNIX commands is no longer truncated

The client update documentation is at http://support.apple.com/kb/HT5896?viewlocale=en_US&locale=en_US.

October 24th, 2013

Posted In: Mac OS X, Mac OS X Server, Mac Security, Mass Deployment

Tags: , , , , , ,

In Lion Server, Open Directory can be managed in one of three ways: using the Server application the Server Admin application or using the command line utilities. Configuring Open Directory has never been easier than it is in the Server application, though. As we looked at in a previous article, setting up an Open Directory master should be done using the Server application. But setting up an Open Directory replica should be done using the Server Admin application. The Server Admin application is not installed when you buy OS X Server on the App Store and so it can be obtained here.

But first (or while that’s downloading even), open the Server application. If this is the first time that you’ve opened the Server application then you’re in for a bit of a wait. This is a nice time to grab yourself the first shot of Jäger of the day. According to your internet speed, you could end up with 3 or 4 of these. That’s fine though, the new Open Directory makes much more sense afterwards.

When you first open and start using the Server application, you’re creating local users. The Server application automatically creates local users until you setup Open Directory. Before you set up Open Directory as a Replica on the system, it should have a static IP address and a name in the DNS servers that the server uses (forward and reverse lookups for said address). The Server application has a Next Steps drawer. Clicking on the drawer and then the Configure Network button brings up a screen that will complain if your DNS has any problems. If DNS is working great, then the Configure Network section of the Next Steps drawer will appear as follows:

Not to get off topic on the hostname/dns/etc thing, but when you click on Network, if you decide to change names before you promote to an Open Directory Master/Replica, clicking on Edit for the Host Name, you should almost always click on the third option, Host Name for Internet…

While the Server app is cool, it caches stuff and I’ve seen it let things go threat shouldn’t be let go. Therefore, in order to make sure that the server has such an address, I still recommend using changeip, but I also recommend using the Server application. In Lion, I’ve seen each find things that other misses. To use changeip:

sudo changeip -checkhostname

The address and host names should look correct and match what you see in the Server application’s Next Steps drawer.

Primary address = 10.0.0.1

Current HostName = mdm.krypted.com
DNS HostName = mdm.krypted.com

The names match. There is nothing to change.
dirserv:success = “success”

Provided everything is cool with the hostname, open the Server Admin application from /Applications/Server. Then click on Settings in the application’s toolbar. At the Settings screen, click on Services. Click on the checkbox for the Open Directory Service and click Save to see the Open Directory service appear in the Server Admin sidebar. Then, click on Open Directory in the Server Admin sidebar and then click on the Change… button to bring up the Open Directory Assistant.

At the Choose Directory Role screen, click on Set up an Open Directory replica and then click on the Continue button.

At the Replica and Certificate Authority screen, provide the name or IP address of the Open Directory master in the IP address or DNS name of master field. Actually, just use the name. If you can’t find the Open Directory Master by name, then you should really fix that before moving forward. Also provide the Open Directory administrative user name in the Domain administrator’s short name field and that account’s password in the Domain administrator’s password field. If you have any problems, make sure you can ssh into the Open Directory master using this account.

Also, new in Lion, there’s a CA administrator’s email address field. Put in here, what you put into the Organization Information field back when you promoted the master (screen shown for posterity).

If you’ve lost track of the email address you used, keep in mind that the SSL certificate can be used to grab that information. Open Keychain Access, click on Certificates, search for the host name of the Master (this is all from the master, btw) and then do a Get Info and you’ll see the Email Address used.

Anyway, back to the Open Directory Assistant on the new Replica. Click on the Continue button and finish the wizard to complete promoting the replica. That’s it. Don’t forget to check your logs when the promotion is complete.

I’ve been finding that there are a lot of issues with promoting Replicas in Lion so far. This has meant bad directory data (import + export), bad DNS, security policies, using a bad username and password combination (not the systems fault) and other issues. To fix the bad directory data, you have to import and export (in my experience not an archive and restore but an actual export and import, losing all passwords in the process). The Next Steps drawer can guide you through the host names/DNS issues. For security policies, I’ve found the following command to work for me (run on the master):

slapconfig -setmacosxodpolicy -binding enabled

For the username and password issues (the errors don’t always tell you what is or is not a password problem) I have found using dscl or even Workgroup Manager to test the login is an important step.

You can also still use slapconfig for Open Directory replicas, a great way to get a lot of detailed information. For example, one time, the replica promotion was failing because the server was a member server in a domain; however, using slapconfig -getstyle the server simply reported as Standalone. To promote a replica, you will define want to make sure to include the new –certAdminEmail option, followed by the email address on that certificate of the master. This is then followed with the address and the admin username of the master. For example:

slapconfig -createreplica --certAdminEmail krypted@me.com odm.pretendco.com diradmin

When slapconfig runs, it will give you a detailed account of where it failed and why.

Finally, I have noticed that some machines fail in the Server Admin GUI and Server Admin simply doesn’t show that the machine failed, but instead just makes the system a member to the server. When this happens, I have always had to clean install the system in order to get it to promote to a replica again, properly. To make sure a replica is indeed a replica, consult slapconfig:

slapconfig -getstyle

Now is when you get to have a little more Jäger. This whole process hopefully only took about 5 to 10 minutes, so it’s about time anyways. If the process took longer, then I hope you didn’t wait until now for round 2. Later, we’ll discuss directory trees and using those as a means of building sites. For that, you might want to move onto something a bit stronger, like mescaline.

March 1st, 2012

Posted In: Mac OS X, Mac OS X Server, Mac Security

Tags: , , , , , ,

When you are using Podcast Producer, whether you are looking in your log files on a server in Server Admin or whether you are looking in Console on a client, if there are any problems submitting jobs you should find a numeric reference code. The meaning can be cryptic, although I’ll try a little bit here:

-500 = Camera agent went offline

-501 = Podcast Producer agent timed out

-502 = Agent failed to communicate

-600 = Tunnel protocol mismatch

-601 = Tunnel could not connect

-602 = Tunnel timed out

-603 = Tunnel failed

1 = Internal camera agent is failing

3 = Capture failed to run

4 = Capture already running

5 = Capture is not paused

6 = The locking mechanism encountered a mutex failure

7 = The unlocking mechanism encountered a mutex failure

8 = Camera agent cannot communicate with the file system

9 = Podcast Capture has no capture device available

10 = SG initialization failure

11 = Audio channel initialization failure

12 = Video channel initialization failure

13 = Video creation failed

14 = QuickTime encountered an Error

15 = QuickTime SG failed to start

16 = QuickTime SG failed to prepare

17 = QuickTime SG failed to set the data processor

18 = QuickTime compression session failed

19 = QuickTime Decompression session failed

20 = QuickTime SGIdle failed to initialize

21 = QuickTime data failed to process

22 = QuickTime sound failed to compress

23 = Writing the movie frame failed

24 = Could not start the process (a bit cryptic)

25 = Could not stop the process (a bit cryptic)

26 = Could not finalize the movie

27 = Action not supported

28 = Action could not resume processing

29 = OpenGL error

30 = Insufficient disk space for the action (or could not reach file system)

31 = Invalid/incorrect command

32 = Screen grab functionality disabled

November 17th, 2009

Posted In: Mac OS X Server

Tags: , , , , , , ,

Volumes can become corrupt no matter what file system you are talking about (er, there might a magical file system out there that cannot become corrupted but I’ve never heard of it and would like to sell a certain bridge to you if you have).  Xsan is no different and so you need to be ready to use the command line to combat said corruption.  fsck is the traditional *nix tool to fix issues with volume corruption.  cvfsck is the weird cousin that’s used for Xsan.  If you see any iNode errors in your logs, corruption errors, high latency or just too many weird issues to shake a stick at then use cvfsck to check for errors.  It can be run in a non-destructive mode (it is by default actually).  If errors are found then, if possible, backup the SAN immediate as cvfsck could cause the volume to get shredded (or more commonly for specified files on the volume to become unuseable).  Then you can use cvfsck to repair the volume.

April 23rd, 2006

Posted In: Xsan

Tags: , , ,