activation-manager errors and spammage

[shm-eboks]

the setup works and deploys succesfully - however the activationmanager seems to have an issue with your script

[acsoric]

Although the entire log is not visible, it seems that, due to some network restriction, the activation-manager container could not instal curl and jq and therefore it cannot continue normally.
We'll update the chart in a future release to use a custom container for the activation manager with all the logic built-in, instead of having a generic one that required additional dependencies.

[shm-eboks]

odd, - if i kubectl exec into the activation manager and add the jq + curl ~ "apk add curl jq"

then the error does indeed go away

and then to verify that the deactivation manager works, i delete the pod

that doesn't really look good tho.

[shm-eboks]

ah, changing https to http - let it run through its termination with reported "success" in your deactivation script

curl -H "apikey: $APIKEY" -X POST "https://localhost:$REST_PORT/admin/license/deactivation"
curl -X GET "https://$ACTIVATION_SERVER/deactivation?key=$LICENSE_KEY&deployment=$DEPLOYMENT"

[shm-eboks]

changed your startup script to the following, and that works on our system k8s 1.20 (eks)

• changed https to http
• added startup echo
• added sleep (to wait for whatever k8s resources is not available at startup that cause the dns/internet/egress lookups to fail
• added a apk update...

        - |
          echo 'Starting activation manager, waiting 20sec for interfaces to be up'
          sleep 20
          apk update && apk add curl jq
          stop() {
            echo 'Deactivating using the MD Core API'
            curl -H "apikey: $APIKEY" -X POST "http://localhost:$REST_PORT/admin/license/deactivation"
            echo 'Deactivating using activation server API'
            curl -X GET "http://$ACTIVATION_SERVER/deactivation?key=$LICENSE_KEY&deployment=$DEPLOYMENT"
            exit 0
          }
          trap stop SIGTERM SIGINT SIGQUIT

          until [ -n $DEPLOYMENT ] && [ $DEPLOYMENT != null ]; do
              echo 'Checking...'
              export DEPLOYMENT=$(curl --silent -H "apikey: $APIKEY" "http://localhost:$REST_PORT/admin/license" | jq -r '.deployment')
              echo "Deployment ID: $DEPLOYMENT"
              sleep 1
          done
          echo "Waiting for termination signal..."
          while true; do sleep 1; done
          echo "MD Core pod finished, exiting"
          exit 0```

[shm-eboks]

also this whole approach seems prone to error, since you dont really know what kubernetes will kill when a pod is recycled/killed.

i would recommend looking into lifecycle hooks https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/
for your deactivation setup. - especially the "prestop" event

[acsoric]

Actually our initial approach was with lifecycle hooks but we noticed that the "PreStop" hook did not meet all requirements for proper deactivation. For example, the hook would not fire when manually restarting or scaling a deployment, which would leave unused deployment ids still activated.

We'll continue to improve the activation/deactivation logic until we have a "metering" based license system which will make this process unnecessary .

[shm-eboks]

oh alright, yeah that would be an issue, odd k8s doesn't handle this case...
well - true - looking very much forward to your metering approach !

[erhan-]

Hello,

is there any progress on the metering type of licensing or does this sidecar work properly now? We have very big production issues when licenses get deactivated and files not processed.

[acsoric]

I've checked with the dev team for the metering feature and it's not going to be released soon. As a result, we've refactored the activation manager container and published a dedicated image that can be imported and used offline if needed. The changes are available in the latest release.

[erhan-]

I wrote my own license manager which monitors the state of the licenses on all cores and automatically deactivates / activates them. Not sure how we were able to use metadefender in production for so long. Looks like we were just lucky that the pods were not created on different nodes regularly.

I am not sure if I will be ever able to release it because its not my private project but done during company time.

The principle is basic, use the API to check license, upload license. Use the opswat api to deactivate and activate license/download license file. Didnt take too long to implement and it just runs as pod beside our deployment.
Not sure what to think about this whole situation but I should have never been in this situation right now.