- Mar 12, 2020
-
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
-
- Mar 11, 2020
-
-
McConahy, Renee Margaret authored
This is not worthy of production, but I found it useful for monitoring certain things while I developed this project.
-
McConahy, Renee Margaret authored
I found this to be most useful when I was trying to find things in the LOCKSS codebase.
-
McConahy, Renee Margaret authored
Docker forbids updating configurations and secrets: to replace one, one must either create the replacement with a new name or delete and recreate the configuration or secret, which requires stopping any containers that use it. This change modifies the Docker Stack deployment to give each configuration a name derived from a hash of its contents. This allows running stacks to be updated while preserving idempotency. This also changes some tasks to prevent them from unnecessarily reporting changed status, making this role idempotent.
-
McConahy, Renee Margaret authored
This moves most of the code into a standalone (at least in principle) "http_frontend" role and invokes it from the main LOCKSS role.
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
This creates a service that listens on (by default) port 80 and maps LOCKSS's many Web interfaces, each listening on a different port, to paths under a single base. For example: http://lockss.test/crawler -> http://lockss.test:24631 This is not ready for production. The remaining tasks are as follows: - Turn the front-end into a proper Docker image and service. (It should include a health check.) - Merge the lockss-config-frontend into the main lockss role. - Remove from the firewall rules access to the other administrative ports that are now accessed through this. - Document the front-end paths. Or, better yet, write a landing page that lists them all.
-
McConahy, Renee Margaret authored
Among other things, this version uses Docker's host-based networking rather than the ingress network. This simplifies the networking setup, but I'm leaving ferm in place because it is easier to configure than ufw or firewalld, and we may need to switch back again.
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
-
- Mar 03, 2020
-
-
McConahy, Renee Margaret authored
This caused a problem with the LOCKSS 2.0-alpha2 configuration, where LOCKSS_ACCESS_SUBNET used semicolons to separate values, but it should be done generally.
-
McConahy, Renee Margaret authored
See IEEE, POSIX.1-2017—Base Definitions § 3.206.
-
- Feb 28, 2020
-
-
McConahy, Renee Margaret authored
-
- Feb 27, 2020
-
-
McConahy, Renee Margaret authored
-
- Feb 12, 2020
-
-
McConahy, Renee Margaret authored
It's too slow to be worthwhile.
-
McConahy, Renee Margaret authored
This skips several tasks that fail, at least in some conditions, when run in check mode but not when run in normal mode.
-
McConahy, Renee Margaret authored
As I noted in an earlier commit, restricting Docker's ingress traffic is more complicated than adding a few rules to the filter table's INPUT chain. I had thought that relying on LOCKSS's "LOCKSS_ACCESS_SUBNET" variable would be sufficient; unfortunately, that is not the case: LOCKSS sees all of its traffic as coming from the Docker overlay network (by default, 10.0.0.0/8), regardless of its true origin. Fortunately for us, Docker provides us with a chain, DOCKER-USER, called by Docker's rules from the FORWARD chain in the filter table, that is suitable for filtering Docker's ingress traffic. Accordingly, this commit: - Removes the misleadingly ineffective 'lockss_trusted_ips' variable and provides new variables 'lockss_network_ips' and 'lockss_admin_ips'. - Replaces ufw or firewalld with ferm. Neither ufw nor firewalld is capable of satisfying this use case without employing significant violence; ferm is elegant and has beautiful configuration files. Beauty over bloodshed. - Adds tasks to configure a local firewall that denies inbound and forwarded traffic by default, permits ssh from anywhere, and permits access to LOCKSS's data and configuration ports from 'lockss_network_ips' and 'lockss_admin_ips' respectively. Said firewall cooperates with Docker: Docker and the firewall can be started in any order, and restarting either preserves rules created by the other. * * * I got the suggestion of using ferm for this, as well as the bulk of the Docker-related rules, from a blog post: Ben Chavet, Convincing Docker and Iptables to Play Nicely, Aug. 8, 2019, <https://www.lullabot.com/articles/convincing-docker-and-iptables-play-nicely>.
-
McConahy, Renee Margaret authored
This reduces the time and space required to spin up a new VM.
-
McConahy, Renee Margaret authored
I see little risk in using known passwords here, but it's such a bad practice that I'd rather avoid it entirely. (The worst case I can imagine is that a malicious process running on the developer's workstation would be able to manipulate the configuration.)
-
McConahy, Renee Margaret authored
Docker secrets cannot be changed (at least through the Ansible module) while their are in use. This breaks idempotency.
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
Ordinary firewall filtering rules, placed in iptables's "INPUT" chain in the "filter" table, aren't applied to Docker's ingress traffic, which is redirected ("NATted") to Docker's interface by the "PREROUTING" chain in the "nat" table. Hence, the rules pretending to allow LOCKSS management traffic from trusted hosts are superfluous and misleading: traffic to those ports is instead restricted by LOCKSS according to its "LOCKSS_ACCESS_SUBNET" variable. I could write rules to filter Docker's ingress traffic, but I would rather not take the time--I would need to take care that they were always given priority over Docker's rules, even when Docker were restarted--and LOCKSS's own handling of matters ought to be sufficient for now. With that, the base firewall rules (enabling a default-deny ingress policy with an exception for ssh) seem out of scope for this role.
-
McConahy, Renee Margaret authored
- Vagrantfile: Correct the path to the parsed YAML file. (This caused 'vagrant global-status' to fail when called from outside the project's directory.) - Vagrantfile: As we do not use it, disable the default sharing of the project's directory with the VMs. - lockss: Use /tmp as temporary directory. - Other trivialities.
-
- Feb 11, 2020
-
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
-
- Jan 28, 2020
-
-
McConahy, Renee Margaret authored
-
- Jan 24, 2020
-
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
-
McConahy, Renee Margaret authored
When it already exists, the swap file managed by the role must be excluded from the sum of memory and swap used to calculate the size of said file. The size of the swap file's header ought to be included in the calculation; otherwise, the file will be slightly undersized, and the role will re-create it at every invocation.
-
McConahy, Renee Margaret authored
-
- Jan 17, 2020
-
-
McConahy, Renee Margaret authored
-