Sunday, January 24, 2021

Upgrading my Wiki

My last post mentioned that my wiki was down. Well in the process of troubleshooting the issue I discovered a bunch of things that I didn't know. It's good to learn right?

So there are a couple of things that I discovered during this process the first of which is that Python2 reached end of life support January 2020. I knew that MoinMoin used python 2 but I hadn't realized that python2 is no longer supported at all. In addition PIP, the python package installer announced what yesterday that it no longer supported python2, so you can install it via method. And so the more I thought about it the more I realized that I definitely didn't want to be running my wiki on outdated software particularly if a security vulnerability in python2 was discovered.

So I did a little digging and the Moinmoin site is misleading. The Roadmap and discussion on Moin2 are misleading. On those pages it seems that the next version of Moin, moin2 would be available and then the project would work on python3 support. Well moin2 isn't even released as an "alpha" yet. So of course I started down the path of thinking that maybe I'd have to use another wiki tool. I've tried django-wiki but wasn't impressed with it, it felt too much like a CMS and not the natural flow and ease of a wiki. To be fair I didn't look that closely so I could be wrong. But that's where I was at.

I then started looking at github for moin2 and the lead me to moin-20.readthedocs.io where the most up to date info is. From this I gathered that moin2 does support python3 which was quite a relief because it was hard to believe they would be so far behind. While I couldn't use PIP to install moin2 I was able to clone the repository and configure the developer server and run it. So I was able to use lynx to hit localhost on port 8080 and bingo a wiki! I was able to register a username and password and add words to the page. At that point I was sure that at least to that level it was working. So I'll give it a shot, I just need to figure out how to deploy it.

Actually the orginal cause to the outage was probably due to the fact that I was adding Django to the same server. Django however uses python 3 naturally. Both moin and django use uwsgi to connect with nginx web server. But first time I installed uwgsgi I built it with python2, the second time python3. I, of course didn't realize this until trying to troubleshoot. Which led to the realization mentioned above. In a previous lifetime I used FastCGI but that was deprecated in django 1.7 and removed in 1.9. We are now at django 3.1 or something. It took me a while to wrap my head around this but here are the basics as I understand them. Feel free to correct my in the comments.

Your app or website is written in say django, which has combination of code, design "stuff", and database. All these combine to create a website or the combination of apps, say a blog, or photo album are combined together in a site. You can check out the sheer volume of django packages here: https://djangopackages.org/.

There are a couple of critical files it appears - the .service file, the .wsgi or .py file and finally the nginx config file for that website/app. The .service file is to start uwsgi which kicks off the app the configuration of which is located in the .wsgi or .py file. The nginx config tells the web server what the name of the server is, ex. wiki.neohawk.org, what root of the site is and where to connecto to uwsgi. The connection from the web server to the app can be through the built in uwsgi "web server" on local host (127.0.0.1) on a specified port say 8000. Or the connection can be to a unix socket file. I am guessing based on my reading that the socket file is the better way to go, I'm guessing because there is less "http" traffic. But that is a wild ass guess.

So I got this far, the next step I'm trying to get to is deploying multiple apps using uwsgi and that looks like I have two options. One is to create a virtualenv for each of my apps/websites installing uwsgi for each, and starting each separately. The other option seems to use "Emperor" and "Vassals" where the emperor is the master uwsgi service and the vassal represent the unique, specific apps. Like I said I'm not quite there yet though.

No comments:

Post a Comment