removed files that got added back somehow

7 files changed, 0 insertions, 790 deletions

diff --git a/tech/debian 7 digital ocean running slowly.txt b/tech/debian 7 digital ocean running slowly.txt
deleted file mode 100644
index 9cb2e14..0000000
--- a/tech/debian 7 digital ocean running slowly.txt
+++ /dev/null
@@ -1,7 +0,0 @@
-http://unix.stackexchange.com/questions/68597/console-kit-daemon-hogging-cpu-and-ram
-
-Kill the console-kit-daemon process if it's still running. Remove the file 
-
-/usr/share/dbus-1/system-service/org.freedesktop.ConsoleKit.service 
-
-(or move it to some place where you could restore it, if necessary). Reboot and you will see that console-kit-daemon no longer automatically starts up.
\ No newline at end of file
diff --git a/tech/install tinytinyrss debian 10.txt b/tech/install tinytinyrss debian 10.txt
deleted file mode 100644
index 0c65213..0000000
--- a/tech/install tinytinyrss debian 10.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-ttrss
-
-php modules debian:
-
-php-fpm php-xml php-mbstring php-pgsql
diff --git a/tech/set up certbot nginx ubuntu.txt b/tech/set up certbot nginx ubuntu.txt
deleted file mode 100644
index f13b1e9..0000000
--- a/tech/set up certbot nginx ubuntu.txt
+++ /dev/null
@@ -1,137 +0,0 @@
-EFF's free certificate service, Certbot, has greatly simplified the task of setting up HTTPS for your websites. The only downside is that the certificates are only good for 90 days. Fortunately renewing is easy, and we can even automate it all with systemd. Here's how to set up Certbot with Nginx *and* make sure your SSL certs renew indefinitely with no input from you.
-
-This tutorial is aimed at anyone using an Ubuntu 18.04 VPS from cheap hosts like DigitalOcean or [Vultr.com](https://www.vultr.com/?ref=6825229), but should also work for other versions of Ubuntu, Debian, Fedora, CentOS and any other system that uses systemd. The only difference will be the commands you use to install Certbot. See the Certbot site for [instructions](https://certbot.eff.org/) specific to your system.
-
-Here's how you get Certbot running on Ubuntu 18.04, then we'll dive into setting up automatic renewals via systemd.
-
-You should not need this with 18.04, but to be on the safe side, make sure you have the `software-properties-common` package installed. 
-
-~~~~console
-sudo apt install software-properties-common
-~~~~
-
-The next part requires that you add a PPA, my least favorite part of Certbot for Ubuntu, as I don't like to rely on PPAs for something as mission critical as my security certificates. Still, as of this writing, there is not a better way. At least go [look at the code](https://launchpad.net/~certbot/+archive/ubuntu/certbot) before you blindly cut and paste. When you're done, here's your cut and paste:
-
-~~~~console
-sudo apt update
-sudo add-apt-repository ppa:certbot/certbot
-sudo apt update
-sudo apt install python-certbot-nginx 
-~~~~
-
-Now you're ready to install some certs. For this part I'm going to show the commands and the output of the commands since the `certbot` command is interactive. Note that the version below will append some lines to your Nginx config file. If you prefer to edit your config file yourself, use this command: `sudo certbot --nginx certonly`, otherwise, here's now to get your certs.
-
-~~~~console
-sudo certbot --nginx
-
-[sudo] password for $youruser: 
-Saving debug log to /var/log/letsencrypt/letsencrypt.log
-Plugins selected: Authenticator nginx, Installer nginx 
-
-Which names would you like to activate HTTPS for?
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-1: luxagraf.net
-2: awstats.luxagraf.net
-3: origin.luxagraf.net
-4: www.luxagraf.net
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -                                                                                                                                                               
-Select the appropriate numbers separated by commas and/or spaces, or leave input blank to select all options shown (Enter 'c' to cancel): 4
-Obtaining a new certificate
-Performing the following challenges:
-http-01 challenge for www.luxagraf.net
-Waiting for verification...
-Cleaning up challenges
-Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/luxagraf.net.conf
-
-Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access.
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-1: No redirect - Make no further changes to the webserver configuration.
-2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for
-new sites, or if you're confident your site works on HTTPS. You can undo this
-change by editing your web server's configuration.
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Select the appropriate number [1-2] then [enter] (press 'c' to cancel): 2
-
-Traffic on port 80 already redirecting to ssl in /etc/nginx/sites-enabled/luxagraf.net.conf
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-Congratulations! You have successfully enabled https://www.luxagraf.net.
-You should test your configuration at: https://www.ssllabs.com/ssltest/analyze.html?d=www.luxagraf.net
-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-IMPORTANT NOTES:
- - Congratulations! Your certificate and chain have been saved at:
-   /etc/letsencrypt/live/www.luxagraf.net/fullchain.pem
-   Your key file has been saved at:
-   /etc/letsencrypt/live/www.luxagraf.net/privkey.pem
-   Your cert will expire on 2019-01-09. To obtain a new or tweaked
-   version of this certificate in the future, simply run certbot again
-   with the "certonly" option. To non-interactively renew *all* of
-   your certificates, run "certbot renew"
- - If you like Certbot, please consider supporting our work by:
-   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
-   Donating to EFF:                    https://eff.org/donate-le     
-~~~~
-
-And there you have it, SSL certs for all your domains.
-
-That's all good and well, but those new certs are only good for 90 days. The odds of you remembering to renew that every 90 days -- even with reminder emails from the EFF -- is near nil. Plus, do you really want to be renewing certs by hand, [like an animal](http://5by5.tv/hypercritical/17)? No, you want to automate everything so you can do better things with your time. 
-
-You could use cron, but the more modern approach would be to create a systemd service and a systemd timer to control when that service runs.
-
-I highly recommend reading through the Arch Wiki page on [systemd services and timers](https://wiki.archlinux.org/index.php/Systemd/Timers), as well as the [systemd.timer man pages](https://jlk.fjfi.cvut.cz/arch/manpages/man/systemd.timer.5) to get a better understanding of how you can automate other tasks in your system. But for the purposes of this tutorial all you really need to understand is that timers are just like other systemd unit files, but they include a `[Timer]` block which takes parameter for exactly when you want your service file to run.
-
-Timer files can live right next to your service files in `/etc/systemd/system/`.
-
-There's no hard and fast rules about naming timers, but it makes sense to use same name as the service file the timer controls, except the timer gets the `.timer` extension. So you'll have two files `myservice.service` and `myservice.timer`.
-
-Let's start with the service file. I call mine `certbot-renewal`. Open the service file:
-
-~~~~console
-sudo nano /etc/systemd/system/certbot-renewal.service
-~~~~
-
-This is going to be a super simple service, we'll give it a description and a command to run and that's it:
-
-~~~~ini
-[Unit]
-Description=Certbot Renewal
-
-[Service]
-ExecStart=/usr/bin/certbot renew
-~~~~
-
-Next we need to create a .timer file that will run the certbot.renewal service every day. Create this file:
-
-~~~~console
-sudo nano /etc/systemd/system/certbot-renewal.timer
-~~~~
-
-And now for the slightly more complex timer:
-
-~~~~ini
-[Unit]
-Description=Certbot Renewal Timer
-
-[Timer]
-OnBootSec=500
-OnUnitActiveSec=1d
-
-[Install]
-WantedBy=multi-user.target
-~~~~
-
-The `[Timer]` directive can take a number of parameters, the ones we've used constitute what's called a monotonic timer, which means they run "after a time span relative to a varying starting point". In other words they're not calendar events like cron. 
-
-Our monotonic timer has two directives, `onBootSec` and `OnUnitActiveSec`. The first should be obvious, our timer will run 500 seconds after the system boots. Why 500? No real reason, I just didn't want to bog down the system at boot. 
-
-The `OnUnitActiveSec` is really what makes this work. This directive measures time relative to when the service that the timer controls was last activated. In our case the `1d` means run the service one day after it last ran. So our timer will run once a day to make sure our scripts stay up to date.
-
-As a kind of footnote, in systemd parlance calendar-based timers are called realtime timers and can be used to replace cron if you want, though there are some disadvantages, see the Arch Wiki for [a good overview of what you get and what you lose](https://wiki.archlinux.org/index.php/Systemd/Timers#As_a_cron_replacement) if you go that route.
-
-Okay, the last step for our certbot renewal system is to enable and then start our timer. Note that we don't have to do either to our actual service file because we don't want it active, the timer will control when it runs.
-
-~~~~console
-sudo systemctl enable certbot-renewal.timer
-sudo systemctl start certbot-renewal.timer
-~~~~
-
-Run those commands and you're done. Your timer is now active and your Certbot certificates will automatically renew as long as your server is up and running.
diff --git a/tech/set up debian droplet python 3 + gunicorn + supervisor.txt b/tech/set up debian droplet python 3 + gunicorn + supervisor.txt
deleted file mode 100644
index 3f199b9..0000000
--- a/tech/set up debian droplet python 3 + gunicorn + supervisor.txt
+++ /dev/null
@@ -1,166 +0,0 @@
-Set Up Debian Droplet - Python 3 + gunicorn + supervisor
-
-[reference:
-<http://michal.karzynski.pl/blog/2013/06/09/django-nginx-gunicorn-virtualenv-supervisor/>
-<http://wiki.nginx.org/HttpHeadersMoreModule#more_clear_input_headers>
-<https://github.com/nbs-system/naxsi/wiki/basicsetup>
-<http://pillow.readthedocs.org/en/latest/installation.html#linux-installation>
-<http://codeinthehole.com/writing/how-to-install-postgis-and-geodjango-on-ubuntu/>
-<http://docs.gunicorn.org/en/latest/configure.html>
-<udo update-rc.ttp://edvanbeinum.com/how-to-install-and-configure-supervisord/>
-]
-
-If you really want python3.3 you can compile it from scratch. That would eliminate the need to install virtualenv, since it's part of Python as of 3.3. I've gone that route, but for simplicity's sake most of the time I just use python 3.2 which has is available in the debian stable repos. I also grab pip from the repos, though gunicorn and supervisor I install via pip since I want those on a virtualenv-based per-project basis. 
-
-So start with this:
-
-    apt-get install python3.2 python3.2-dev python3-pip
-
-And then:
-
-    pip-3.2 install virtualenv
-    
-That gets us a nice python3 working setup, though note that you have to call python with python3 and pip-3.2. To cut down on the typing I just make aliases in my .zshrc along the lines of:
-
-    alias p3="python3 "
-    alias p3p="pip-3.2 "
-    
-Okay so we can use that to setup a working django environment with `virtualenv`. You can use [`virtualenvwrapper`](http://virtualenvwrapper.readthedocs.org/en/latest/) if you like, I find it to be unnecessary. I do something like this:
-
-    mkdir -p apps/mydjangoapp
-    cd !$
-    virtualenv --distribute --python=python3 venv
-    source venv/bin/activate
-    
-There are few other things that you may want to install before we get around to actually installing stuff with pip. For example if you plan to use memcached you'll want to install pylibmc which needs:
-
-    sudo apt-get install python-dev libmemcached-dev
-    
-**Apparently pylibmc doesn't work with Python3 yet**
-
-Then I just load everything I need from my requirements.txt file, which lives in the config folder:
-
-    pip install -r config/requirements.txt
-    
-Where did that file come from? Typically I generate it with `pip freeze > requirements.txt` in my local development environment. 
-    
-Among the requirements will be gunicorn. If you don't already have a requirements file then you'd just do this:
-
-    pip install gunicorn
-    
-Okay, so we have our sandboxed python3 environment, along with gunicorn to act as a server for our site. In a minute we'll connect Nginx and gunicorn, but first let's make sure our gunicorn server restarts whenever our machine reboots. To do that we'll use `supervisor`. Here's where it gets tricky though, `supervisor` doesn't run under Python 3. It has no problem *managing* python 3 projects, it just doesn't run under python 3 yet. That means we can't just install it using pip3.2.
-
-We could install it with the system pip, but debian (and ubuntu) have a supervisor repo, so we can just do:
-    
-    sudo apt-get install supervisor
-    
-That will install and start supervisor. Let's add an init script so that supervisord starts up should the server need to reboot. so create the file
-
-    /etc/init.d/supervisord
-    
-And grab the appropriate [init script from the supervisor project](https://github.com/Supervisor/initscripts). I use the Debian script from that link. Paste that script into `/etc/init.d/supervisord` and save. Then make it executable:
-
-    sudo chmod +x /etc/init.d/supervisord
-
-Now, make sure supervisor isn't running:
-
-    supervisorctl shutdown
-    
-And add supervisor to 
-
-With Supervisor installed you can start and watch apps by creating configuration files in the `/etc/supervisor/conf.d` directory. You might do something like this, in, for example, `/etc/supervisor/conf.d/helloworld.conf`:
-
-    [program:helloworld]
-    command = /home/<username>/apps/mydjangoapp/venv/bin/gunicorn -c /home/<username>/apps/mydjangoapp/config/gunicorn_config.py config.wsgi
-    directory = /home/<username>/apps/mydjangoapp/
-    user = <non-privledged-user>
-    autostart = true
-    autorestart = true
-    stdout_logfile = /var/log/supervisor/helloworld.log
-    stderr_logfile = /var/log/supervisor/helloworld_err.log
-
-You'll need to fill in the correct paths based on your server setup, replacing <username> with your username and `mydjangoapp/etc...` with the actual path to the gunicorn app. This also assumes your gunicorn config file lives in `mydjangoapp/config/`. We'll get to that file in a minute.
-
-First, let's tell supervisor about our new app:
-
-    sudo supervisorctl reread
-    
-You should see a message `helloworld available`. So Supervisor knows about our app, let's actually add it.
-
-    sudo supervisorctl update
-    
-Now you should see a message that says something like `helloworld: added process group`. Supervisor is now aware of our hello world app and will make sure it automatically starts up whenever our server reboots. You can check the status of our gunicorn app with:
-
-   sudo supervisorctl status
-   
-Right now that will generate an error that looks something like this:
-
-    helloworld FATAL can't find command '/home/<username>/apps/mydjangoapp/venv/bin/gunicorn'
-
-
-
-
-
-Now we just need to set up that gunicorn_config.py file we referenced earlier. 
-
-In my setup that file looks like this:
-
-    from os.path import dirname, abspath,join
-    # get the root folder for this project, which happens to be two folder up
-    PROJ_ROOT = abspath(dirname(dirname(dirname(__file__))))+'/'
-    command = join(PROJ_ROOT, "/venv/bin/gunicorn")
-    pythonpath = PROJ_ROOT
-    bind = '127.0.0.1:8002'
-    workers = 3
-    log_level = "warning"
-    error_logfile = "/home/<username>/logs/gunicorn.error.log"
-
-This is pretty boilerplate, you just need to adjust the paths and it should work. The other thing to note is the line `bind = '127.0.0.1:8002'`. That's the address we'll pass requests to with Nginx.
-
-Okay, now let's go back to the Nginx tutorial we worked with in the previous part of this series. Here's what this looks like:
-
-
-
-    # define an upstream server named gunicorn on localhost port 8002
-    upstream gunicorn {
-        server localhost:8002;
-    }
-    
-    server {
-        listen      80;
-        server_name mydomain.com;
-        root /var/www/mydomain.com/;    
-        error_log  <path to logs>/mydomain.error.log main;
-        access_log  <path to logs>/mydomain.access.log main;
-        # See http://wiki.nginx.org/HttpCoreModule#client_max_body_size
-        client_max_body_size 0;
-    
-        # this tries to serve a static file at the requested url
-        # if no static file is found, it passes the url to gunicorn
-        try_files $uri @gunicorn;
-    
-        # define rules for gunicorn
-        location @longgunicorn {
-            # repeated just in case
-            client_max_body_size 0;
-    
-            # proxy to the gunicorn upstream defined above
-            proxy_pass http://gunicorn;
-    
-            # makes sure the URLs don't actually say http://gunicorn 
-            proxy_redirect off;
-            # If gunicorn takes > 3 minutes to respond, give up
-            proxy_read_timeout 3m;
-    
-            # make sure these HTTP headers are set properly
-            proxy_set_header Host            $host;
-            proxy_set_header X-Real-IP       $remote_addr;
-            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
-    
-        }
-        
-      
-    }
-
-
- 
diff --git a/tech/set up geodjango on debian 7 digital ocean.txt b/tech/set up geodjango on debian 7 digital ocean.txt
deleted file mode 100644
index 475c6eb..0000000
--- a/tech/set up geodjango on debian 7 digital ocean.txt
+++ /dev/null
@@ -1,98 +0,0 @@
-the first thing we need is python 3.4+ which I install by hand:
-
-prereqs:
-sudo apt-get install build-essential libncursesw5-dev libssl-dev libgdbm-dev libc6-dev libsqlite3-dev tk-dev libreadline6-dev
-
-wget https://www.python.org/ftp/python/3.4.1/Python-3.4.1.tgz
-tar -xvzf Python-3.4.1.tgz
-cd Python-3.4.1
-./configure --prefix=/opt/python3
-make 
-sudo make altinstall
-
-Then we need postgres and the geospatial libs:
-
-apt-get install postgresql postgresql-contrib binutils libproj-dev gdal-bin
-
-
-
-postgis 2 i also do from source:
-
-wget http://download.osgeo.org/postgis/source/postgis-2.1.3.tar.gz
-tar -xvzf postgis-2.1.3.tar.gz
-cd postgis-2.1.3
-
-preqs:
-
-apt-get install libpq-dev postgresql-server-dev-all libxml2 libgeos-dev libxml2-dev gdal-bin libgdal-dev
-
-./configure
-make
-sudo make install
-
-Then you just need to create a db user and database
-
-sudo su - postgres
-createuser -P -s -e luxagraf
-
-The with regular user:
-createdb luxagraf -U luxagraf -W -hlocalhost
-psql -U luxagraf -W -hlocalhost -d luxagraf
-and when you're in postgres:
-CREATE EXTENSION postgis;
-
-Then just load the data:
-psql -U luxagraf -W -hlocalhost -d luxagraf -f fullbak.sql (or whatever your backupfile is)
-
-
-The last thing is a virtualenv for our project using python3.4
-
-#make sure you use the right pip (included with python 3.4+)
-sudo /opt/python3/bin/pip3.4 install virtualenv
-then cd to proj dir and do:
-/opt/python3/bin/virtualenv --distribute --python=/opt/python3/bin/python3-4 venv
-then activate and install what you need
-
----
-Once that's set up we need to connect gunicorn to nginx via supervisor.
-
-    sudo apt-get install supervisor
-    
-That will install and start supervisor. Let's add an init script so that supervisord starts up should the server need to reboot. so create the file
-
-    /etc/init.d/supervisord
-    
-And grab the appropriate [init script from the supervisor project](https://github.com/Supervisor/initscripts). I use the Debian script from that link. Paste that script into `/etc/init.d/supervisord` and save. Then make it executable:
-
-    sudo chmod +x /etc/init.d/supervisord
-
-Now, make sure supervisor isn't running:
-
-    supervisorctl shutdown
-    
-And add supervisor to 
-
-With Supervisor installed you can start and watch apps by creating configuration files in the `/etc/supervisor/conf.d` directory. You might do something like this, in, for example, `/etc/supervisor/conf.d/helloworld.conf`:
-
-    [program:helloworld]
-    command = /home/<username>/apps/mydjangoapp/venv/bin/gunicorn -c /home/<username>/apps/mydjangoapp/config/gunicorn_config.py config.wsgi
-    directory = /home/<username>/apps/mydjangoapp/
-    user = <non-privledged-user>
-    autostart = true
-    autorestart = true
-    stdout_logfile = /var/log/supervisor/helloworld.log
-    stderr_logfile = /var/log/supervisor/helloworld_err.log
-
-You'll need to fill in the correct paths based on your server setup, replacing <username> with your username and `mydjangoapp/etc...` with the actual path to the gunicorn app. This also assumes your gunicorn config file lives in `mydjangoapp/config/`. We'll get to that file in a minute.
-
-First, let's tell supervisor about our new app:
-
-    sudo supervisorctl reread
-    
-You should see a message `helloworld available`. So Supervisor knows about our app, let's actually add it.
-
-    sudo supervisorctl update
-    
-Now you should see a message that says something like `helloworld: added process group`. Supervisor is now aware of our hello world app and will make sure it automatically starts up whenever our server reboots. You can check the status of our gunicorn app with:
-
-   sudo supervisorctl status
\ No newline at end of file
diff --git a/tech/set up gitea on ubuntu 18.04.txt b/tech/set up gitea on ubuntu 18.04.txt
deleted file mode 100644
index 6d1870b..0000000
--- a/tech/set up gitea on ubuntu 18.04.txt
+++ /dev/null
@@ -1,233 +0,0 @@
-I've never liked hosting my git repos on someone else's servers. GitHub especially is not a company I'd do business with, ever. I do have a repo or two hosted over at [GitLab](https://gitlab.com/luxagraf) because those are projects I want to be easily available to anyone. But I store almost everything in git -- notes, my whole documents folder, all my code projects, all my writing, pretty much everything is in git -- but I like to keep all that private and on my own server.
-
-For years I used [Gitlist](http://gitlist.org/) because it was clean, simple, and did 95 percent of what I needed in a web-based interface for my repos. But Gitlist is abandonware at this point and broken if you're using PHP 7.2. There are few forks that [patch it](https://github.com/patrikx3/gitlist), but it's copyrighted to the original dev and I don't want to depend on illegitimate forks for something so critical to my workflow. Then there's self-hosted Gitlab, which I like, but the system requirements are ridiculous.
-
-Some searching eventually led me to Gitea, which is lightweight, written in Go and has everything I need. 
-
-Here's a quick guide to getting Gitea up and running on your Ubuntu 18.04 -- or similar -- VPS.
-
-### Set up Gitea
-
-The first thing we're going to do is isolate Gitea from the rest of our server, running it under a different user seems to be the standard practice. Installing Gitea via the Arch User Repository will create a `git` user, so that's what I used on Ubuntu 18.04 as well. 
-
-Here's a shell command to create a user named `git`:
-
-~~~~console
-sudo adduser --system --shell /bin/bash --group --disabled-password --home /home/git git
-~~~~
-
-This is pretty much a standard adduser command such as you'd use when setting up a new VPS, the only difference is that we've added the `--disable-password` flag so you can't actually log in with it. While we will use this user to authenticate over SSH, we'll do so with a key, not a password.
-
-Now we need to grab the latest Gitea binary. At the time of writing that's version 1.5.2, but be sure to check the [Gitea downloads page](https://dl.gitea.io/gitea/) for the latest version and adjust the commands below to work with that version number. Let's download the Gitea binary and then we'll verify the signing key. Verifying keys is very important when working with binaries since you can't see the code behind them[^1].
-
-~~~~console
-wget -O gitea https://dl.gitea.io/gitea/1.5.2/gitea-1.5.2-linux-amd64
-gpg --keyserver pgp.mit.edu --recv 0x2D9AE806EC1592E2
-wget https://dl.gitea.io/gitea/1.5.2/gitea-1.5.2-linux-amd64.asc
-gpg --verify gitea-1.5.2-linux-amd64.asc gitea
-~~~~
-
-A couple of notes here, GPG should say the keys match, but then it should also warn that "this key is not certified with a trusted signature!" That means, essentially, that this binary could have been signed by anybody. All we know for sure is that wasn't tampered with in transit[^1].
-
-Now let's make the binary executable and test it to make sure it's working:
-
-~~~~console
-chmod +x gitea
-./gitea web
-~~~~
-
-You can stop Gitea with `Ctrl+C`. Let's move the binary to a more traditional location:
-
-~~~~console
-sudo cp gitea /usr/local/bin/gitea
-~~~~
-
-The next thing we're going to do is create all the directories we need. 
-
-~~~~console
-sudo mkdir -p /var/lib/gitea/{custom,data,indexers,public,log}
-sudo chown git:git /var/lib/gitea/{data,indexers,log}
-sudo chmod 750 /var/lib/gitea/{data,indexers,log}
-sudo mkdir /etc/gitea
-sudo chown root:git /etc/gitea
-sudo chmod 770 /etc/gitea
-~~~~
-
-That last line should make you nervous, that's too permissive for a public directory, but don't worry, as soon as we're done setting up Gitea we'll change the permissions on that directory and the config file inside it. 
-
-Before we do that though let's create a systemd service file to start and stop Gitea. The Gitea project has a service file that will work well for our purposes, so let's grab it, make a couple changes and then we'll add it to our system:
-
-~~~~console
-wget https://raw.githubusercontent.com/go-gitea/gitea/master/contrib/systemd/gitea.service 
-~~~~
-
-Now open that file and uncomment the line `After=postgresql.service` so that Gitea starts after postgresql is running. The resulting config file should look like this:
-
-~~~~ini
-[Unit]
-Description=Gitea (Git with a cup of tea)
-After=syslog.target
-After=network.target
-#After=mysqld.service
-After=postgresql.service
-#After=memcached.service
-#After=redis.service
-
-[Service]
-# Modify these two values and uncomment them if you have
-# repos with lots of files and get an HTTP error 500 because
-# of that
-###
-#LimitMEMLOCK=infinity
-#LimitNOFILE=65535
-RestartSec=2s
-Type=simple
-User=git
-Group=git
-WorkingDirectory=/var/lib/gitea/
-ExecStart=/usr/local/bin/gitea web -c /etc/gitea/app.ini
-Restart=always
-Environment=USER=git HOME=/home/git GITEA_WORK_DIR=/var/lib/gitea
-# If you want to bind Gitea to a port below 1024 uncomment
-# the two values below
-###
-#CapabilityBoundingSet=CAP_NET_BIND_SERVICE
-#AmbientCapabilities=CAP_NET_BIND_SERVICE
-
-[Install]
-WantedBy=multi-user.target
-~~~~
-
-Now we need to move the service file to somewhere systemd expects it and then start and enable the service so Gitea will launch automatically when the server boots.
-
-~~~~console
-sudo cp gitea.service /etc/systemd/system/
-sudo systemctl enable gitea
-sudo systemctl start gitea
-~~~~
-
-There you have it, Gitea is installed, running and will automatically start whenever we restart the server. Now we need to set up Postgresql and then Nginx to serve up our Gitea site to the world. Or at least to us.
-
-### Setup a Postgresql and Nginx
-
-Gitea needs a database to store all our data in; I use PostgreSQL. You can also use MySQL, but you're on your own there. Install PostgreSQL if you haven't already:
-
-~~~~console
-sudo apt install postgresql
-~~~~
-
-Now let's create a new user and database for Gitea:
-
-~~~~console
-sudo su postgres
-createuser gitea
-createdb gitea -O gitea
-~~~~
-
-Exit the postgres user shell by hitting `Ctrl+D`. 
-
-Now let's set up Nginx to serve our Gitea site. 
-
-~~~~console
-sudo apt update
-sudo apt install nginx
-~~~~
-
-For the next part you'll need a domain name. I use a subdomain, git.mydomain.com, but for simplicity sake I'll refer to `mydomain.com` for the rest of this tutorial. Replace `mydomain.com` in all the instructions below with your actual domain name.
-
-We need to create a config file for our domain. By default Nginx will look for config files in `/etc/nginx/sites-enabled/`, so the config file we'll create is:
-
-~~~~console
-nano /etc/nginx/sites-enabled/mydomain.com.conf
-~~~~
-
-Here's what that file looks like:
-
-~~~~nginx
-server {
-    listen 80;
-    listen [::]:80;
-    server_name <mydomain.com>;
-
-
-    location / {
-        proxy_pass http://localhost:3000;
-    }
-
-    proxy_set_header X-Real-IP $remote_addr;
-}
-~~~~
-
-The main line here is the `proxy_pass` bit, which takes all requests and sends it to gitea, which is listening on `localhost:3000` by default. You can change that if you have something else that conflicts with it, but you'll need to change it here and in the service file that we used to start Gitea.
-
-The last step is to add an SSL cert to our site so we can clone over https (and SSH if you keep reading). I have another tutorial on setting up [Certbot for Nginx on Ubuntu](/src/certbot-nginx-ubuntu-1804). You can use that to get Certbot installed and auto-renewing certs. Then all you need to do is run:
-
-~~~~console
-sudo certbot --nginx
-~~~~
-
-Select your Gitea domain, follow the prompts and when you're done you'll be ready to set up Gitea. 
-
-### Setting up Gitea
-
-Point your browser to `https://mydomain.com/install` and go through the Gitea setup process. That screen looks like this, and you can use these values, except for the domain name (and be sure to enter the password you used when we created the `gitea` user for postgresql).
-
-One note, if you intend your Gitea instance to be for you alone, I strongly recommend you check the "disable self registration" box, which will stop anyone else from being able to sign up. But, turning off registration means you'll need to create an administrator account at the bottom of the page. 
-
-<img src="images/2018/gitea-install_FAW0kIJ.jpg" id="image-1706" class="picwide" />
-
-Okay, now that we've got Gitea initialized it's time to go back and change the permissions on those directories that we set up earlier.
-
-~~~~console
-sudo chmod 750 /etc/gitea
-sudo chmod 644 /etc/gitea/app.ini
-~~~~
-Now you're ready to create your first repo in Gitea. Click the little button next to the repositories menu on the right side of your Gitea dashboard and that'll walk you through creating your first repo. Once that's done you can clone that repo with:
-
-~~~~console
-git clone https://mydomain.com/giteausername/reponame.git
-~~~~
-
-Now if you have an existing repo that you want to push to your new Gitea repo, just edit the `.git/config` files to make your Gitea repo the new url, e.g.:
-
-~~~~ini
-[remote "origin"]
-    url = https://mydomain.com/giteausername/reponame.git
-	fetch = +refs/heads/*:refs/remotes/origin/*
-~~~~
-
-Now do this:
-
-~~~~console
-git push origin master 
-~~~~
-
-### Setting up SSH
-
-Working with git over https is pretty good, but I prefer the more secure method of SSH with a key. To get that working we'll need to add our SSH key to Gitea. That means you'll need a GPG key. If you don't have one already, open the terminal on your local machine and issue this command:
-
-~~~~console
-ssh-keygen -o -a 100 -t ed25519
-~~~~
-
-That will create a key named `id_ed25519` in the directory `.ssh/`. If you want to know where that command comes from, read [this article](https://blog.g3rt.nl/upgrade-your-ssh-keys.html).
-
-Now we need to add that key to Gitea. First open the file `.ssh/id_ed25519.pub` and copy the contents to your clipboard. Now in the Gitea web interface, click on the user menu at the upper right and select "settings". Then across the top you'll see a bunch of tabs. Click the one that reads "SSH / GPG Keys". Click the add key button, give your key a name and paste in the contents of the key.
-
-Note: depending on how your VPS was set up, you may need to add the `git` user to your sshd config. Open `/etc/ssh/sshd_config` and look for a line that reads something like this:
-
-~~~~console
-AllowUsers myuser myotheruser git
-~~~~
-
-Add `git` to the list of allowed users so you'll be able to authenticate with the git user over ssh. Now test SSH cloning with this line, substituting your SSH clone url:
-
-~~~~console
-git clone ssh://git@mydomain/giteausername/reponame.git
-~~~~
-
-Assuming that works then you're all set, Gitea is working and you can create all the repos you need. If you have any problems you can drop a comment in the form below and I'll do my best to help you out.
-
-If you want to add some other niceties, the Gitea docs have a good guide to [setting up Fail2Ban for Gitea](https://docs.gitea.io/en-us/fail2ban-setup/) and then there's a whole section on [backing up Gitea](https://docs.gitea.io/en-us/backup-and-restore/) that's well worth a read.
-
-[^1]: You can compile Gitea yourself if you like, there are [instructions on the Gitea site](https://docs.gitea.io/en-us/install-from-source/), but be forewarned its uses quite a bit of RAM to build.
diff --git a/tech/set up mysql php.txt b/tech/set up mysql php.txt
deleted file mode 100644
index 2856f05..0000000
--- a/tech/set up mysql php.txt
+++ /dev/null
@@ -1,144 +0,0 @@
-
-
-Everything you need for wordpress and piwik:
-
-apt-get install php5-dev libssh2-1-dev libssh2-php php5-geoip libgeoip-dev mysql-server php5-mysql php5-fpm fcgiwrap 
-
-then run:
-
-sudo mysql_install_db
-sudo /usr/bin/mysql_secure_installation
-
-
-mysql -u root -p
-CREATE DATABASE local_stats_piwik;
-CREATE USER piwiklocalstats@localhost;
-SET PASSWORD FOR piwiklocalstats@localhost= PASSWORD("");
-GRANT ALL PRIVILEGES ON local_stats_piwik. TO piwiklocalstats IDENTIFIED BY '';
-
-CREATE DATABASE longhandpixels_lhp_wp;
-CREATE USER longhandpixels@localhost;
-SET PASSWORD FOR longhandpixels@localhost= PASSWORD("");
-GRANT ALL PRIVILEGES ON longhandpixels_lhp_wp. TO longhandpixels IDENTIFIED BY '';
-
-FLUSH PRIVILEGES;
-
-next edit 
-
-sudo vim /etc/php5/fpm/php.ini
-
-cgi.fix_pathinfo=0
-
-open_basedir = '/home/wp-user:/tmp:/home/lxf/git:/var/www/stats.luxagraf.net:/var/www/rss.luxagraf.net:/var/www/rss.longhandpixels.net:/var/www/longhandpixels.net:/var/www/git.luxagraf.net:/var/www/storage.luxagraf.net:/var/www/dev.longhandpixels.net'
-
-then:
-
-sudo service php5-fpm restart
-
-last thing to do for wordpress is create a user for secure updates. reference: https://www.digitalocean.com/community/tutorials/how-to-configure-secure-updates-and-installations-in-wordpress-on-ubuntu
-
-sudo adduser wp-user
-sudo chown -R wp-user:wp-user ~/apps/longhandpixels.net
-sudo su - wp-user
-ssh-keygen -t rsa -b 4096 # save in /home/wp-user/wp_rsa
-(answer blank to everything, including password)
-exit
-sudo chown wp-user:www-data /home/wp-user/wp_rsa*
-sudo chmod 0640 /home/wp-user/wp_rsa*
-sudo mkdir /home/wp-user/.ssh
-sudo chown wp-user:wp-user /home/wp-user/.ssh/
-sudo chmod 0700 /home/wp-user/.ssh/
-sudo cp /home/wp-user/wp_rsa.pub /home/wp-user/.ssh/authorized_keys
-sudo chown wp-user:wp-user /home/wp-user/.ssh/authorized_keys
-sudo chmod 0644 /home/wp-user/.ssh/authorized_keys
-sudo vim /home/wp-user/.ssh/authorized_keys
-
-add this to restrict to local connections:
-from="127.0.0.1" ssh-rsa...
-then
-
-sudo apt-get update
-sudo apt-get install php5-dev libssh2-1-dev libssh2-php
-vim apps/longhandpixels.net/wp-config.php
-
-add these lines:
-
-define('FTP_PUBKEY','/home/wp-user/wp_rsa.pub');
-define('FTP_PRIKEY','/home/wp-user/wp_rsa');
-define('FTP_USER','wp-user');
-define('FTP_PASS','');
-define('FTP_HOST','127.0.0.1:sshport');
-
-restart nginx and it should work. make sure that wp-user in allowed ssh hosts and /home/wp-user/ is in open_basedir in php.ini.
-
-
-## Piwik specific:
-
-grab piwik:
-
-wget http://builds.piwik.org/piwik.zip && unzip piwik.zip
-mv piwik apps/app.name
-sudo chown -R www-data:www-data apps/app.name
-mkdir -p /tmp/cache/tracker/
-
-
-apt-get install php5-gd libfreetype6 # for nice parklines
-
-How do I install the GeoIP Geo location PECL extension? from http://piwik.org/faq/how-to/#faq_163
-
-    sudo pecl install geoip
-
-Finally, add the following to your php.ini file:
-
-    extension=geoip.so
-    geoip.custom_directory=/path/to/piwik/misc
-
-Replace /path/to/piwik with the path to your Piwik installation.
-
-And finally, if you are using the GeoLite City database there is one more thing you need to do. The PECL extension won’t recognize the database if it’s named GeoLiteCity.dat so make sure it is named GeoIPCity.dat.
-
-in my case : 
-
-    cp GeoLiteCity.dat apps/stats.luxagraf.net/misc/GeoIPCity.dat
-
-sudo chown -R www-data:www-data apps/stats.luxagraf.net/misc/GeoIPCity.dat
-
-# postgres, postgis python setup
-
-apt-get install build-essential python python3 python-dev python3-dev python-pip python3-pip python-setuptools
-sudo apt-get install postgresql postgresql-server-dev-all
-sudo apt-get install binutils libproj-dev gdal-bin postgis postgresql-9.4-postgis-2.1
-
-
-Stuff for Pillow:
-apt-get install libtiff5-dev libjpeg62-turbo-dev zlib1g-dev libfreetype6-dev liblcms2-dev libwebp-dev tcl8.6-dev tk8.6-dev python-tk
-
-Install uwsgi:
-
-PIP_REQUIRE_VIRTUALENV=false
-sudo pip3 install uwsgi
-
-sudo vi /etc/systemd/system/uwsgi.service
-
-
-[Unit]
-Description=uWSGI Emperor
-After=syslog.target
-
-[Service]
-ExecStart=/usr/local/bin/uwsgi --ini /etc/uwsgi/emperor.ini
-Restart=always
-KillSignal=SIGQUIT
-Type=notify
-StandardError=syslog
-NotifyAccess=all
-
-[Install]
-WantedBy=multi-user.target
-
-
-sudo mkdir -p /etc/uwsgi/vassals/ && cd /etc/uwsgi/vassals
-sudo ln -s ~/apps/luxagraf/config/django.ini /etc/uwsgi/vassals/
-sudo systemctl start uwsgi
-sudo systemctl enable uwsgi
-