I’ll be working on updating Lightsail and the AWS packages to 7.0.0 this weekend, which will include the security updates. Two things I need to check on:
Apparently Duplicity and some kinda new S3 bucket-naming hotness don’t always get along; --use-s3-new-style and/or addressing via boto3+s3: have been tossed around, and I want to sort that out.
I need to experiment to see if I can delete a container without damaging patient files on the volume, and document the use of the MANUAL_SETUP flag if so.
I learned that a functioning OpenEMR Standard instance can survive a down, and that this somehow resolved an SSL problem the instance contracted. I recommended the administrator up the instance with MANUAL_SETUP set but on review I’m not sure that was necessary. The administrator ran a Duplicity recovery as I asked but it replaced no files, so we assume the volume remained intact past the container’s downing.
Password reset attempts do not override the password expiration requirements of last_update_password and this caused a lot of frustration for reasons I’m not 100% sure I understand but I’m reporting what seemed to resolve the problem because I can’t recall the last time I saw it mentioned.
You can actually set Let’s Encrypt Docker envvars after initial setup, which is a good thing since you can’t actually know what IP your server is going to get until after the stack launches. Add the DOMAIN and EMAIL envvars to the docker-compose file once you know them (and once your A records match up) and up it to have the container consider them and run Let’s Encrypt before it lets Apache actually crank up properly.
Vocabulary and concept reminders:
openemr/openemr:7.0.0 is an image
<some random string of hexadecimal characters> is a container, which also has a handy name like standard_openemr_1
docker run loads an image and turns it into a container which then starts
docker start and docker stop start and stop containers
docker exec runs a command of your choice (usually a shell) inside a running container
docker-compose downdestroys containers
docker-compose upcreates or recreates containers, optionally with new state (like environmental variables) or new sources (like upgraded images)
exploring a container that’s so busted it can’t start is problematic
docker logs will let you see the container’s stderr/stdout output, which will give hints
On the developer call today, I was asked about virtual machine instances. Right now I’m not preparing any, there never seemed to be even light demand for them, but it’s very little effort to make one on your own. Boot up an Ubuntu 20 iso, make sure it can see the network, and from there it’s literally two commands.
Once the launch is finished OpenEMR will be ready to log in under the default credentials. You can start using it or you can turn the instance off and export it to an OVF for distribution. In this mode you still get Duplicity backups (run daily from a cronjob), but they’ll just be copied somewhere to sit on the host instead of sent to some S3 bucket – you can arrange an rsync on your own terms to somewhere safer (or modify /etc/cron.daily/duplicity-backups to work as you’d prefer).
Nothing stops me from making one if somebody truly needs one produced, but… there’s just not a lot to it. There’s no elaborate build process to bake these, just run the launch, test the login, halt the instance, pick export from the dropdown.