add service files for systemd

[munroebot]

I already have this stuff in the service directory. You just need to copy *.example to membership.service and fill out the details

[mrjones-plip]

ah - gotcha! thanks for the tip!

You cool with just customizing these to be exact? I'm thinking:

• change paths to be what they'll be on prod
• move Environment="ENCRYPTION_KEY=ChangeMe" out of .service file into another one (config.py?)
• make one for dev and one for prod

That way we just copy in place and we're done.

Also, do we need the shell script? Shouldn't we be able to put it all in the .service file or in config.py? I only ask because the less we have to customize per install the better. Also, there's no activate file in the repo which the shell script references.

[munroebot]

I was currently not planning to track any environment configurations in Github, my thinking was that the *.example and *.default files would give you enough of a starting point and whoever is setting up said environment can figure out the details.

The Environment="ENCRYPTION_KEY=ChangeMe" is the decryption key for all the encrypted properties in config.py, so putting it config.py sort of defeats the purpose? We can bury the variable somewhere else if you'd like (or put it in the .bashrc of the membership user or something) - but I think the *.service file is normally only readable by root anyways? Also, we definitely don't want *.service checked into Github if that is kept in there.

As far as having the gunicorn.sh script, I don't know that much about how virtualenv work non-interactively and I barely understand *.service files, so that's why I separated things out. Also, in your PR, you're launching the Flask dev / debugger WSGI container (Werkzeug) and not the production Gunicorn WSGI container.

[mrjones-plip]

The Environment="ENCRYPTION_KEY=ChangeMe" is the decryption key for all the encrypted properties in config.py, so putting it config.py sort of defeats the purpose?

Ah - gotcha! Totally makes sense to keep that as owned by root - I'm with ya!

As far as having the gunicorn.sh script, I don't know that much about how virtualenv work non-interactively and I barely understand *.service files, so that's why I separated things out.

Ah, per #8 , we jusst need specify deep paths! So for example, I've set up virtenvs for dev. Check out when I try start the script with the base python (note I'm in ~/membership-dev.synshop.org):

membership@new-lagos:~/membership-dev.synshop.org$ python3 ./server.py 
Traceback (most recent call last):
  File "/home/membership/membership-dev.synshop.org/./server.py", line 5, in <module>
    from authlib.integrations.flask_client import OAuth
ModuleNotFoundError: No module named 'authlib'

As expected, none of the stuff I installed with pip3 install -r requirements.txt in the virtenv is there. But now check out if I specify the python binary in the virtenv! (still in ~/membership-dev.synshop.org)

membership@new-lagos:~/membership-dev.synshop.org$ /home/membership/membership-dev.synshop.org/venv/bin/python3 ./server.py 
Please enter the encryption key to unlock this application: 

Everything just works! And what about the prod install? (now I'm in ~/membership.synshop.org)

membership@new-lagos:~/membership.synshop.org$ /home/membership/membership.synshop.org/venv/bin/python3 ./server.py 
ERROR Missing "config.py" file. See https://github.com/synshop/membership.synshop.org for info

This is because the configy.py is missing variables, so it can't start, but otherwise everything is there. So all we need to is set the working directory with WorkingDirectory in the system file and it should all work.

I think that covers everything in your bash script except the port and the activate script:

cd /home/ubuntu/membership.synshop.org
source /home/ubuntu/membership.synshop.org/activate;
gunicorn --bind [::]:8000 --log-file /tmp/gunicorn.log --pid /tmp/gunicorn.pid server:app

Lemme dork around with the PR and some tests here...

[mrjones-plip]

OK! The two files in this PR are working on production, so I know they work. Given we can decrease complexity by removing the bash file, and you have to edit the service files any way after you copy them, my advice is to go with what's in this PR.

Steps to install have been updated here.

[mrjones-plip]

Thank you for explaining how the virtualenv setup could be simplified. While I don't agree with your approach because I think you are complicating the membership.service file and mixing in application configuration that should be kept with the application, I'll let you have it because I don't care that much.

Cools - thanks! That said, if you still think we should move the port (and log and pid files?) to a config file, I did read up that gunicorn supports config files, so we could pursue that.

Are you planning to check the membership.service file into GitHub and then copy it over to the correct location for systemd?

Correct, that's what this PR does and what the docs specify (see step #15).

You don't think my approach of having a membership.service.default is a good idea? My thinking is that I don't want membership.service accidentally getting checked into GitHub but I still want a reference, so that's why I have the default template.

I wasn't sure why you were concerned about having membership.service in the repo, but not concerned about membership.service.example - can you explain the difference? In both cases you need to copy the file some where. My thinking was that you want as few steps as possible when setting up production with the least amount of complexity. Thus, having the literal production ready service file was optimal, and then you could tweak it for another deployment (like dev) if you wanted. I imagine a future volunteer struggling with this when we're not around and being thankful it's a simple cp and they're done.

And thanks for documenting everything

your welcome!

even though you're basically giving hackers a howto on finding the decryption key.

Oh no! I'm really sorry if I made you upset by my actions. I've removed the public info on the encryption info and put it in the service file. We can address the publicizing it later if we choose to open source this repo.

BUT, I am trying to do my best to keep env configuration out of the Git repo, so please don't check a membership-dev.service file into GH.

Done! removed in aad135f

[mrjones-plip]

thanks for the approval & merge!

saw I forgot to address this:

Finally. What are your thoughts on renaming the branches back to devo and prod vs how I have them now?

don't feel too strongly about it, but do like how the branch name matches the directory name on lagos matches the URL. A nice trifecta of unambiguous names! Oh - so maybe membership-dev.synshop.org -> membership.synshop.net ? (but if I'm honest with myself, I think i'd prefer membership-dev.synshop.net there to remove any ambiguity, but... :shrug: )