7.1. Known Issues

This page was last updated: 2021-07-07.

  • Security

    • In the "alpha" phase of development of LOCKSS 2.0, there are no access controls on Kubernetes' API. It is not accessible from outside the machine, but any local user can access the API, so they can stop the LOCKSS containers, change their contents, read secrets, etc. We plan to enable access controls in the "beta" phase.

    • In the Classic LOCKSS system (1.x), the LCAP SSL key could only be read by root, but now it can also be read by lockss.

  • DNS Resolution

    K3s' default DNS cache timeout is 30 seconds, which results in enough repetitive upstream queries to trigger alarms at some institutions. One remediation is to change the CoreDNS configuration by editing its configmap.

    With K3s, changes made to CoreDNS's configmap with kubectl apply do not persist, because the configmap is constantly reloaded from /var/lib/rancher/k3s/server/manifests/coredns.yaml. Additionally, K3s overwrites the file with the defaults at startup, so changes there are not really persistent either.

    The LOCKSS Installer offers the script scripts/coredns-cron-hack, which sets the CoreDNS cache timeout to 30 minutes. It should be run once, as root, after each time K3s starts. Absent a good way to do that, it is harmless to run it periodically from root's crontab. The recommended use is to copy it to a root-owned file in /etc/cron.hourly.

  • Harmless PID File Errors

    The stdout log files of the various LOCKSS service containers contain the following error messages at startup:

    /usr/local/bin/docker-entrypoint: line 374: can't create /var/run/docker-entrypoint.pid: Permission denied
    

    This is harmless and will be addressed in the next release of the system.