Jan VarhoI found it surprisingly difficult to find a plain explanation of setting up hug and apache mod_wsgi. So here is how I did it.
Writing an API with hug is really easy. You can write a "hello world" in four lines of code:
import hug
@hug.get('/hello') def hello(name: str) -> str: return "Hello " + name
Running this on a devserver is also trivial:
hug -f hello.py
Setting up mod_wsgi is not too difficult either. You need to install the module and enable it, which on Ubuntu was as easy as:
sudo apt install libapache2-mod-wsgi-py3
Note the 'py3' part, however. I wasted quite a bit of time before realizing the module uses a specific version of Python. Since hug is Python 3 only (a shame), a Python 3 build is needed.
The actual host configuration looks something like:
<VirtualHost *:80> ServerName hello.example.com DocumentRoot /var/www/hello/ WSGIDaemonProcess hello threads=1 WSGIScriptAlias / /var/www/api/hello.py
<Directory /var/www/hello> WSGIProcessGroup hello WSGIApplicationGroup %{GLOBAL} Order deny,allow Allow from all </Directory> </VirtualHost>
(This is on Ubuntu 16.04 with Apache 2.4.18, running it as the Apache user.)
The WSGI entry point expected by mod_wsgi is named 'application' while hug exposes one under 'hug_wsgi'. There must be some way to change it from the above configuration (how?), but I ended up adding this to hello.py:
application = hug_wsgi
If the application was installed as a package it would be cleaner to have some kind of a separate shi like wsgi.py with just a oneliner:
from mypackage import hug_wsgi as application
Whenever I want to test a new release of Ubuntu I find myself cloning the root partition so I can safely upgrade and still keep my old install.
However, I usually forget some step and end up needing to debug grub boot. So this is a summary of what needs to be done in order to clone the partition and make it work. (Almost all of the below need to be run as root of course.)
First you need the file systems in question to be unmounted, so likely you will want to boot from a USB stick or some third partition.
dd
--The simplest way to clone the whole FS is to just dd the partition into
another equally sized partition (I keep a few root-sized ones in reserve).
That is, something like:
dd if=/dev/sdd1 of=/dev/sdd2 bs=$((1024102416))
That copies the contents of /dev/sdd1 into /dev/sdd2 with a large enough
block size that you get most out of SSDs.
Since there are now two partitions with the same UUID, you need to rename one. The command depends on the file system in question, but for ext4 it is:
tune2fs -U random /dev/sdd2
Now you can check that the UUID changed and record the values:
blkid
/etc/fstab
--The next step is to update the fstab in the changed filesystem. Mount the FS somewhere and edit the root UUID manually or just use sed:
sed -ie 's/<old_uuid>/<new_uuid/g' ./etc/fstab
Next you can boot into the normal system (which for me is usually the clone's
original copy, i.e. /dev/sdd1 above), chroot into the clone FS (/dev/sdd2)
and update grub from there. Go into the root of the clone and run:
mount --bind /dev ./dev mount --bind /proc ./proc mount --bind /sys ./sys chroot . update-grub
Finally, run update-grub outside the chroot, in whichever install owns
the default drive's grub.
After my old WordPress setup broke one time too many I finally decided to convert the site to something nicer to work with. I ended up going with Pelican, which is a static site generator using Python.
It seems quite basic at first, though I'm sure there are features waiting to be discovered. The main advantage is that I no longer need to worry about software updates when not actually changing the site. Another is that practically any hosting setup works painlessly.
I tried to fix up all intra site links, but others are hopelessly broken, so you may have been directed to this page instead of what you were looking for. Sorry!
Github link: pylibscrypt v1.5.3
Github link: pylibscrypt v1.5.2