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.