Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-69822

ClamAV Transaction Socket Timeout

XMLWordPrintable

    • MOODLE_310_STABLE, MOODLE_39_STABLE
    • Hide

      Before the patch

      1. Configure Moodle to connect to a ClamAV server over a TCP Socket.
      2. Set they retry value to 5.
      3. Set the upload failure action to 'actlikevirus'.
      4. Upload a large Zip file or MBZ. This will need to be something that the AV scanner can chew on for a while so I recommend something with several small files in the ZIP or a course backup with thousands of items.
      5. On the ClamAV server, you can monitor the scanning process with the following command:
        watch -n .1 "echo nSTATS | nc localhost 3310"
      6. Once the scanning time passes 60 seconds, Moodle will upload another copy of the file and the antivirus scanner will start scanning that file, increasing CPU load.
      7. Rinse and repeat until the file can finally be uploaded.

      After the patch

      1. Configure Moodle to connect to a ClamAV server over a TCP Socket.
      2. Set they retry value to 5.
      3. Set the upload failure action to 'actlikevirus'.
      4. Restart the ClamAV server to ensure results are not cached from the previous attempts.
      5. Upload the file with the default timeout of 180 seconds. See if this additional two minutes has given ClamAV enough time to clear the file without hitting the retry loop on failure.
      6. Increase the timeout value for the site and try again if the file is uploaded again due to timing out from the scan upload.
      7. Adjust the time in the ClamAV plugin settings page to a larger value in the event that a retry is executed. Repeat this process until the file is cleared by the ClamAV server in one pass.
      Show
      Before the patch Configure Moodle to connect to a ClamAV server over a TCP Socket. Set they retry value to 5. Set the upload failure action to 'actlikevirus'. Upload a large Zip file or MBZ. This will need to be something that the AV scanner can chew on for a while so I recommend something with several small files in the ZIP or a course backup with thousands of items. On the ClamAV server, you can monitor the scanning process with the following command: watch -n .1 "echo nSTATS | nc localhost 3310" Once the scanning time passes 60 seconds, Moodle will upload another copy of the file and the antivirus scanner will start scanning that file, increasing CPU load. Rinse and repeat until the file can finally be uploaded. After the patch Configure Moodle to connect to a ClamAV server over a TCP Socket. Set they retry value to 5. Set the upload failure action to 'actlikevirus'. Restart the ClamAV server to ensure results are not cached from the previous attempts. Upload the file with the default timeout of 180 seconds. See if this additional two minutes has given ClamAV enough time to clear the file without hitting the retry loop on failure. Increase the timeout value for the site and try again if the file is uploaded again due to timing out from the scan upload. Adjust the time in the ClamAV plugin settings page to a larger value in the event that a retry is executed. Repeat this process until the file is cleared by the ClamAV server in one pass.

      With the latest addition of direct TCP connections to a ClamAV server, Moodle is now configured to perform a stream_get_line() call once the file has been fully submitted to a ClamAV server for scanning feedback of the file. In almost all cases this is fine since a majority of files we've seen are relatively small and take a small amount of time to process through the ClamAV server. However, as customer's are performing course restores through MBZ uploads or new large content uploads at the beginning of the semester, we've seen on numerous occasions the following scenario.

      1. The Moodle site is configured to talk to remote ClamAV server via TCP connection configured in Moodle with 5 retry attempts.
      2. An administrator uploads a large course MBZ backup that takes longer than 60 seconds for the ClamAV server to process and clear for upload.
      3. Once the file is uploaded to the ClamAV server, the stream_get_line() function is called and by default waits for 60 sends before returning false with no response from ClamAV.
      4. The file is then re-uploaded due to the retry event configuration which now starts compounding CPU utilization on the ClamAV server as the first file hasn't been cleared or cached.
      5. This keeps reiterating and compounding load on the server until retry attempts have run out.
      6. The administrator must wait enough time (unknown) for a file to be cleared so when the upload attempt is tried again, the administrator is hopefully able to connect to a ClamAV server that has the file's MD5 hash cached in memory and the file can be instantly cleared.

      So this becomes less than ideal as ClamAV solutions part of a dynamic scaling group will be added to the pool based on scaling rules around CPU, Load, or Concurrent connections costing money that didn't need to be spent, and creates a poor user experience for an administrator due to the lack of transparency that is happening on the back end along with needing several attempts to successfully upload a file.

      This code fix adds an $CFG value that allows a site administrator the ability to define the timeout on stream_get_line() to allow the ClamAV server more time to scan the file prior to a retry attempt executing.

            inkjet2000 Justin Merrill
            inkjet2000 Justin Merrill
            Tim Hunt Tim Hunt
            Votes:
            7 Vote for this issue
            Watchers:
            10 Start watching this issue

              Created:
              Updated:

                Error rendering 'clockify-timesheets-time-tracking-reports:timer-sidebar'. Please contact your Jira administrators.