Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 1 subscriber
  • Views 2615 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

Corporate layer setup failure on Linux SAV version 7.x.x, please help

Kuba

Hi,

Foreword:

I am using Sophos Antivirus for Linux in the CID-based configuration, formerly known as corporate configuration. An Enterprise console, i.e. a Windoz computer, is not required.

The CID directory (on Linux server) is read-only shared across a local network with NFS and it is used as a primary update source on the Linux clients. The server OS is Ubuntu 8.04.4 LTS (server), while all clients use the same distribution for client. The entire configuration was working perfectly till the version 6.

Malfunction:

With the automatic passage to version 7, the following problems appear:

1) The NFS CID directory became inaccessible to the clients, while perfectly exported on server and mounted on clients.

2) The Corporate layer settings disappear on the server and the command addcfg.sh, to copy the off-line configuration to the live configuration, doesn't work any more. The attempt to re-create the off-line configuration file doesn't change the situation, the check command:

/opt/sophos-av/bin/savconfig --corporate query

generates an empty output again.

Analysis:

The problem 1) appears due to root changed permissions on CID directory for version 7. Normally, on the Linux servers, the NFS export use sc. 'root squashing', to avoid clients root to be treated as root when accessing files on the NFS server, see exports(5). This standard mechanism prevents the CID access by the client root processes. The solution is to disable the 'root squashing' by adding the "no_root_squash" option to the export command:

/opt/sophos-av/update/cache/Primary *(ro,sync,no_root_squash,no_subtree_check)

in the /etc/fstab file.

I am astonished that no news about this can be found on the support section of the Sophos site :smileysurprised:

The problem 2) appears due to absence for version 7 of the CID live configuration file:

/opt/sophos-av/update/cache/Primary/config/CorporateLayer.cfg

still needed for the addcfg.sh script. It seems that the following directory:

/opt/sophos-av/update/cache/Primary/config

is not included in the installation path any more; if you try to manually create it, then, at the following update (from the Sophos site) it will be automatically removed :smileysurprised:

In this way, I am not allowed to propagate the corporate layer setting to the attached Linux clients :smileysad:

Question:

Could anyone help me to solve the problem 2) ? :smileyhappy:

Thanks,

Kuba

P.S.

Final question about the Sophos commercial policy. In Italy the legal private users (i.e. without a VAT number) have limited access to the Sophos support, does this happen also in other countries?

:3572


This thread was automatically locked due to age.
  • 0

    1) You shouldn't be sharing out the Local Cache Directory (LCD) directly - it's designed to be private to the Sophos Anti-Virus install on the machine. Instead you should copy the LCD to another directory and share that out, and after the copy you can ensure that the permissions are set so they can access it. The copying also allows a work around for 2)

    2) This appears to be a regression against SAV6, so I've raised a tracking item against it. But the best work-around solution would be to copy the LCD and copy in the config directory into the exported copy.

    Maybe a script like this one:
    #!/bin/bash

INST="$1"
CID="$2"
CONFIG="$3"
TBP="$4"

failure()
{
    echo "$@"
    exit 1
}

[ -n "$INST" ] || failure "No installation dir specified"
[ -n "$CID" ] || failure "No CID location specified"
[ -d "$INST" ] || failure "Installation doesn't exist"

$INST/bin/savupdate -v1 || failure "Failed to update SAV"

PrimaryCacheDir=$($INST/bin/savconfig query PrimaryUpdateCachePath)
[ -n "$PrimaryCacheDir" ] || failure "Can't read PrimaryUpdateCachePath"
[ -d "$PrimaryCacheDir" ] || failure "Primary cache dir doesn't exist"

rm -rf ${CID}.new
cp -a $PrimaryCacheDir ${CID}.new

if [ -n "$CONFIG" ] ; then
    [ -f "$CONFIG" ] && ${CID}.new/addcfg.sh -f$CONFIG
    [ -d "$CONFIG" ] && cp -a "$CONFIG" ${CID}.new/config
else
    [ -d ${CID}/config ] && cp -a ${CID}/config ${CID}.new/
fi

if [ -n "$TBP" ] ; then
    [ -d "$TBP" ] && cp -a "$TBP" ${CID}.new/talpa-custom
else
    [ -d ${CID}/talpa-custom ] && cp -a ${CID}/talpa-custom ${CID}.new/
fi

mv ${CID} ${CID}.old
mv ${CID}.new ${CID}
rm -rf ${CID}.old

echo "Successfully updated ${CID}"
exit 0
    :3576
  • 0

    Thanks for your quick answer :smileyhappy:

    Your solution (or work around) sounds good but I have some doubts:

    1) If I decide to copy the LCD directory somewhere else, let's say, to Exported Cache Directory (ECD), then I have to manage the automatic periodic update of the LCD and so also updating periodically the ECD. How can I do it automatically ? In other words, how can I continue to hold synchronization between the original directory (LCD) and its copy (ECD) ? Any suggestion ?

    2) What about the added config directory only in the ECD directory ? Please take it into account, when you indicate the possible synchronization methods.

    Thanks again,

    Kuba

    :3631
  • 0

    1) I would suggest cron, probably scheduled about once per hour? The savupdate call will ensure the LCD is updated just before we do the copy operation.

    2) The third argument to the script can be a CID config file, which will be added the the ECD, each time it is copied.

    :3643
  • 0

    Hi, Sandy

    Sorry, my question was not precise. Let me explain the issue better. I am a private person (i.e. without a VAT number) who uses a Sophos license for private purposes, after buying it from the local Sophos reseller. The reseller is a third company that doesn't offer any support for Linux (as far as I know, they provide some kind of limited support only for Mac and Windoz). The site I use to download the updates is owned by another company having some specific agreements with Sophos and the reseller. In fact, I received the account and password to access the update site from the reseller. As a consequence of this situation, I am not informed about my license number (do I have it ?) so I cannot request the support directly from Sophos Italy.

    The correct question, at this point, should be: is this situation typical for the Sophos policy also in other countries ?

    Thanks again,

    Kuba

    :3668
Unfiltered HTML