I've seen a number of postings regarding installing Sophos Central (including https://www.jamf.com/jamf-nation/discussions/12348/script-to-launch-sophos-cloud-installer which ultimately points to a derflounder post) but I'm not having any luck at all with getting things to work...
Can someone help me out a bit? Have things changed since the referenced post?
Solved! Go to Solution.
I assume you're trying to get Sophos Cloud installed from what I gather?
Here's what we do
#!/bin/sh ## postinstall # # Created using this Sophos KB article: # https://community.sophos.com/kb/en-us/14179#v9.2+ # sudo /private/var/tmp/sophos/Sophos Installer.app/Contents/MacOS/Sophos Installer --install; # # Remove installer /bin/rm -rf /private/var/tmp/sophos; exit 0 ## Success exit 1 ## Failure
Hope this helps. It works as a normal pkg for Casper or ARD.
@steve1127 when you added the "sudo chmod 0755 /Library/Application Support/” command to a .pkg, was that just an empty package containing the command or did it include the Sophos installer files as well.
I ask cuz I just ran that command manually, then tried to install Sophos manually, and it still failed.
I was able to use #calvins awesome script to install Sophos 9.7.6 but I received the message System Extension Blocked. Once I went into the security settings and allowed it... Sophos appears to be running and says my computer is protected. Is there anyway to automate approving the System extension? Thanks, Ray
@rgerman , you need to also do a Configuration Profile that whitelists the Sophos Kernel Extension's TeamID. At a high level in general, we whitelist a ton of Kernel Extensions in a single profile scoped to all machines that have User Approved MDM enabled, including Sophos.
See this screenshot for what you need
Whitelisting a Team ID blesses everything that uses that same ID. So Sophos installs something like 4 kernel extensions, but you can get away just doing the Team ID they all share. That single entry in my screenshot is the only Sophos thing we have to whitelist to Endpoint work.
There's a good script in this other thread about finding these extensions and all the ID's associated with them. By @franton, here.
We run a simplified version of that on all our Macs 1x as a policy, then we just have to skim policy logs on a machine if someone needs one added to our global whitelist. We have 22 total Team IDs in there right now, but only Sophos and HP complained about needing it approved; the rest were pre-emptive.
Also, I just edited my OP script with the one we are currently using. We had a couple cases come up where some Macs were cloned with bad permissions on /, /Library, and /Library/Application Support, and it turns out the Sophos installer doesn't like that at all. So, I added some cursory logging and checking for that.
I am new to Sophos Endpoint Protection and have to say it is proving a bit more challenging than I ever expected.
Using @calvins script, I was able to automate the installation. I was also able to make a configuration profile whitelist and thought I was home free. I have one last issue which I was curious how others were handling.
After successfully installing Sophos on my test bed macs (which are local accounts not bound to AD) and another users computer who is bound to AD. I logged Sophos Central and noticed all of the devices were showing up under my User account under the people tab. Not a good thing, as this would not allow me to assign policies to groups. Are you guys using the AD Sync tool with Sophos... and if you are, will the installer match up the user automatically?
That's what I saw too. As far as I know, it's because your user generated the link. We don't manage Sophos on a user-basis, so we didn't bother messing with it. But yeah, there are totally like 2,000+ Macs with the same user that generated the link in ours.
I looked at automatically generating download links based on who was logged in when it ran with Sophos' API and didn't get very far. I think we also asked Sophos for a generic non-user based download link that never expired and I don't think we got anywhere with that. That was a while ago though, might be worth asking your rep.
For what it's worth here is our current Sophos situation.
I downloaded from the Sophos Central Console the Mac installer. (This is in reality a downloader for the real installer, lots of people including myself have complained to Sophos about not being able to download a full installer since this means each and every computer downloads the entire full installer over the Internet.)
I then used Richard Trouton's script as the basis for creating an Apple Installer package, as payload it contains the Installer nee Downloader and the Sophos Installer Components folder inside of which is one or more plists. These plists let you configure settings to apply to each client.
As mentioned previously in this thread DeployStudio 1.7.8 - the current version causes a folder to have incorrect permissions which in turn causes Sophos 9.7 and later to fail to install. This can be fixed without having to mess with SIP by creating another DeployStudio workflow that runs a script that does the required chmod to fix the permissions, because this runs in single user mode it works even with SIP on, this workflow then triggers a deliberate reboot as the second - final step rather than letting it simply reach the end of the workflow, not sure if this is necessary or not, it might prevent DeployStudio messing the permissions again, at a minimum it makes this a very quick workflow.
Note: This DeployStudio issue is supposedly fixed in the beta 1.7.9.
We do this before enforcing FileVault encryption but it would still be possible with an encrypted drive, in that case you would need to run Disk Utility in DeployStudio runtime to mount the encrypted volume and enter a valid password to authorise this.
We do push via JSS a Profile containing a list of Team IDs to whitelist various Kernel Extensions, I have quite a list now. Arguably rather stupidly, even some of the Kernel Extensions included as standard with macOS have to be approved, e.g. Atto, Promise, HighPoint etc. I also approve VirtualBox, Parallels, VMware, TunnelBlick, Sophos and so on.
I install Sophos using the afore mentioned pkg via Munki, in Munki I have a conditional check script to see if the folder permissions are correct otherwise Munki will not try to install it. If Munki was to try to install it with the wrong permissions then the install would fail but a receipt would be left behind which would mean Munki would think it had succeeded when it hadn't.
I do not find that all Macs show up under a single user, we are using local only accounts and it seems to show up under what ever user logs in when the Sophos agent 'phones home'. However we do not use the user name information much anyway, it helps tracking which user to speak to if there is a problem but we can do that via the machine name anyway. I have not found that my pkg with the original downloaded Sophos Installer expires, it has been working for several months.
I am finding that far too often when a Mac updates Sophos this results in Sophos Central flagging 'one or more services is not installed or running', clearly this is because during the update the old version of a service is removed and the new one installed and started and there is an inevitable gap, Sophos need to fix this. One Monday I came in and 10% of our Macs had such reports. These typically clear themselves by/during the next time the client phones home or updates. However as these are red-flag rather than amber-flag error this is causing a lot of extra work to double check all machines are indeed properly protected. I have a ticket open with Sophos over this.
I cant thank you guys enough for all the info. I would have been fighting this for hours/days.
Looks like deploying Sophos is doable, but they sure made it more difficult than it needs to be. At least it sounds like one it is installed it is fairly trouble free :)
Once again, thank you for all the input!
I'm using the script that has been posted here a few different ways. Do you all have an issue with the installer script hanging? Outside of the script, running int --install command I get a hang here:
DATE TIME Sophos Installer[1027:12677] Starting Sophos Bootstrap Installer.
I have a config profile that allows the Team ID, so it's not hanging there. The app actually installs and is running fine, but the script never exits properly. Anyone else have this issue, and more importantly, is there a work around?
I have not had that problem. I see the the lines below in the details after the script runs. I replaced the path/link to the installer with /hereiswhereyourinsallernamegoes// since it is specific to my install.
Script result: We are getting Sophos Endpoint from: https://api-cloudstation-us-east-2.prod.hydra.sophos.com/api/download/hereiswhereyourinsallernamegoes/SophosInstall.zip % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
100 2677k 0 2677k 0 0 2577k 0 --:--:-- 0:00:01 --:--:-- 2574k
100 2760k 0 2760k 0 0 2645k 0 --:--:-- 0:00:01 --:--:-- 2644k
2018-07-09 14:48:38.146 Sophos Installer[19514:4907266] Starting Sophos Bootstrap Installer.
2018-07-09 14:50:00.161 Sophos Installer[19514:4907266] Installation successful.
Big thanks to @calvins for the script. I've been using it since version 1.0 and it works great.
Recently I'm seeing some installs hanging, Sophos installs and functions okay but the installer process does not quit. The script stays active and prevents other policies from running. This happens on both 10.12 and 10.13 (w/ approved KEXT profile), maybe the same issue you are having @thegooch49?
Hi @MrRoboto , it seems that I'm having the same issue that you are. JAMF aside, when I run the script, and it hangs for about 40-50 minutes before exiting. After about 4 minutes of the script executing, Sophos is installed, updated, and enabled. I'm not sure what it's doing for the other 35+ minutes, but nothing jumped out at me in the system logs.
The .zip we are downloading is an older one, I think I may need to go through this all again, and see if it's simply an artifact from an old installer.
@MrRoboto and @thegooch49, I'm using a slightly tweaked version of @mkremic's script and I'm seeing the same problem with a current download URL. I started getting reports from our techs about it hanging while I was out of the office yesterday. They left one overnight so I could take a look at it, and it's still sitting there. Kind of at a loss here.
@kericson we used to use the packaging method and would run into the same issue, had to download a newer installer to make things work. In this case we have ditched packages and use a single script to deploy Sophos, it downloads the latest installer and then runs locally. For some reason the install completes but the installer process does not end.
@thegooch49 / @MrRoboto We're experiencing the same where the Sophos installs successfully as always, but within the last week or two, the installer isn't closing to allow other policies to run. Same script we've used for over a year with no changes. Haven't determined what's changed or the cause.
EDIT: I have to imagine this is coincidental, but looking at when we started noticing the issue, it coincides with when JAMF separated Sophos Antivirus and Sophos Endpoint in Patch Reporting (https://www.jamf.com/jamf-nation/discussions/28681/sophos-antivirus-and-sophos-endpoint-software-title-split)
I added a few lines to my installation script so it will watch for Sophos to start up and then kill the installer. It's kind of a hacky workaround, but in my limited testing so far it seems to work. If a user is logged in it looks for SophosAgent to be running, and if the computer is at the login window it just waits for Sophos Endpoint.app to show up in /Applications.
My script is based on a simpler version of the script that was posted near the beginning of this thread, so if you need to do the permissions checking and such you'll obviously need to adapt it. Also, I'm still relatively new to bash scripting, so if anyone sees something I could have done better I would welcome some feedback. :)
#!/bin/bash # Sophos Installation Script # https://www.jamf.com/jamf-nation/discussions/23168/sophos-cloud-installs#responseChild152451 # https://community.sophos.com/kb/en-us/120570 # Isaac Nelson 19 March 2018 # Updated 27 July 2018 with workaround for bug that causes the installer process to hang even though installation has completed successfully. installerDir=/private/var/tmp/sophos installerURL=$4 currentUser=$(/usr/bin/stat -f "%Su" /dev/console) /bin/mkdir $installerDir # Download Sophos /usr/bin/curl -L -o $installerDir/SophosInstall.zip "$installerURL" /usr/bin/unzip -o $installerDir/SophosInstall.zip -d $installerDir # Fix permissions on installer /bin/chmod a+x $installerDir/Sophos Installer.app/Contents/MacOS/Sophos Installer /bin/chmod a+x $installerDir/Sophos Installer.app/Contents/MacOS/tools/com.sophos.bootstrap.helper # Run the Sophos installer $installerDir/Sophos Installer.app/Contents/MacOS/Sophos Installer --install & # Kill the installer once Sophos is up and running (workaround for bug that causes the installer process to hang even though installation has completed successfully) # Wait until SophosAgent is running before finishing up (checking every 5 seconds) # User logged in if [[ ! "$currentUser" == "root" ]]; then until /usr/bin/pgrep SophosAgent; do /bin/sleep 5; done #Login Window elif [[ "$currentUser" == "root" ]]; then until [[ -e "/Applications/Sophos Endpoint.app" ]]; do /bin/sleep 5; done sleep 10 fi # Cleanup /bin/rm -rf "$installerDir" /usr/bin/killall "Sophos Installer"
@aeaton With the two dashes it will do a silent install, so you shouldn't be seeing the Sophos GUI installer. However, as we've been discussing above, there seems to be a bug in the Sophos installer that prevents it from exiting when it's done. I'm getting around that by essentially having the postinstall watch for Sophos to start up, then it forces the installer process to exit.
Before I could make any changes to our script (was going to test out @aeaton 's method above), I'm finding that all our Sophos installs today are working fine and the installer is closing without issue.
Is anyone else seeing this too or is the issue persisting for y'all?
EDIT: Nevermind. Issue still persisting.
Regarding the if then else loop at the bottom maybe I'm being dense but the $currentUser variable is going to return the console user i.e. the logged in user, not root. The script would hang at that point every time in my case because root was never logged in despite the jamf binary running scripts, etc. as root. I changed it so that it says "$currentUser" == "$currentUser" and it killed the installer process like clockwork every time I tested the policy. Hacky for sure, but it worked.
Hey all, like many of you we've just run into the same issue. Our techs were letting me know that Sophos was causing our build process to hang a couple of weeks ago. They must have changed something in the installer.
Going to try @isaacnelson's method of killing the process once Sophos is installed in the meantime. Will report back once i've had one of my team test it out. I have a contact at Sophos that i'll reach out to as well.
@galionschools, $currentUser will return the logged in user unless nobody is logged in (meaning the computer is at the login screen), in which case it will return root. [[ ! "$currentUser" == "root" ]] checks to see if the console user is anybody other than root (that's what the "!" in there does).
If someone is logged in, the installer process won't be killed until SophosAgent is up and running. Otherwise, if the console user is root, the installer process will be killed after Sophos Endpoint.app shows up in /Applications. I put that in because if nobody is logged in SophosAgent will never start up so the installer process will never get killed. Does that make sense?
Basically what's happening is this:
If somebody is logged in, wait for the SophoAgent process to exist, then proceed to the end of the script where the installer process will be killed.
Else, if nobody is logged in, wait for /Applications/Sophos Endpoint.app to exist, then proceed to the end of the script where the installer process will be killed.
@mkremic Let us know if you're able to get a response from Sophos. I'd much rather have them fix their installer than rely on a hacky workaround!
Hey @isaacnelson, your hack worked a treat
Specifically I just used these parts in my own script:
# Kill the installer once Sophos is up and running (workaround for bug that causes the installer process to hang even though installation has completed successfully) # Wait until SophosAgent is running before finishing up (checking every 5 seconds) # User logged in if [[ ! "$currentUser" == "root" ]]; then until /usr/bin/pgrep SophosAgent; do /bin/sleep 5; done #Login Window elif [[ "$currentUser" == "root" ]]; then until [[ -e "/Applications/Sophos Endpoint.app" ]]; do /bin/sleep 5; done sleep 10 fi /usr/bin/killall "Sophos Installer"
Looks like all my Sophos contacts have left Sophos, but i'm asking out licensing person if they have any others. If I get a hold of anyone and get any success i'll post here.
I've been using this spreadsheet: https://docs.google.com/spreadsheets/d/1IWrbE8xiau4rU2mtXYji9vSPWDqb56luh0OhD5XS0AM/edit#gid=0 for the most part to get Team IDs. We also have a policy that runs a script 1x/computer to find Team IDs of the popular places kernel extensions get dropped so we can have it handy in policy logs.
Right now we do Sophos, VMWare, Apogee Digital, MOTU Audio, PreSonus Audio, Parallels, VirtualBox, Zoom, HP, Cisco, SoftRAID, Jabra, Epson, ATTO, Wacom, Paragon Software, Accusys, Digidesign, Highpoint-Tech, CalDigit, Areca, and Promise. About half of those were because people were getting approval prompts, the rest we did preemptively.