-- Leo's gemini proxy

-- Connecting to bbs.geminispace.org:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini; charset=utf-8

Setting up myTinyTodo on my VPS


Introduction


I enjoy making TODO-lists quite a lot. They've been a helpful way for me to collect my thoughts and manage my time. Lately I've been working on a gemini client app that's been getting steadily more complex (as these things often do). The project has gotten to the point that each time I step away from it I find myself struggling to pick up where I last left off.


Yesterday I came to the conclusion that if I want to continue working on this project in the long-term, I will need to find a better way to manage in-process tasks.


I often use a paper TODO-list for this kind of thing, but lately I've been trying to reduce the amount of clutter on my desk. It therefore seemed only reasonable that I search for a digital alternative.


I ended up settling on a self-hostable web service called *myTinyTodo*.


https://mytinytodo.net/


I appreciate its support for markdown and its tagging feature, and I was impressed by how easy it was to set up on my VPS. The whole process took less than ten minutes. I'll detail the steps I took to set it up below.


The developer has installation instructions, which can be found here. There are just four steps.


Prerequisites


For context, I'm running this on a rented 4GB Arch Linux VPS. The setup should be pretty distro-agnostic.


For my particular setup, I made use of the following:

NGINX with the mod_php module enabled (which I *think* is available out-of-the-box on Arch)

A running MariaDB (a.k.a. MySQL) instance

The Let's Encrypt 'Certbot' utility

PHP-FPM, which runs PHP in a FastCGI instance


myTinyTodo supports both SQLite and MySQL database engines. I chose to use MySQL because I have an instance set up already. I might have chosen SQLite if I wanted to run this in an underprivileged or resource-constrained environment where MySQL isn't an option.


Setup


User + Directory


I started by creating a system user account called "mytinytodo". This account will be used for running the FastCGI pools and will own all of the myTinyTodo files.


useradd --system -U -s /usr/bin/nologin mytinytodo

I then downloaded and extracted the myTinyTodo application files to a directory in /srv.


wget https://github.com/maxpozdeev/mytinytodo/releases/download/v1.7.6/mytinytodo-v1.7.6.tar.gz
tar -xf mytinytodo-v1.7.6.tar.gz
cp -r ./mytinytodo /srv/mytinytodo

I can't be bothered to remember the syntax for the 'find' command, so I modify the following script and run it when I need to set directory permissions:


#!/bin/sh

find $1 -mindepth 1 -maxdepth 1 -type d -exec chown -R mytinytodo:mytinytodo {} \;
for repo in $(find . -mindepth 1 -maxdepth 1 -type d);
do
        find $repo -type f -exec chmod 644 {} \;
        find $repo -type d -exec chmod 755 {} \;
done

PHP-FPM Pool


As a security measure, I created a new PHP-FPM application pool which will run as this restricted user account.


I copied the default 'www' pool configuration...


cd /etc/php/php-fpm.d/
cp www.conf mytinytodo.conf

... and changed four lines in mytinytodo.conf to the following:


[mytinytodo]

...

user = mytinytodo
group = mytinytodo

...

listen = /run/php-fpm/mytinytodo.sock

Reverse Proxy


In order to allow myTinyTodo to coexist with the other web apps running on my VPS, I configured a new subdomain with my domain registrar.


I then created a new NGINX config file to pass incoming requests to the FastCGI pools (use your own server_name obviously):


server {
    server_name your.domain.here;
    listen 80;
    index index.php;

    root /srv/mytinytodo;

    location / {
        try_files $uri $uri/ =404;
    }

    error_page 404 /index.php;

    location ~ \.php$ {
        try_files $uri $document_root$fastcgi_script_name =404;

        fastcgi_split_path_info ^(.+\.php)(/.*)$;
        fastcgi_pass unix:/run/php-fpm/mytinytodo.sock;
        fastcgi_index index.php;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include fastcgi_params;

        fastcgi_param HTTP_PROXY "";
        fastcgi_param HTTPS on;
        fastcgi_request_buffering off;
   }
}

I'm not the most knowledgeable NGINX buff, so most of the fastcgi lines are copied from somewhere else.


Reload Configurations + Certbot


Finally, I reloaded php-fpm and NGINX, then ran Certbot and followed its prompts to set up a TLS certificate for this new subdomain.


systemctl restart php-fpm
systemctl restart nginx
certbot

Certbot will add some extra lines to your NGINX configuration; it will reload NGINX so that those changes take effect immediately.


Configure myTinyTodo


By this point, I had NGINX forwarding incoming requests to a few FastCGI pools, which in turn are running under a restricted user account. Traffic to and from the server is encrypted with a signed Let's Encrypt certificate which Certbot will automatically renew (if you've configured it to do so).


That was a lot, but what I've outlined is a useful set of steps to securely set up many kinds of web services. Proxying requests to a restricted application pool is a commonplace task as far as web servers go.


At this point I could access and configure myTinyTodo through its web interface. According to the steps on the developer's website, this involves navigating to /setup.php and entering the database credentials.


Conclusion


Thank you for reading all this. I wrote this mainly to help myself remember how I set this up, as well as to help anyone else who is looking for instructions on configuring a relatively secure environment for such an application. I welcome all suggestions and criticism, as I'm by no means an expert Linux sysadmin.


mytinytodo.png


Posted in: s/self-hosted

๐Ÿ Addison [mod]

2023-09-24 ยท 8 months ago

-- Response ended

-- Page fetched on Sun May 19 19:49:37 2024