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

Updating Policy is not working for Linux

Hi,

I have been searching for an answer on this for about an hour, but am guessing someone will respond with a link to the KB on this.

I installed the endpoint agent on an Ubuntu Linux system.  I can see the system in the console, but it is showing not up to date since the install time.

It has an update policy assigned to its group specifying both the primary and secondary update servers.  When changes are made to this policy I see its policy compliance change to "awaiting transfer" and the changing back to "same as policy".  

When I check the computer details from the console I see it does not have a primary or secondary update server configured.  

The savupdate-debug.log is filled with these:

2020-06-27 12:24:57,677 DEBUG savupdate.util.Logger: NO-UPDATE-CONFIGURATION
2020-06-27 12:34:57,229 DEBUG savupdate.util.Logger: Logging to /opt/sophos-av/log/savupdate-debug.log

Am I doing something wrong with the update policy, or is it normal that I should need to configure this on each agent although they report back to the console?

I have verified DNS resolution to the server hosting the updates works and am using the fqdn in the update path.

Thank you



This thread was automatically locked due to age.
Parents
  • Hello provisional Identity,

    apparently you installed from a CID so it's supposed to work.

    What are the Primary and Secondary locations in the policy? Are other endpoints in the same group?
    You choose a subscription in the policy - is Linux selected in this subscription?

    Christian

  • Hi Christian,

    This is what is specified as the primary update server in the policy:

    \\[ServerFQDN]\SophosUpdate

    Secondary:

    Someone has just put "Sophos" here.  I unchecked the box to set a secondary server to verify if that was causing the configuration to fail.  It has that value on the Windows servers and they are taking the policy.  I see you provided a list of updated servers per another persons issue here: https://community.sophos.com/kb/en-us/111428

    Supposedly Linux agents were already configured at some point in the past and were working.  There were none reporting to the console yesterday until I installed this agent.  I would rather figure out how to get it to work before installing on everything else.

    The Linux servers group has its own policy and it is applied to the group.  This is the only member of that group.

    Does it matter the format of the username.  I have tried domain\username and username@domain.  I do not think this would impact the policy not specifying an update server.  I did not install this server, so cannot guarantee things are configured in a way that makes sense.  I do know the install files I used from savlinux were from yesterday (at least had that last modified timestamp).  I also verified the share has appropriate permissions.  There must be something taking place at a much lower level though in order to explain it not even knowing which server it should get updates from.

    Thank you

Reply
  • Hi Christian,

    This is what is specified as the primary update server in the policy:

    \\[ServerFQDN]\SophosUpdate

    Secondary:

    Someone has just put "Sophos" here.  I unchecked the box to set a secondary server to verify if that was causing the configuration to fail.  It has that value on the Windows servers and they are taking the policy.  I see you provided a list of updated servers per another persons issue here: https://community.sophos.com/kb/en-us/111428

    Supposedly Linux agents were already configured at some point in the past and were working.  There were none reporting to the console yesterday until I installed this agent.  I would rather figure out how to get it to work before installing on everything else.

    The Linux servers group has its own policy and it is applied to the group.  This is the only member of that group.

    Does it matter the format of the username.  I have tried domain\username and username@domain.  I do not think this would impact the policy not specifying an update server.  I did not install this server, so cannot guarantee things are configured in a way that makes sense.  I do know the install files I used from savlinux were from yesterday (at least had that last modified timestamp).  I also verified the share has appropriate permissions.  There must be something taking place at a much lower level though in order to explain it not even knowing which server it should get updates from.

    Thank you

Children
  • Hello provisional Identity,

    like the miller's daughter did to Rumpelstiltskin I'll  first keep you in suspense.

    "Sophos" as Secondary
    is fine and doesn't cause any problems (if the credentials, that are the same as in the Update Manager configuration, are correct). It definitely doesn't cause a NO-UPDATE-CONFIGURATION.

    until I installed this agent
    how did you go about it? You must have installed from some CID, a path ending in \Snnn\savlinux\, otherwise the endpoint would not report to and fetch policies from the server. What was the value for Snnn - the default Recommended subscription has S000. Do you have more than one Software Subscription in the Update managers view?
     

    Coincidentally I noticed this behaviour (the NO-UPDATE-CONFIGURATION) for the first time just the other day. Brought my laptop, that is most of the time at home, with me. At work it should update via UNC, this failing it should fall back to the Secondary web CID. This has worked for weeks. Well, it did not update and suddenly Primary and Secondary were gone in the details. Huh? 

    Turned out I has assigned an alternate updating policy to its group.

    As you can see it does not contain Linux. Looking at the Subscription in the Update managers view showed that indeed Linux wasn't selected.

    What happens is the following: When SEC builds an updating policy it creates an XML with settings for all platforms. For platforms that are not selected in the chosen Subscription the updating paths are empty though and consequently the endpoint has effectively no configuration.
    Interestingly SEC does not warn you if you assign a policy/subscription to a group containing an endpoint with an "unselected" platform, or move the endpoint to a group with such a policy. SEC does refuse to change a Subscription when you try to unselect a platform from it and this Subscription is chosen in policies assigned to groups containing endpoints that would be affected. 

    I hope you can sort it out with this information.

    Christian

  • Wow, you saved me again.  That was the issue.  I went to the "subscriptions" tab and changed it to "Linux".  The policy updated and I sent the update command and everything is good.

    Thank you again!