Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 36 replies
  • Subscribers 1 subscriber
  • Views 105115 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mac OS - pre-configuring Autoupdate

QC

We have quite a number of Macs (not surprising at a university) but no official Mac support. Nevertheless we offer Sophos for Macs (in a downloadable .zip archive).  

When Sophos is installed on a Mac on our network it connects to the management server from where it gets the update policy (the CIDs contain the correct mrinit.conf for RMS to work). Of course this does not work if the Mac is used at home. For windows PCs putting sauconf.xml placed in the appropriate directory does the trick. There are some articles in the knowledgebase but usually a Mac is required with which you can configure the CID (if I understand correctly). I believe no magic is actually involved and the configuration is stored somewhere in a .plist file (XML format). I suspect that the catalogues are involved and configcid.exe does not support a CID for OSX.

Or is there a "simple" way to pre-configure autoupdate (even if it's unsupported)? sau.plist looks suspicous  :smileywink:

Christian

:518


This thread was automatically locked due to age.
  • 0

    bobcook wrote:

    jelockwood wrote:

    After automatically installing SAV 9.2.2 as part of my DeployStudio / Munki build process I am finding that when I first login to a freshly minted Yosemite Mac I get a dialog box appearing from Keychain Migrator asking for the password for the Sophos keychain. I of course have no idea what that password would be as it is used and created by Sophos. I therefore have to click cancel and then the login proceeds and completes normally. Sophos seems to run ok after this and the message does not seem to reoccur on subsequent logins.

    Anyone else seeing this?

    I'm keen to hear more about this, its weird and unexpected. Definitely never seen it myself nor have we had it happen in our testing, but I can't say we would necessarily have the same endpoint configuration as you'd be running. Anything non-standard in your deployments that we should be trying?

    -------------------------------

    The main if not only difference is that I am installing Sophos without actually being logged in as a user. If you use Sophos Installer.app by itself this is a GUI installer and has to be run from inside an active login, if you use the Sophos Cloud installer the same applies. As a reminder I have 'wrapped' the Sophos Installer.app inside an Apple installer package.

    As I don't have a Windows Server I cannot test using the installer package created and maintained by Sophos Enterprise Console but that (last time I saw it) was an Apple installer package and one could test deploying it to a new Mac via ARD or similar to replicate a similar situation to mine. I am using Munki to auto deploy and install my Sophos (Apple) installer package, this takes place while at the login screen with no user actually logged in. ARD, Munki, Casper, and others that support Apple installer packages can all do installs without a user needing to be logged in.

    I only see this in Yosemite, it does not happen in Mavericks.

    On a slightly different topic, is there a commandline tool in Sophos SAV9 that can force a check for updates? It would be nice to immediately follow an install with a check for updates so as to ensure it immediately is up-to-date rather than having to wait 60 minutes for this to happen automatically.

    :54293
  • 0
    jelockwood wrote:

    The main if not only difference is that I am installing Sophos without actually being logged in as a user. If you use Sophos Installer.app by itself this is a GUI installer and has to be run from inside an active login, if you use the Sophos Cloud installer the same applies. As a reminder I have 'wrapped' the Sophos Installer.app inside an Apple installer package.

    As I don't have a Windows Server I cannot test using the installer package created and maintained by Sophos Enterprise Console but that (last time I saw it) was an Apple installer package and one could test deploying it to a new Mac via ARD or similar to replicate a similar situation to mine. I am using Munki to auto deploy and install my Sophos (Apple) installer package, this takes place while at the login screen with no user actually logged in. ARD, Munki, Casper, and others that support Apple installer packages can all do installs without a user needing to be logged in.

    I only see this in Yosemite, it does not happen in Mavericks.

    Faceless installation should work (we definitely designed it to be compatible witht that style of deployment) but I'll have someone look into it more deeply. Thanks for the pointers, it definitely helps.

    BTW the version of the software managed by Sophos Enterprise Console now uses the same installer that the stand alone package is using. We switched because Apple no longer supports signing of the MPKG format (they are correct by saying it was deprected a long time ago). We continued to use that format (rather than a simple PKG) because we rely on the ability to have the SEC system glue together the software + detection data + RMS configuration, and only an MPKG could do that. We now put the files into a separate folder next to the app, and we independently validate the contents during install.

    jelockwood wrote:

    On a slightly different topic, is there a commandline tool in Sophos SAV9 that can force a check for updates? It would be nice to immediately follow an install with a check for updates so as to ensure it immediately is up-to-date rather than having to wait 60 minutes for this to happen automatically.

    /usr/bin/SophosUpdate

    This tool has been around for a while but got a major overhaul in 9.2. It used to flake out a bit when AutoUpdate itself was updated and could appear like it failed, but it actually just got disconnected.

    The software will attempt to do its own update immediately, but there isn't any harm in asking for it to do so again from your script. You should probably give the system ~30 seconds to stabilize after the installer has completed before kicking off the update. In theory the installer is doing that for you, but sometimes very poky systems take longer.

    :54307
  • 0

    I've just discovered that CreateUpdatePreconfig will throw an error for passwords using special characters- I'm not sure if this is intentional, but running it from the commandline with a password like "#thisisapassword" (without quotes) throws the following error:

    2014-10-28 10:33:54.685 CreateUpdatePreconfig[86168:507] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: '*** +[NSString stringWithUTF8String:]: NULL cString'

    *** Call stack at first throw:

    (

    0   CoreFoundation                      0x95b77471 __raiseError + 193

    1   libobjc.A.dylib                     0x9857f091 objc_exception_throw + 162

    2   CoreFoundation                      0x95b7738b +[NSException raise:format:] + 139

    3   Foundation                          0x91847533 +[NSString stringWithUTF8String:] + 90

    4   CreateUpdatePreconfig               0x000026ad main + 413

    5   CreateUpdatePreconfig               0x00002375 start + 53

    )


    Adding single quotes around the password seems to fix this. NB: the password is fine if it doesn't include the # symbol (I haven't tested other special characters)

    :54349
  • 0

    I can confirm that this works with 9.2.2 Preview with the stand alone installation, but how do we implement this with our centrally managed clients?

    I need to be able to pre-assign a group AND pre-assign a temporary update policy to each Mac (and Windows box) I install Sophos on.   

     After the installation is completed and update to our server is successful, the machine does not show up in the enterprise console.  I am assuming that this is intended because the installer is stand alone, but it highlights the need for this functionality in the managed installer because without it, the clients won't get a scan policy which we need. 

    :54389
  • 0

    So... I took the Sophos Installer.app and the Sophos Installer Components directory from the CID that hosts this version, added the file that is created when you run the script for update locations to the directory, copied them to my desktop.  I ran the installer and I got the right update address and I was in the right group.  

    Can someone else try this and confirm?

    :54391
  • 0

    bobcook wrote:

    jelockwood wrote:

    After automatically installing SAV 9.2.2 as part of my DeployStudio / Munki build process I am finding that when I first login to a freshly minted Yosemite Mac I get a dialog box appearing from Keychain Migrator asking for the password for the Sophos keychain. I of course have no idea what that password would be as it is used and created by Sophos. I therefore have to click cancel and then the login proceeds and completes normally. Sophos seems to run ok after this and the message does not seem to reoccur on subsequent logins.

    Anyone else seeing this?

    I'm keen to hear more about this, its weird and unexpected. Definitely never seen it myself nor have we had it happen in our testing, but I can't say we would necessarily have the same endpoint configuration as you'd be running. Anything non-standard in your deployments that we should be trying?

    I may have a bit more information on this. As previously mentioned I am installing Sophos from an automated system when not logged in as a user. When I log in afterwards - for the first time then the above message appears.

    It now appears that the trigger for this is logging in for a user for the first time even if the user account already exists. Normally if you are logging in for the first time then the users home directory does not yet exist along with the users Library folder, Preferences folder and login.keychain

    I think it is the absense of these at the login stage that causes the Sophos message. Now while these files will be unavoidably missing at this first login stage I still do not see why this should upset Sophos because supposedly Sophos uses its own keychain file in the /Library/Keychains folder rather than the users own personal keychain file.

    I have now see this happen with two types of user account - a local admin account created before installing Sophos but never logged in to until after Sophos is installed and hence at that point has not created a home directory, and secondly a network login account with a 'portable home directory' which when first logged in to will create a local home directory for that network login account. This second account was not an admin level user. In both cases the commonality is the absense of a home directory at the time of the first login and this then causes the message to appear. Subsequent logins with the same accounts do not cause the message to reoccur because by then the home directory exists.

    It would appear Sophos is trying to access or create something in the users home directory before the home directory has finished being created.

    A possible simple way to test would be to login as a local admin user, create a second user account, make sure the home directory for the second account does not yet exist and if it does delete it, then try logging in to the second user account which should then at that point have no existing home directory.

    :54603