Safari Develop missing....

I installed MacOS 15.4 Beta (24E5222f) today.

When I started Safari for the first time, I noticed that de develop menu was missing.

I tried reenabling it in the settings, but nothing worked.

I knew, it somehow had to work.

So the trick was to look at the settings via CLI:

defaults read  com.apple.Safari

There is an entry:

com.apple.Safari IncludeDevelopMenu 0

So I changed that by entering:

defaults write  com.apple.Safari IncludeDevelopMenu 1

Et voilà:

Starting Safari again, the Develop menu was back.

Cheers

Apple Remote Desktop 3.9 update

So you came here because you updated your clients?
You really installed the Apple Remote Desktop 3.9 Client ?

And so now some of your clients are accessible via Screen Sharing but fail to do anything else?

No packages installable? No UNIX commands executable? No reports generatable?

I had the same problem.

But I think I was able to fix it.

At least I got it running on my blocked clients.

What I did, was to execute this script on the client machines:

#!/bin/sh

# Fix ARD 3.9 clients 

rm -Rf /Library/Application\ Support/Apple/Remote\ Desktop/Client/privatekey

rm -Rf /Library/Application\ Support/Apple/Remote\ Desktop/Client/publickey

/System/Library/CoreServices/RemoteManagement/ARDAgent.app/Contents/Resources/kickstart -activate -restart -agent -console

exit 0

That's it.

The first two commands delete the client's certificates.
Kickstart is then used to regenerate the certificates needed.

Maybe the clients have to be readded to the Remote Desktop Admin

From then on, they worked as expected....

PrinterProxy & Restrictions

So, if you got here, you are looking for a solution to find out how you can prevent you users from being able to start applications from any location while still being able to print.

The big problems are:

• macOS using restriction profiles seems unable to handle relative paths. In earlier versions of OS X you could use these paths such as '~/' for the home folder to for example deny execution of applications from within the home folder
• In order to print, macOS needs to create these 'PrinterProxy' apps in the users home directory under 'Library/Printers'.

Why these PrinterProxys habe to be located within the home directory is out of my reach.
Also I don't think this is logic. Even if the printer is assigned to the machine, the folder containing those PrinterProxys is still located in the home directory of the user.

But anyway.

I tried al sorts of redirections, creating a PrinterProxy folder in /Library or /tmp and then creating a symlink that would point at these folder.
Forget it. It won't work.

So, in the end I ended up doing this:

For every file share that contains user home directories, I created an entry in the 'Allow Folder' section of the profile.

These entries look like this:

/Network/Servers//Volumes//%short_name%/Library/Printers

By using the payload variable '%short_name%" inside the path allows you to use the users short name as is most often done for the name of his home directory.

The rest of the path has to correspond to the path that you get when entering the command

pwd

in the terminal when logged in as an example user.

I hope this helps others to save some time and prevents them from going all the way again.

This procedure was verified using macOS 10.12.3

VPP & OS X Device Assignment

After having struggled for quite some time, here's what I found out when deploying VPP apps to clients running OS X or macOS using device bases assignment.

In this case we were using OS X 10.11.6 El Capitan.

This means that the apps are assigned to the device and not to the user.

One thing that was especially irritating was that we often had a dialog popping up:

«storedownloadd is trying to install new software.
Type an administrator's name and password to allow this.»

The problem is: we are deploying the software to client whose users are not administrators.

So, what's the solution?

Well, thing is, there are several players to the game.

In order to have VPP apps being installed to your computer, you need:

1. A working VPP deployment system
2. Correct settings in Restriction Profiles applied to the clients
3. Correct settings in the App Store PrefPane being used by the clients software update mechanism.

1. Working VPP

Actually I found this to be the easiest of all.

We use FileWave to deploy our apps, but the problems we were having were independent of any special software.

2. Restriction Profiles

In order to really understand what's going on if you deploy VPP apps to the device, you need to know this: The apps being installed from VPP are actually being installed by the user currently logged in.

This means this:

• The local user has to be able to install apps.
• The user has to be able to use the app store
• A non admin user has to be able to install apps
• If no-one is logged in, apps are not being installed

If we look at a restriction profile, this is what we see:

In here there are two points:

One is: «Require admin password to install or update apps».

This has to be turned of because otherwise only admins are able to install apps.

Remember VPP is using the current user to install the apps which might not be an admin user.

This would make this dialog mentioned above to pop up and the app would not be installed correctly.

3. App Store Settings

In the App Store Pref Pane there are two things that need to be set correctly.

It should look something like this:

Two of these points seem to be affecting the deployment of VPP apps:

First we need to enable 'Automatically check for updates' in order to get the mechanism to work.

Second, the item 'Install app updates' has to be enabled.

The reason for this seems to be that the software deploying an app to a device seems to actually be assigning a license to the device, the installation all updates of the app itself are being done via App Store. So if we close down the app store for a client, it won't be able to download and install any apps.

I used a script to remove any previously configured settings to the app store and configure them as required. The script looks like this:

#!/bin/bash

# Configure app store to only download critical system updates and vpp apps

# Information taken from:

# https://discussions.apple.com/thread/6683455?start=0&tstart=0

# Switch off Software update schedule

/usr/sbin/softwareupdate  --schedule off

# Remove App Store Preferences

/usr/bin/defaults delete /Library/Preferences/com.apple.commerce.plist

# Remove Softwareupdate Preferences

/usr/bin/defaults delete /Library/Preferences/com.apple.SoftwareUpdate.plist

# Enable automatic update checking

/usr/bin/defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist AutomaticCheckEnabled -bool YES

# Disables automatic update download

/usr/bin/defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist AutomaticDownload -bool NO

# Enable automatic Configuration Data

/usr/bin/defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist ConfigDataInstall -bool YES

# Enable critical updates

/usr/bin/defaults write /Library/Preferences/com.apple.SoftwareUpdate.plist CriticalUpdateInstall -bool YES

# Disable App restart

/usr/bin/defaults write /Library/Preferences/com.apple.commerce.plist AutoUpdateRestartRequired -bool NO

# Disable app updates

/usr/bin/defaults write /Library/Preferences/com.apple.commerce.plist AutoUpdate -bool YES

# Switch off Software update schedule

/usr/sbin/softwareupdate  --schedule on

exit 0

Deploying this script to my clients configured the correct settings.

Now deploying VPP apps to OS X devices is working correctly.

OS X Calendar Server Maintenance and Cleanup

Having some troubles with my calendar server, I decided, it was time for a cleanup.

We are running the Calendar Server on OS X 10.11.x El Capitan.
Server App version 5.1.5.

First thing to do was to reindex the database.

This is my script that does this. I reads a list of the databases and then issues a reindex command to each table:

#!/bin/sh

# Reindex all calendar server databases

# © 2016 kurt hofmann

# Get stat of the calendar server

calStat=`serveradmin status calendar | grep "calendar:calendarState"`

echo "$calStat" | grep "RUNNING" >/dev/null 2>&1

  if [ "$?" -eq "0" ]; then

      echo "Calendar is running"

      CalRunning=true

  else

      echo "Calendar is stopped"

      CalRunning=false

  fi

if $CalRunning ; then

  echo "Stopping calendar server"

  serveradmin stop calendar

fi

# Do the database stuff

export PGDATABASE=caldav

export PGUSER=caldav

# Get list of tables

dbt=`psql -h /var/run/caldavd/PostgresSocket/ << EOF

\d ;

EOF`

dblist=`echo "$dbt" | cut -d "|" -f 2 | grep "^ " | grep -v "^  "`

# With each database in the list, issue a reindex command

for db in $dblist

do

echo "Now reindexing table $db"

dbt=`psql -h /var/run/caldavd/PostgresSocket/ << EOF

REINDEX table $db ;

EOF`

done

# Restart Calendar server if it was running before we started

if $CalRunning ; then

  echo "Starting Calendar"

  serveradmin start calendar

fi

exit 0

Second thing to do was to purge all old calendar entries.

I already had a script that did this, but this no longer worked because this can no longer be done for all users in one go.

The command:

/Applications/Server.app/Contents/ServerRoot/usr/sbin/calendarserver_purge_events

now requires a userid.

So, I first need to read the contents of the databases to find the uids of all the users that actually use the calendar. Then I delete the entries older than 365 days on the calendar.

Then we do the same thing with the attachments.

The script goes like this:

#!/bin/sh

# Using hints from myself ;-) :

#http://osxadmin.blogspot.ch/2015/06/os-x-yosemite-calendar-server-utilites.html

# These are the commands involved:

#/Applications/Server.app/Contents/ServerRoot/usr/sbin/calendarserver_purge_events -nv

#/Applications/Server.app/Contents/ServerRoot/usr/sbin/calendarserver_purge_attachments -nv

#psql -h /var/run/caldavd/PostgresSocket/ --username=caldav

export PGDATABASE=caldav

export PGUSER=caldav

# Get the UIDs of all users

dbt=`psql -h /var/run/caldavd/PostgresSocket/ << EOF

SELECT * FROM calendar_home;

EOF`

theUsers=`echo "$dbt" | cut -d "|" -f 2 | grep "^ " | grep -v "^  "`

# Purge all old data

for uid in $theUsers

do

  echo $uid

  theResult=`/Applications/Server.app/Contents/ServerRoot/usr/sbin/calendarserver_purge_events -u $uid`

  purge_events=`echo "$theResult" | grep "older"`

  echo "$purge_events"

  /Applications/Server.app/Contents/ServerRoot/usr/sbin/calendarserver_purge_attachments -u $uid

  echo "----"

done

Creating Custom Guest Users on OS X with OS X 10.11 El Capitan

We were using the script by 'rtrouton' from his page  Creating Custom Guest Users on OS X | Der Flounder for our clients up to 10.10 Yosemite.

Unfortunately this script no longer worked when we upgraded to OS X version 10.11 'El Capitan'.

We tried everything, but always ended up with keychain errors.

When logging in, the guest user obviously tried to access keychains which at that moment weren't there or not accessible.

We the tried to revert back to the system guest.
That seemed to work. Until we removed the parental controls from that user at which point the system created a new user named 'Guest1' which had some other problems….

So, after trying around quite a lot, I found a solution.
The changes are actually quite simple. There are tow things that have to be changed:

1. Add a password for the guest user. The script won't work with empty passwords
2. The entry in the keychain added has to be accessible to all processes. To allow that the parameter '-A' is added to this step

So this is my version of the script:


#!/bin/bash

# Original script by Noel B. Alonso: https://gist.github.com/nbalonso/5696340
# Modified script by rtrouton: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/create_custom_guest_account
#variables
DSCL="/usr/bin/dscl"
SECURITY="/usr/bin/security"
LOGGER="/usr/bin/logger"

# Determine OS version
OSVERS=$(sw_vers -productVersion | awk -F. '{print $2}')

# Set the account shortname
USERNAME="Gast"

# Set the name which is displayed in System Preferences for the account
DISPLAYNAME="Gastbenutzer"

# Set the account's UID
GUESTUID="600"

# Set the account's GID
GUESTGROUPID="600"

if [[ ${OSVERS} -lt 6 ]]; then
  ${LOGGER} -s -t create"${USERNAME}".sh "ERROR: The version of OS X running on this Mac is not supported by this script. User account not created."
fi

if [[ ${OSVERS} -eq 6 ]]; then
${LOGGER} -s -t create"${USERNAME}".sh "INFO: Creating the "${USERNAME}" user account on Mac OS X 10.${OSVERS}.x"
${DSCL} . -create /Users/"${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" UserShell /bin/bash
${DSCL} . -create /Users/"${USERNAME}" RealName "${DISPLAYNAME}"
${DSCL} . -create /Users/"${USERNAME}" UniqueID "${GUESTUID}"
${DSCL} . -create /Users/"${USERNAME}" PrimaryGroupID "${GUESTGROUPID}"
${DSCL} . -create /Users/"${USERNAME}" NFSHomeDirectory /Users/"${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" RecordType dsRecTypeStandard:Users
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_defaultLanguage de
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_guest true
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers__defaultLanguage "${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers_jpegphoto "${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers_LinkedIdentity "${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers_picture "${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers_UserCertificate "${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" AppleMetaNodeLocation /Local/Default
#setting up an empty password and giving local Kerberos some time to process it
${DSCL} . -passwd /Users/"${USERNAME}" ''
sleep 2
fi

if [[ ${OSVERS} -ge 7 ]]; then
${LOGGER} -s -t create"${USERNAME}".sh "INFO: Creating the "${USERNAME}" user account on Mac OS X 10.${OSVERS}.x"
${DSCL} . -create /Users/"${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_defaultLanguage de
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_guest true
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers__defaultLanguage "${USERNAME}"
# Adding the _writers_LinkedIdentity attribute for Macs running Mac OS X 10.7.x. This
# attribute is not needed on 10.8.x and later.
if [[ ${OSVERS} -eq 7 ]]; then
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers_LinkedIdentity "${USERNAME}"
fi
${DSCL} . -create /Users/"${USERNAME}" dsAttrTypeNative:_writers_UserCertificate "${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" AuthenticationHint ''
${DSCL} . -create /Users/"${USERNAME}" NFSHomeDirectory /Users/"${USERNAME}"
#setting up an empty password and giving local Kerberos some time to process it
${DSCL} . -passwd /Users/"${USERNAME}" "${USERNAME}"
sleep 2
${DSCL} . -create /Users/"${USERNAME}" Picture "/Library/User Pictures/Nature/Leaf.tif"
${DSCL} . -create /Users/"${USERNAME}" PrimaryGroupID "${GUESTGROUPID}"
${DSCL} . -create /Users/"${USERNAME}" RealName "${DISPLAYNAME}"
${DSCL} . -create /Users/"${USERNAME}" RecordName "${USERNAME}"
${DSCL} . -create /Users/"${USERNAME}" UniqueID "${GUESTUID}"
${DSCL} . -create /Users/"${USERNAME}" UserShell /bin/bash
#Adding the keychain item that allows "${USERNAME}" to login in 10.7 and later.
${SECURITY} add-generic-password -a "${USERNAME}" -s com.apple.loginwindow.guest-account -A -w "${USERNAME}" -D "application password" /Library/Keychains/System.keychain


# Restart loginwindow
/usr/bin/killall loginwindow
fi

${LOGGER} -s -t create"${USERNAME}".sh "INFO: Exiting"

exit 0

VMware ESXi 6.0 Update 2 & SSH

So you upgraded to VMware ESXi 6.0 Update 2 and now your passwordless SSH login is no longer working?

Same happened to me yesterday.

Allowing SSH access to ESXi/ESX hosts with public/private key authentication (1002866)

is of no help because this no longer works.

It looks as if though your 'authorized_keys' file could not be found.

After searching around a bit ( admittedly a quite long bit) , I found out the cause and the solution.

In this file '/var/log/auth.log' there are entries that show this

userauth_pubkey: key type ssh-dss not in PubkeyAcceptedKeyTypes

Seems that this is a hint.

Following that, I quite quickly got the impressions that this update has changes to SSH in it.
Apparently it includes a new version of SSH.

To verify this: let's try:

ssh -V

OpenSSH_7.1p1, OpenSSL 1.0.1p 9 Jul 2015

So OK, that is a new version.

Further following this road gets me here:
http://www.openssh.com/txt/release-7.0

This reads:

 * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
   by default at run-time. These may be re-enabled using the
   instructions at http://www.openssh.com/legacy.html

So OK, let's go there:  http://www.openssh.com/legacy.html

Here I read:

OpenSSH 7.0 and greater similarly disables the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use. It can be re-enabled using the HostkeyAlgorithms configuration option:

ssh -oHostKeyAlgorithms=+ssh-dss user@127.0.0.1

or in the ~/.ssh/config file:

Host somehost.example.org
 HostkeyAlgorithms ssh-dss

So OK, but how do I enable it?

Lets see. Clearly we need to edit the file '/etc/ssh/sshd_config'.
So after having created a backup of this file (and having me ending up locked out several times), I added two and tow together and tried this:

vi /etc/ssh/sshd_config

Here I added the line

HostkeyAlgorithms ssh-dss

 Then restart the SSH daemon

/etc/init.d/SSH restart

But. It still doesn't work.

OK, but I still think this is the right way to go.

Restore the backuped file.
So we add two and three together which looks like this:

vi /etc/ssh/sshd_config

Now I add the line

PubkeyAcceptedKeyTypes ssh-dss

Then again:

 /etc/init.d/SSH restart

Et voilà. It works.

So all you have to do is add the line

PubkeyAcceptedKeyTypes ssh-dss

to the file ' /etc/ssh/sshd_config' and then restart the SSH daemon using

 /etc/init.d/SSH restart

That's it.

Mac Pro & ESXi & Promise SANLink2 10G SFP+

We were looking for a replacement of our Xserves for our ESXi cluster.

The only valid option to do so if you still want to be able to run some OS X servers on them was to replace the Xserves by Mac Pros.

So we bought two of those black cans. 12 cores.

As our storage is attached via 10g SFP we needed to so the same with our new servers.
So I ordered two 'Promise SANLink2 10G SFP+'.

It was only then when the question arised, whether VMware Sphere with ESXi was going to support this Thunderbolt interface.

So I sent an email to Promise.
They told me that as they only supplied Mac drivers, this was not going to work.

Hmm.

On the other hand, I had this bit of information:

The SANlink2 is based on Intel's 10Gbe chipset like
our 10Gbe Intel cards do and so it should work
on ESX.

 So when the interfaces arrived, I tried them out using a MacBook Pro.

And guess what: It works.

The  'Promise SANLink2 10G SFP+' shows up as a regular 'Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection' with two interfaces at 10000, just as it should.

Great.

iOS Update

Just in case you should try the same thing: don't.

As I was having different problems with my iPad I thought it might be a good idea to make a clean install.

So I tried these steps:

• Backup, both local and to iCloud
• Reset the iPad
• Update the iPad
• Restore the data

Fact is, at least when updating form 8.4.1 to 9.0, it won't work.

Restoring the data from an oder backup to an iPad with a newer system version will end up in a mess.

So what I did was, downgrade the iPad to 8.4.1 again and restore the update.

Then update. 

ESXi 6.0 on Apple Xserve crashes

After having lots of problems with my Xserves crashing al lot after having upgraded them to ESXi 6.0, I decided I had to solve this.

Basically ESXi 6.0 with vSphere runs on Xserves.

After some time, i found out that it was not the server crashing.
It was the network connection that went down.

I knew this because a) the server was not dead, no PSOD or anything, and on my secondary network interface, the server was still pingable.

So, what did we do:

The Xserve 3.1 comes with these NICs installed:

Intel Corporation 82574L Gigabit Network Connection

So what we did is exchange the PCI NIC to a

Intel Corporation I350 Gigabit Network Connection

Soon after that, VMware released ESXi 6.0U1.

And what do I read in the Release Notes:

VMware vSphere 6.0 Updated 1 Release Notes

An ESXi host might lose connectivity and e1000e virtual NIC might get reset 

An ESXi host might intermittently lose connectivity and e1000e virtual NIC might get reset. An All Paths Down (APD) condition to NFS volumes might also be observed. An error message similar to the following is written to the vmkernel.log file

packets completion seems stuck, issuing reset

This issue is resolved in this release.

You can check if this might be the case if you enter this in the command line of your server:

1. esxcli network nic list  

If a driver is listed as «e1000e» then you could try updating to 6.0U1

OS X Yosemite Calendar Server Utilites

So when writing a script to back up my calendar server, I noticed that the folder

/Library/Server/Calendar and Contacts

was using up 233MB. While that might not seem a lot - when keeping 10 copies, it will still use some disk space.

So then it came to my mind, that, when time passes by, there are a lot of events, that nobody no longer cares about.
Surely there must be some kind of mechanism to remove those expired events.

So I went looking around on the command line.

What I found were these commands:

calendarserver_command_gateway    

calendarserver_config             

calendarserver_diagnose           

calendarserver_export             

calendarserver_gather_logs        

calendarserver_import             

calendarserver_manage_principals  

calendarserver_purge_attachments  

calendarserver_purge_events

calendarserver_purge_principals

For us especially interesting are these:

You can get some help by calling them with the '-h' option

calendarserver_export

Usage: calendarserver_export [options] [input specifiers]

This tool reads calendar data from a series of inputs and generates a single

iCalendar file which can be opened in many calendar applications.

This can be used to quickly create an iCalendar file from a user's calendars.

This tool requires access to the calendar server's configuration and data

storage; it does not operate by talking to the server via the network. It

therefore does not apply any of the access restrictions that the server would.

As such, one should be mindful that data exported via this tool may be

sensitive.

Please also note that this is not an appropriate tool for backups, as there is

data associated with users and calendars beyond the iCalendar as visible to the

owner of that calendar, including DAV properties, information about sharing, and

per-user data such as alarms.

Options:

  -D, --debug        Debug logging.

  -f, --config=      Specify caldavd.plist configuration path. [default:

                     /Applications/Server.app/Contents/ServerRoot/private/etc/caldavd/caldavd-apple.plist]

      --help         Display this help and exit.

  -c, --collection=  Add a calendar collection. This option must be passed after

                     --record (or a synonym, like --user). for example, to

                     export user1's calendars called 'meetings' and 'team',

                     invoke 'calendarserver_export --user=user1

                     --collection=meetings --collection=team'.

  -r, --record=      Add a directory record's calendar home (format:

                     'recordType:shortName').

      --version      Display Twisted version and exit.

  -u, --user=        Add a user's calendar home (shorthand for '-r

                     users:shortName').

  -d, --directory=   Specify output directory path.

  -o, --output=      Specify output file path (default: '-', meaning stdout).

      --uid=         Add a calendar home directly by its UID (which is usually a

                     directory service's GUID).

This will thus allow you to export a users calendar from the server. Might be interesting one day.

But what I'm really looking for are these:

calendarserver_purge_events

calendarserver_purge_events -h

usage: calendarserver_purge_events [options]

  Remove old events from the calendar server

options:

  -h --help: print this help and exit

  -f --config : Specify caldavd.plist configuration path

  -d --days : specify how many days in the past to retain (default=365)

  -n --dry-run: calculate how many events to purge, but do not purge data

  -v --verbose: print progress information

  -D --debug: debug logging

So this is the command to delete old events.

In my case, when calling it using the 'dry run' option, I got this response:

calendarserver_purge_events -nv

NOTICE:  there is no transaction in progress

(Dry run) Searching for old events...

6590 events are older than 20140625T000000

So, I could easily remove 6950 events that are more than one year old! Cool.

calendarserver_purge_attachments

Now I know that some people often attach documents to events. So we should clean up those as well.

So let's check this out:

calendarserver_purge_attachments -h

usage: calendarserver_purge_attachments [options]

  Remove old or orphaned attachments from the calendar server

options:

  -h --help: print this help and exit

  -f --config : Specify caldavd.plist configuration path

  -u --uuid : target a specific user UID

  -d --days : specify how many days in the past to retain (default=365) zero means no removal of old attachments

  -n --dry-run: calculate how many attachments to purge, but do not purge data

  -v --verbose: print progress information

  -D --debug: debug logging

In our case, a dry run returns this:

calendarserver_purge_attachments -nv

NOTICE:  there is no transaction in progress

(Dry run) Searching for orphaned attachments...

(Dry run) Searching for old dropbox attachments...

(Dry run) Searching for old managed attachments...

Orphaned/Old Attachments by User:

+-----------------+---------------+-------------+--------------+--------------+---------------+--------------+---------------+------------+-------------+

|       User      | Current Quota | Orphan Size | Orphan Count | Dropbox Size | Dropbox Count | Managed Size | Managed Count | Total Size | Total Count |

|-----------------+---------------+-------------+--------------+--------------+---------------+--------------+---------------+------------+-------------|

| wiki-haxxxxxxxxx |      18883053 |      817155 |            6 |     18062725 |           332 |            0 |             0 |   18879880 |         338 |

|=================+===============+=============+==============+==============+===============+==============+===============+============+=============|

| Total:          |               |      817155 |            6 |     18062725 |           332 |            0 |             0 |   18879880 |         338 |

+-----------------+---------------+-------------+--------------+--------------+---------------+--------------+---------------+------------+-------------+

That means there are quite some attachments that can be removed that are older than one 365 days.

So, time to write a script that will perform these cleanups once a month.

Hooray!

Yosemite: dump calendar server database

I always knew it.

One day that server is gonna crash and that calendar database will be gone.

As it is it happened the day I was going to write my export script.

I was lucky enough to have some backup.
But it's not gonna get me again. So I started writing my daily dump script.

It's not done quite yet.

But the main step is done.
I found out how to successfully dump the calendar database.

The command to do so is:

sudo -u _calendar /Applications/Server.app/Contents/ServerRoot/usr/bin/pg_dumpall -h /var/run/caldavd/PostgresSocket/ -f /Users/Shared/calendar_$(date +%Y%m%d).pgdump

Logic Pro X Additional Content download

We want to deploy Logic Pro X in one of our computer labs.

As Logic wants to download huge amounts of additional content when installed and our users are not admins on the lab machines, we have to deploy the additional content as well.

These are the steps I figured out to install the additional content packages via our software deployment.

Same thing as written for GarageBand applies to Logic as well

Here's the link to the plist containing all the information for the additional content packages of Logic Pro X 10.1.1:

http://audiocontentdownload.apple.com/lp10_ms3_content_2015/logicpro1010.plist

To get the information needed, enter this command:

defaults read ~/Downloads/logicpro1010 | grep DownloadName

You will then end up with a list of the packages.

Some updated content is added via App Store.

So maybe there is a better way to do this.

Let's try it this way.

1. Activate the AppStore debug mode#   
• Quit the AppStore.app if it is running
• open the terminal and enter "defaults write com.apple.appstore ShowDebugMenu -bool true"
• Start AppStore.app and open the Menu 'Debug > Show Download Folder…"
2. Download Logic Pro X
3. Start Logic Pro X - it will ask to download additional content
4. Allow Logic to download the content, but, when asked for your admin credentials, click 'Cancel'. Do NOT install anything at this point.
5. Quit Logic Pro X
6. Navigate to the ausic apps download folder, You can find it in the same folder as the 'iTunes Download Folder'. It will look something like this '/private/var/folders/nc/t8zc00xs2nx1vmcjyxryf11w0000gn/C/com.apple.MusicApps' where the part in the middle seems to be a randomly generated string. 
7. In the folder 'com.apple.MusicApps' you should now see a folder named 'audiocontentdownload.apple.com' and inside that another called 'audiocontentdownload.apple.com'. Here we find what we need: the 'ProAudioCoreContent10.pkg'.
   
8. Place a copy of  'ProAudioCoreContent10.pkg' somewhere else from where you can install it later.
9. Start Logic Pro X. It will no ask you for the credential to install the package, we already downloaded.
10. Now we come to the additional content.
11. Select menu 'Logic Pro X > Download Additional Content'
12. Select any of the additional content packages you want to deploy
13. Click 'Install'
14. Wait for the download to complete
15. When prompted for the admin password, do NOT enter it. Click 'Cancel' instead
16. Quit Logic Pro X
17. Inside the directory of the folder containing the download there should now be a folder named 'com.apple.MusicApps >  com.apple.MusicApps > audiocontentdownload.apple.com > lp10_ms3_content_2015' and some more in 'lp10_ms3_content_2013'.
18. In these folders you will now find the packages needed to deploy the additional content. 
    
19. Copy these packages to a safe place.
20. Deploy them as needed
21. When you start Logic Pro X with the packages installed, you will see that all the additional content is already installed.

OS X 10.9 Mavericks and Keychain

We had massive problems with OS X 10.9 Mavericks and Keychains.

Theses problems mainly occurred to users with network home directories.
It affected some massively while others had not problems at all.
Even on the same Mac.

In our case this caused mail and calendar to be unusable to those affected.

Updating to that latest 10.9 seemed to help somewhat.

These steps seem to cure the the problems on the other users affected:

• Delete every folder in ~/Library/Keychains that has a name somewhat like for example 'ABF6C3A9-702E-5666-AE78-0D0D96A676BA'.
• Delete ~/Library/Preferences/com.apple.security.cloudkeychainproxy3.keysToRegister.plist
• Delete ~/Library/Preferences/com.apple.security_common.plist
• Reboot
• Open 'System Preferences > Internet Accounts'.
• Select each account and enter the passwords as required

From there on mail and calendars work seamlessly again.

ESX & OS X Yosemite 10.10.1

Last week I upgraded my Caching Server from OS X 10.9 Mavericks to 10.10.1 Yosemite.
It runs on my ESX.

I installed the latest vmware tools. Version 9354.

The problem was, that now I could no longer log in to my server.
It was hanging after I entered the password.
Loginwindow got stuck.

I could log into the server per SSH, so that was not a problem.
When I killed the loginwindow process using

killall loginwindow

I could login again. Most of the times.

Finally I got to the point at which I made the vmware tools responsible for this behavior.
As soon as I had uninstalled them, the situation got better.

So. What now.

I finally had an idea. Sure I did - otherwise I wouldn't be writing this, would I.

I knew that VMware Fusion supported Mavericks and had recently been updated.
So my guess was, that Fusion may contain a newer version of the vmware tools.

So I opened this image:

/Applications/VMware Fusion.app/Contents/Library/isoimages/darwin.iso

And installed the package that I found there.

Now I am running vmware tools version 9504 and the problems are gone.

BTW:
The same thing applies to Windows 10.
Just mount this image:

/Applications/VMware Fusion.app/Contents/Library/isoimages/windows.iso

Inside the Windows 10 VM and install the VMware Tools from there.