Compare commits

...

10 Commits

Author SHA1 Message Date
ktyl 2fdd63de56 more tweaks 2022-12-03 15:37:22 +00:00
ktyl aebe95aa01 edits before posting 2022-12-03 15:06:52 +00:00
ktyl 6116d9ccbd automount NFS 2022-12-03 15:00:33 +00:00
ktyl b7c2193ba5 merci à ethel 2022-11-15 00:41:09 +00:00
ktyl 9ca4dd6b62 remove author subtitle 2022-11-13 19:03:25 +00:00
ktyl d42897624f un cafe dans l'espace 2022-11-13 13:48:44 +00:00
ktyl c306093453 fix typos 2022-10-19 18:43:47 +01:00
ktyl 40fbdd93c0 the prince of milk 2022-10-18 19:24:00 +01:00
ktyl ef586f654d fix broken link 2022-10-17 20:59:24 +01:00
ktyl f31ebc88f4 add drone ci 2022-10-17 20:39:45 +01:00
4 changed files with 252 additions and 0 deletions

View File

@ -0,0 +1,121 @@
# Drone CI
When it comes to automation, [GitLab CI](https://gitlab.com) has been my go-to for running builds, tests and deployments of projects from static websites to 3D open-world games.
This has generally been on a self-hosted installation, and often makes use of physical runners.
However, I have some gripes: I mostly only use it for the CI, but it comes with an issue tracker and Git hosting solution too - great for some cases, but overkill in so many others.
Because it's such a complete solution, GitLab is a bit of a resource hog, and can often run frustratingly slowly.
Recently I've been playing with a friend's self-hosted instance of [Drone CI](https://drone.io/) as a lightweight alternative, and I much prefer it.
I didn't set up the instance, so that part is out of scope for this post, but in case it's relevant, we're using a self-hosted [Gitea](https://gitea.io/) instance to host the source.
You can find out about configuring Drone with Gitea [here](https://docs.drone.io/server/provider/gitea/).
## Yet Another Yaml Config
Like GitLab, Drone is configured via a YAML file at the project root, called `.drone.yml`.
Drone is configured by creating 'steps' to the pipeline, where GitLab uses 'jobs'.
My first project's automation requirements were small - all I needed for a deployment was to copy all the files in a directory on every push to the `main` branch.
This means I needed secure access to the host, and the ability to copy files to it.
I didn't want to dedicate any permanent resources to such a small project, so opted for the `docker` pipeline option.
My pipeline would contain a single `deploy` step which would configure SSH access to the host, and then use it to copy the relevant files from the checked out version of the project.
I decided to use `ubuntu` as the Docker image for familiarity and accessibility - there are probably better options.
Drone widely supports Docker image registries; I have not used Docker much, but would like to get more experience with it.
```yml
kind: pipeline
type: docker
name: deploy
steps:
- name: deploy
image: ubuntu
when:
branch:
- main
commands:
- echo hello world
```
## Secrets
A hugely important aspect of automation is ensuring the security of one's pipelines.
Automated access between pipelines is a big risk, and should be locked down as much as possible.
For passing around secrets such as passwords and SSH keys, Drone has a concept of secrets.
I created a private key on my local machine for the runner's access to the remote host, and added a [per-repository secret](https://docs.drone.io/secret/repository/) to contain the value.
This is a named string value which can be accessed from within the context of a single pipeline step.
I also created secrets to contain values for the remote host address and the user to login as.
These are less of a security concern than the private SSH key, but we should obfuscate them anyway.
It's also a useful step towards generalising the pipeline for other projects: I can use the same set of commands in multiple CI configurations, and just update the secrets from the project page.
This block was placed in the same step definition as above, below the `image:` entry:
```
environment:
HOST:
from_secret: host
USER:
from_secret: user
SSH_KEY:
from_secret: ssh_key
```
## Connecting
To use the SSH key, we need to spin up `ssh-agent` and load our key into it.
Since it's passed into the job as an environment variable, this involves first writing it to a file.
We also need to disable host key checking (the bit that asks if you're sure you want to connect to a new host) as we're making an automated SSH connection, and therefore won't be there to type 'yes'.
```yml
# configure ssh
- eval $(ssh-agent -s)
- mkdir -p ~/.ssh
- echo "$SSH_KEY" > ~/.ssh/id_rsa
- chmod 600 ~/.ssh/id_rsa
- ssh-add
- echo "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config
```
Finally, it's time to run some SSH commands.
I had a bit of trouble getting the hang of variable templating here - it took some trial and error to figure out what variables would get expanded and when.
Since my `HOST` and `USER` values are defined in secrets, I had to get them from my evironment variables and into a correctly formatted string for the SSH target.
As I would be running multiple commands, I also wanted to store this in a variable to keep the SSH commands short in the Drone config.
What ended up working for me was this:
```yml
# environment variables get expanded (twice?)
- host="$${USER}@$${HOST}"
# running 'hostname' on the deploy target
- ssh $host "hostname"
```
## Images
It's pretty cool to be able to pass a repository through several Docker images through the pipeline.
I have my website's Makefile set up to build off my local machine, which is on Arch.
It therefore depends on Arch-specific package names.
I didn't want to have to hack around my existing build configuration just to build it automatically, but I also found that the deploy steps I'd already written worked best on Ubuntu.
For Drone, this is no problem - I can simply specify `image: archlinux` in the build stage, and `image: ubuntu` for the deploy step.
My Makefile and local workflow requires no changes at all, but I can still use the more robust deploy steps from Ubuntu.
## Final thoughts
I like Drone's minimalist approach to CI.
There isn't much in terms of configuration, and the interface is much snappier than Gitlab's.
It will take a bit more work to get a full workflow - Gitlab basically has one out the box - but working with more separate components should provide flexibility and resilience in the long run.
I'd like to explore some more features, like [templates](https://docs.drone.io/template/yaml/) for steps shared between repositories, and spend more time tuning exactly when pipelines run.
I also want to try building some more complex projects, such as those using game engines like Godot, and those targeting multiple target platforms.
Those are adventures for another day, though.
That's all for now, thanks for reading and see you next time!
## References
* [GitLab CI config to deploy via SSH](https://medium.com/@hfally/a-gitlab-ci-config-to-deploy-to-your-server-via-ssh-43bf3cf93775)

View File

@ -0,0 +1,30 @@
# The Prince of Milk
The Prince of Milk is a science fiction novel by Exurb1a of YouTube fame.
It follows the story of a fictional village in southern England named Wilthail, which ends up the unwilling venue for the settling of an ancient grudge.
Deities ("Etherics") exist alongside the mundanity of 21st century Wilthail, and engage in absurdity, sodomy and violence with its quaint population.
The books makes reference to a number of popular philosophical debates, and takes inspiration from a number of classical sci-fi authors.
A common theme is the idea that power is relative.
The Etherics are immortal - their grudge has played out across hundreds of 'Corporic' incarnations - and have power and abilities far beyond the comprehension of their human counterparts.
However, they do not necessarily view themselves as gods.
This is particularly true of the character Beomus, who frequently plays down their immortality and returns fire with questions about modern humans' relationship to their primitive ancestors, or with ants.
This relativity of power recurs plenty, and is reminiscient of Arthur C. Clarke's assertion that sufficiently advanced technology is indistinguishable from magic.
As characters in a book, the Etherics are understandably cagey about how any of their abilities work - but broadly refuse to classify them as either magic or technology.
Reincarnation is viewed as a fundamental way of the world - Chalmers' panpsychism, or the Hard Problem of Philosophy.
This goes further than to suggest that people are simply reincarnated as others when they die, rather suggesting that consciousness is a fundamental force of the universe, in just the way electromagnetism is.
It's a recursive thing, from the lowliest atom up through rocks, mice, snakes, cats, people, stars and gods.
It's a neat and satisfying view, and one that has yet to be disproven by neuroscience.
The human characters are invariably damaged - mental health issues, broken relationships, toxic parentage, drug use, suicide, difficult histories.
This paints PoM's world as realistic, and grounds it through the fantastical happenings in the middle act.
It grips the reader with its variety of characters, and follows them all as they confront not only their own personal hells, but the one they now find themselves sharing, in a twisted take on country bumpkinism.
Overall, I thoroughly enjoyed this book, and am looking forward to reading more of Exurb1a's writing.
I am a little biased, as I have already enjoyed the YouTube channel for a number of years.
There is a short glossary at the end naming and exploring some of the particular concepts explored in the novel, which prompt the reader to explore further.
Top marks!

View File

@ -0,0 +1,11 @@
# Un Cafe Dans l'Espace
J'ai acheté ce livre quand j'ai visité la Cité de l'Espace à Toulouse. C'est écrit par Michel Tognini, un astronaute français qui été dans l'espace deux fois. Il a travillé sur la station spatiale de Mir, et sur la navette spatiale pour décoller CHANDRA, une observatoir dans le bas orbite. Depuis, il a selectionné et entrainé de nouveaux astronautes européens.
Ce livre parle de plusiers subjets en relation à l'espace: de l'entrainement de l'auteur à la Cité des Étoiles en Russie, de les échecs et défis dans l'espace, aux réalisations des sociétés privés comme SpaceX, Blue Origin et Virgin Galactic. Comme d'autres astronautes, Tognini a étudié comme pilote de chasse, et puis comme pilote d'essai. Il a rejoint l'agence spatiale française CNES avant la formation de l'ESA, qui existe encore aujourd'hui.
J'ai trouvé que je connaissais déjà beaucoup des histoires dans ce livre, parce que j'ai toujours eu une adoration pour l'espace, et c'est écrit pour une audience générale. Ma première raison de lire ce livre est que c'était mon premier français! Cela m'a pris quelques mois, mais c'etait une experience agréable. Au début, j'avais besoin de rechercer plusiers mots à chaque page, mais à la fin j'ai trouvé que je pouvais lire beaucoup d'aisance.
Je recommende ce livre aux francophones qui sont interessés par l'espace, mais qui sont peut-être moins familiers avec le jargon comme moi.
Encore, merci à mon cher Ethel pour m'aider avec mon français ! <3

View File

@ -0,0 +1,90 @@
# Automounting network drives with NFS
I have a NAS which supports NFS, which I use to store all of my photos, music and other media on my local network.
This gives me OS-independent to all of these files, and frees up drive space on my laptops and desktop - most of which are dual-booted.
On Windows it's fairly straightforward to establish a network drive, but on Linux-based systems - at least on the Debian- and Arch- based distros I find myself using - the process is a little more involved.
Here I'll use `systemd` to automatically mount a shared folder when they're accessed by a client machine.
There are other ways to do this, but as my machines predimonantly run Debian- or Arch-derived Linux distributions, `systemd` is a choice that works for both.
This post is largely based on the description on the [ArchWiki](https://wiki.archlinux.org/title/NFS#As_systemd_unit).
My NAS' hostname is `sleeper-service`, and I'll be mounting the `Music` shared folder.
You'll need the `nfs-utils` package to mount NFS filesytems.
You may also need to configure security on your NAS to allow NFS connections from your local machine's IP.
## Initial mount
Before doing anything automatically, we first need to create a `systemd` unit to mount the remote filesystem at a path in our local filesystem.
I'll mount the remote folder onto the local path `/sleeper-service/Music`.
When creating this file, pay attention to its name, as it's important for it to correspond to the path of the mountpoint.
The correct name can be determined using `systemd-escape` - pay attention to escape characters in the output, this caught me out several times.
```
$ systemd-escape /sleeper-service/Music
-sleeper\x2dservice-Music
$ sudo touch /etc/systemd/system/sleeper\\x2dservice-Music.mount
```
Don't ask me why `systemd` is like this - I think it's silly too.
After creating the unit file, we then need to edit it and fill out some information, specifying where the remote filesystem is and also when we need to initialise it.
Here I used a name instead of an address for the `What=` part - I have an entry for `sleeper-service` configured in `/etc/hosts`, but you can equally use an IP address just as well.
```
[Unit]
Description=Mount music at boot
[Mount]
What=sleeper-service:/volume1/Music
Where=/sleeper-service/Music
Options=vers=3
Type=nfs
TimeoutSec=30
[Install]
WantedBy=multi-user.target
```
Once we've created this, we can try to manually mount the shared folder by starting the unit:
```
$ sudo systemctl start sleeper\\x2dservice-Music.mount
$ ls /sleeper-service/Music
```
At this stage you ought to see the contents of your shared folder.
Next, we want to set up the automount, so that this remote folder is mounted automatically when we try to access it.
To do that, we need to first stop/disable the unit we just created:
```
$ sudo systemctl disable sleeper\\x2dservice-Music.mount
```
Then, let's create an `.automount` unit with the same name as the `.mount` file we already have.
The automount unit expects the mount unit to exist alongside it - it doesn't replace it.
```
$ sudo touch /etc/systemd/system/sleeper\\x2dservice-Music.automount
```
```
[Unit]
Description=Automount NAS music
[Automount]
Where=/sleeper-service/Music
[Install]
WantedBy=multi-user.target
```
Then, enable the new `.automount` unit to have it run automatically:
```
$ sudo systemctl enable sleeper\\x2dservice-Music.automount
```
The folder should now be automatically mounted at the target location when trying to access it.
As always, thanks for reading and I hope this was helpful.
If I got something wrong, or there's an easier way to do it, or you just want to say hi, please don't hesitate to [get in touch!](mailto:me@ktyl.dev)