I want everything to run on my own hardware, minimizing my costs and letting me use what I already have. Tailscale lets me talk with my computers easily. Kamal lets me deploy from my local machine with ease and zero downtime (my wife will never know!). Tailscale’s Serve feature work great with Kamal Proxy’s accessory setup.
Kamal has one onerous requirement, it requires a container registry. This registry has to be available from your laptop and server. If you use an external service, like GitHub’s Artifact Repository or Digital Ocean’s container registry, then you should be good to go. If you, like me, want to also run your own container registry on your tailnet, I wrote another article about that.
Using a ephermeral tailscale auth key, Tailscale will route traffic on our network to the accessory tailscale container that Kamal deploys for us. We use docker’s dns routing to point Tailscale’s Serve feature to the kamal-proxy container that Kamal deploys. Kamal’s proxy will check the hostname for us then route to the application container for our app. Because we’re deploying behind kamal-proxy, Kamal will handle zero downtime deploys for us, no configuration needed!
Kamal proxy routes via the hostname for you, so you can’t access these services via the IP address.
Kamal Proxy can handle multiple apps deployed to the same server. We register a different tailscale sidecar for each one to make our deployments simpler and each service can have it’s own identifier in our Tailscale Admin Dashboard. Requests to both services will run through the same kamal proxy container, who will route it properly via hostname.
# excerpts from my deploy.yml for Kamal
# my server is on tailscale as well
servers:
web:
- <server name>.<tailnet name>.ts.net
# To connect with Zot on my tailnet
build:
driver: docker
# tell the proxy my tailscale hostname
proxy:
# tailscale terminates the ssl connection
ssl: false
# same hostname as the tailscale sidecar
host: <service name>.<tailnet name>.ts.net
# rails port number
app_port: 3000
# rails takes a long time to boot on my little server...
healthcheck:
path: /up
interval: 5
timeout: 600
run:
# don't publish ports to the host machine,
# all the traffic will come through the docker network
# via the tailscale accessory
publish: false
accessories:
sidecar:
image: ghcr.io/tailscale/tailscale:stable
# for kamal, the host to run this sidecar on, same as servers.web configuration
host: <server name>.<tailnet name>.ts.net
files:
# I don't think directories works the way I way, so
# copy and mount the file directly.
- config/tailscale/ts.json:/config/ts.json
env:
clear:
TS_USERSPACE: false
TS_STATE_DIR: /var/lib/tailscale
TS_SERVE_CONFIG: /config/ts.json
TS_EXTRA_ARGS: --advertise-tags=tag:container
secret:
# loaded with .kamal/secrets
- TS_AUTHKEY
options:
# must be the same as the proxy's service name so tailscale and kamal proxy agree
hostname: <service name>
cap-add: NET_ADMIN
device: /dev/net/tun:/dev/net/tun
# derive the volume from the service name so we can have multiple tailscale sidecars on the same server
volume: <service name>-tailscale-state:/var/lib/tailscale
Since I’m only deploying personal web apps/containers with this setup, I tend to think of it as pretty ephemeral, but if you take the time with this (and maybe have a mirror), Zot is capable of being a complete container registry for docker images and any OCI Artifacts.
Zot has pretty good docs, and it’s pretty simple to setup too. We’re going to put it behind Tailscale, so if we’re a little lenient with some of the security options we should still be safe. Some of this is not best practices. At best, these are okay for a homelab setup when nothing is exposed to the internet.
In Appendix A, I have a bunch of configuration files to help get you started. Run the compose on any docker instance you want to use as your registry server. The server doesn’t need to be on your tailnet because we’ll put the registry on it directly.
Kamal requires a password be set for a registry it accesses through HTTPS, so you will need to setup a password to use in Zot.
You only need to set up Zot once, but Kamal you’ll configure for every project you want to deploy. I wrote another article that goes into more detail about the Kamal configuration for deploying on a Tailnet.
In Kamal’s deploy.yml file, the builder section must contain “driver: docker”. The docker driver has access to your machine’s DNS configuration, but Kamal’s default “docker-container” does not. I think this might change eventually, but I’m not sure. If you’re using a registry that doesn’t need Tailscale’s DNS to work, don’t worry about this setting.
I haven’t used a remote builder. I imagine it will need access to your Tailnet as well, to upload the built image. I think the docker driver limits the architectures we can build an image for, so remote might be important if your laptop and server have different architectures.
# example compose.yml with tailscale
name: registry
volumes:
registry-tailscale-state:
zot-data:
services:
sidecar:
image: ghcr.io/tailscale/tailscale:stable
hostname: registry
cap_add:
- NET_ADMIN
volumes:
- registry-tailscale-state:/var/lib/tailscale
- /path/to/configuration/directory:/config # holds the ts.json, below
devices:
- /dev/net/tun:/dev/net/tun
env_file: stack.env # put all the tailscale environment variables here
app:
image: ghcr.io/project-zot/zot:latest
depends_on:
- sidecar
volumes:
# zot configuration
- /share/Docker/stack-configs/ocireg/config.yaml:/etc/zot/config.yaml
# users and passwords
- /share/Docker/stack-configs/ocireg/htpasswd:/etc/zot/htpasswd
# where our images will be stored
- zot-data:/data/zot
command: serve /etc/zot/config.yaml
Example ts.json, Serve Functionality
{
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://app:8080"
}
}
}
},
"AllowFunnel": {
"${TS_CERT_DOMAIN}:443": false
}
}
# example Zot configuration, config.yaml
distSpecVersion: 1.0.1
storage:
rootDirectory: /data/zot
http:
address: 0.0.0.0
port: 8080
auth:
htpasswd:
path: "/etc/zot/htpasswd"
# accessControl:
# repositories:
# **:
# defaultPolicy:
# - read
# - create
# - update
# - delete
extensions:
ui:
enable: true
search:
enable: true
There are some niceties that I like to set up for myself. For example, the die function gives me an easy way to write checks
die() {
echo "$@" >&2
exit 1
}
[[ "$(git rev-parse --is-in-work-tree 2>/dev/null)" == "true" ]] || die "Not in git repo"
I often need to look up the string manipulations, but it’s so simple to read them.
VERBOSE="${VERBOSE:-false}" # set VERBOSE to false if it is unset or null.
Bash’s real super power over a traditional language is the input and output flexibility. Its control flow is second-to-none. The mechanism is super, super simple, strings all around really. But streams are the default, and they are powerful.
while read -r line; do
# run a command every time a notification is sent.
done < <(curl -sN https://ntfy.sh/test/json)
The thing on the last line there looks a little weird, doesn’t it? < <(command) is another super power of bash. How commands can be called. You can treat a file as a string, a string as a file, open a named pipe on your system for inter process communication, inline a script in another language, and more! Bash takes it all in stride. The only thing I’ve seen recently that comes close is WebOrigami.
A=3 B=3 node -e "console.log(Number(process.env.A) + Number(process.env.B))" # 6
# heredoc
cat <<EOF
This is a long
inline string with
enters, spaces and everything!
EOF
# herestring
json='{"this": "Test", "hello": ["sun", "moon", "world"]}'
hello="$(jq -n '.hello[2]' <<<"$line")"
I can even control the process forking of my command with ease. () for a subshell, $() for a subshell, piping stdout bach to me. <() for a subshell, giving me back a file descriptor for it. Functions run in my process automatically, but I can run them in a subshell if I want. Commands may run in a subshell automatically, but I other scripts I can source and run in my process instead.
Lastly, its simple I/O mechanisms are available in every language and it can call any executable on your system with ease, by name. I consider jq part of my basic toolset nowadays. And gum a close second. They’re installed on my system, I don’t need to import them every time. I wrote a parseargs package because I didn’t like the current options and know Node well, now I can call that easily as well! Eventually I’ll rewrite it in Zig to be faster, but my scripts won’t need to change at all.
The importing is a double edged sword, I know. It’s a reason to limit the amount of dependencies I use, luckily bash has a lot of good already in it! But some dependencies are worth convincing other people to use. I trust my taste here and so do my colleagues, but sometimes I will write helpers that don’t require others to have packages installed that I do.
log() {
if command -v gum &>/dev/null; then
gum log --structured --level info "$@"
else
echo "$@"
fi
}
There’s some syntax to learn with bash. It’s probably somewhere between Ruby and Perl in that. There’s no one place to go and learn about it. You probably only use it for quick, one off scripts and don’t fire your whole engineering brain making it robust. But read enough tips and tricks, try new things each time, and I think you’ll find yourself reaching for it more and more often given that you can find it almost everywhere and it is amazingly expressive.
]]>My wife wants to know when she’ll work a certain number of hours so she can take an exam. There’s a projection forward, but I also want to take into account days/hours she’s already worked and days that are out of the norm.
I could make one table with entries for all her hours worked, but then I need to track in that table which are a projection and which are “real”. Thinking myself clever, I decided the distinction warranted two tables. One for simple entries of hours worked and one to hold all the projections.
How do I fill in all those projection dates? I came up with a simple algorithm that basically takes all the week days and gives her 8 hours a day. I used a CTE to come up with this, then I was going to insert them into projections and go from there.
I made a table expression to insert data into a real table. But why not just use that expression in my calculation directly? If I have a algorithmic projection, what parameters could I change that would cause the calculation to update? Those parameters are what I want to store in a table!
If she’s works part time, I can tune that parameter directly instead of trying to reconcile what’s in the table with the new data I want. The SQL CTE will just recalculate it for me.
CTEs are super nice to iterate quickly, since there’s nothing stored to clean up. DBeaver has a nice concept of variables I used to help me decide what parameters should be part of my configuration. What I put in the DBeaver variables become columns in the table directly.
Now that I have a more stable idea of what I want, the next step is materializing it in the database. A View for my projection and a Table for my configuration. Both make the query a little more complicated, since now I have to get the configuration from a new table. But both will help make my final calculation, when will my wife hit her testing hours, easier. And we can tweak parameters until we’ve run through all the scenarios we want. Even generating a little rails app where she could tweak the parameters herself without wading through SQL code shouldn’t be too hard. If I need to change the projection, I can change the view. If we need more parameters, I can tweak the table.
It wasn’t my initial design, but CTEs helped me find my way to a more powerful solution.
]]>written after reading this article
3 are required to use the browser most effectively. 1 is required for solid data management. The last one is the only one we really get to choose. Even if we chose Javascript, I could agree it’s 5 languages: Node and other runtimes are very close but ultimately different environments for the same language and they should be treated differently.
In a production Node application, with a React frontend, we could easily double that count.
9 languages! 6 or 7 DSLs! Some are over top of others, but you write better JSX if you understand HTML better. Same for Panda and CSS, Prisma and SQL. For every DSL layer on top of a DSL doesn’t abstract it away as much as you’d think.
Would any templating language be considered a DSL? Something like Liquid or Nunjucks? They’re such simpler abstractions than JSX/React, you really get the semantics of the underlying DSL much, much more clearly. There’s hardly even another layer to think about. Ultimately they do require a little more knowledge, but they also don’t really know anything about the HTML layer beneath them. They could be used to template Javascript or SQL the exact same way.
More advanced templaters like ERB (with Rails) or Laravel’s Blade definitely feel like they spill over into DSL land. They start to feel more aware of the langauge they’re abstracting. Since they ultimately render down to HTML though, they’re still better at separating what they do vs the templated code than a React/JSX that tries to mix the two and bring a runtime into the mix.
Each person and group can decide for themselves and has a different tolerance for then. 10-15 years ago, React, SASS, etc. smoothed a lot of rough edges on the DSLs that make up web pages. But the platform has come a long way since then. For me, I prefer working with the DSLs directly and dropping into the full Javascript language when needed over just smoothing edges that aren’t rough or pointy anymore.
]]>I host a countdown timer for various friends and family’s weddings. Previously, it was an entirely static site I made for my own wedding, hosted on Github Pages. Then I changed it for the next wedding. But then I couldn’t see how long I had been married for!
I needed the barest amount of dynamic content on my page. I didn’t want to ship everybody’s wedding dates to the client, so it needed to happen server side. I make web apps (React, et al) for a living but that was just way too much (effort, code, time, etc) for what should be a simple problem, one interpolated date!
I had been testing Caddy to host my personal blog, a static website. It’s been performing phenomenally, I’m able to deploy faster to it (via rsync) than to SourceHut Pages most of the time. I had recently come across the Caddy templates module. For my blog, I was resistant to becoming too dependent on a feature like that, in case I needed to switch servers or something. But the concept was the exact right amount of complexity for my wedding countdown timer project.
It took me a few hours to adapt my static site: loading a json file server side then interpolating the date into my timer-element web component and deploying the changes on my public facing web server (adapting the Caddyfile I had there to host two sites at the same time!). But the end result? I’m very impressed! I was able to add a bunch more weddings to my site by adding lines to the json file. Everyone I texted about it was happy to see the counters to their weddings! It will last as long as Caddy does, I didn’t need to introduce or maintain any other moving parts.
For the future, I’m exploring templating via a CGI script. It’s slightly more work, but much more server agnostic. Luckily, caddy has a third party module to support CGI and an amazing build tool, xcaddy, to produce supporting binaries. We’ll see where my ideas take me, but I know I’ll be using Caddy for a lot in the future! Thank you Matt Holt for the amazing project!
]]>run script line by line.
First, the full file for reference
#!/usr/bin/env bash
# load our environment variables
source .env
# run our sidecar container
podman run --detach \
--hostname "$HOSTNAME" \
--name "$SIDECAR_NAME"\
--cap-add net_admin \
--device /dev/net/tun:/dev/net/tun \
--volume freshrss_tailscale_state:/var/lib/tailscale \
--env-file .ts.env \
ghcr.io/tailscale/tailscale:latest
# run our FreshRSS service
podman run --detach \
--restart unless-stopped \
--log-opt max-size=10m \
--network container:"$SIDECAR_NAME" \
-e TZ=America/New_York \
-e 'CRON_MIN=1,31' \
-v freshrss_data:/var/www/FreshRSS/data \
-v freshrss_extensions:/var/www/FreshRSS/extensions \
--name "$CONTAINER_NAME" \
docker.io/freshrss/freshrss
The first few lines are just bash setup.
#!/usr/bin/env bashsource .envsource command loads those variables into our current process. We could put any bash in there, but by convention we’re only setting variables.podman run --detach \
--hostname "$HOSTNAME" \
--name "$SIDECAR_NAME"\
--cap-add net_admin \
--device /dev/net/tun:/dev/net/tun \
--volume freshrss_tailscale_state:/var/lib/tailscale \
--env-file .ts.env \
ghcr.io/tailscale/tailscale:latest
podman run --detach--hostname "$HOSTNAME"--name "$SIDECAR_NAME"--cap-add net_admin--device /dev/net/tun:/dev/net/tun--volume freshrss_tailscale_state:/var/lib/tailscale--env-file .ts.envghcr.io/tailscale/tailscale:latestFreshRSS is our main service in the example, but it could be any container you want to run on your tailnet.
# run our FreshRSS service
podman run --detach \
--restart unless-stopped \
--log-opt max-size=10m \
--network container:"$SIDECAR_NAME" \
-e TZ=America/New_York \
-e 'CRON_MIN=1,31' \
-v freshrss_data:/var/www/FreshRSS/data \
-v freshrss_extensions:/var/www/FreshRSS/extensions \
--name "$CONTAINER_NAME" \
docker.io/freshrss/freshrss
podman run --detach--restart unless-stoppedunless-stopped will always try to restart the container unless we explicitly run stop to stop the container. Not really necessary here, since the tailscale sidecar won’t restart this way. But we could have that too if we wanted.--log-opt max-size=10m--network continaer:"SIDECAR_NAME"-e TZ=America/New_York-e 'CRON_MIN=1,31-v freshrss_data:/var/www/FreshRSS/data-v freshrss_extensions:/var/www/FreshRSS/extensions--name "$CONTAINER_NAME"docker.io/freshrss/freshrssdocker.io on the front here; docker sets this by default if you don’t use it. Other container engines require the full uri (but have settings where you can set defaults).That’s the entire file, line by line! Of course you can read all about all these options and more in the docs but hopefully this was a nice little tutorial of all of them in plain English for you. Container engines have a lot of options and the best way to learn is by practice.
Like a pod of seals, float on!
]]>There’s a lot to Tailscale that facilitates this magic. First, the Tailnet name means you can give each container a name. It’s easy to identify on the Tailscale Dashboard, it’s easy to type into a URL bar, it’s as easy to use as any URL! Second, OAuth tokens make it simple to connect containers (not just machines!) into your Tailnet. Third, HTTPS certificates mean web services behave like you would expect. They look secure in the browser and have access to secure context APIs. Lastly, Tailscale Serve proxies you to the correct port in your container.
Those services together make the experience pretty seamless to connect, once you know how all those pieces fit together. This post will walk you through all the steps you need to set this up today. We’ll be using FreshRSS as the service we’re proxying. I’m not going to use docker compose. Instead, I’ll be using podman and a handful of bash scripts to connect our containers together. This way, the tutorial will be a little more generic and should work for any oci compliant engine (docker, podman, nerdctl, etc).
~/services/freshrss-sidecar would be great. All files and folders will be created in this directory.If you skip this step, podman will pull these the first time we run the container. Either way is fine!
# pull tailscale
podman pull ghcr.io/tailscale/tailscale:latest
# pull freshrss
podman pull docker.io/freshrss/freshrss:latest
This .env file will hold a few configuration variables we can share across our bash scripts. You can parameterize more or less, but this is a good start. HOSTNAME is how we’ll reference it on our tailnet at the end.
# file: .env
SIDECAR_NAME="freshrss_tailscale"
CONTAINER_NAME="freshrss"
HOSTNAME="rss"
Next, create a .ts.env file. This one will hold all the environment variables our tailscale sidecar container needs to connect to our tailnet. We can fill in everything in this file but our TS_AUTHKEY argument. We’ll generate that shortly.
# file: .ts.env
TS_AUTHKEY=tskey-client-notareal-tailscaleoauthtoken
TS_EXTRA_ARGS=--advertise-tags=tag:container
TS_STATE_DIR=/var/lib/tailscale
TS_USERSPACE=false
TS_SERVE_CONFIG=/config/ts.json
In your Tailscale dashboard, go to DNS and find your Tailnet name. Tailscale uses yak-bebop as their example. You can’t pick the one you want (only generate it), and you also can’t change it once you turn on HTTPS. So take some time to generate one that you like. I like a fun name, but you can pick the default too!
We can make most of this tutorial work without HTTPS, so we won’t turn it on until the end.
An [OAuth client] gives you a more secure way to connect to your tailnet versus and Auth Key. Before we can generate the token, we need a tag to give our container. The official docs give a good reference for defining a tag. My short version: go to Tailscale Access Controls tab and add an entry under the tagOwner key named tag:container:
"tagOwners": {
"tag:container": ["autogroup:admin"],
},
Save that with the button beneath and now we have a group we can assign the OAuth token to. So head over to your Tailscale Settings page, the “OAuth clients” option along the sidebar and click the “Generate OAuth Client” button. Type a description like “FreshRSS Test Token” and make sure you give it the “Devices:Core” and “Keys:Auth Keys” write permissions. Make sure you have the tag:container that we just created chosen under the “Add tag” dropdown. It should automatically assign to the second permission if you’ve set it for the first one.
Remember, “Devices:Core” and “Keys:Auth Keys” write permissions, assigned to your new tag, tag:container!
Click “Generate Client” and copy the key it gives you into your .ts.env file. You’ll never see this key again, but if you lose it just delete this one and regenerate a new one. The TS_AUTHKEY line should now have your auth token in place of our previous placeholder, giving you a file that looks like:
TS_AUTHKEY=tskey-client-yournew-tailscaleoauthtoken
TS_EXTRA_ARGS=--advertise-tags=tag:container
TS_STATE_DIR=/var/lib/tailscale
TS_USERSPACE=false
TS_SERVE_CONFIG=/config/ts.json
Now we have everything we need to run our container and access it over http. We need two containers, so we’ll write a short script to help coordinate it. I call it run, to mimic the podman run command. It will create 3 volumes, use the images we pulled in the first step, and our .env and .ts.env files to load everything up.
#!/usr/bin/env bash
# load our environment variables
source .env
# run our sidecar container
podman run --detach \
--hostname "$HOSTNAME" \
--name "$SIDECAR_NAME"\
--cap-add net_admin \
--device /dev/net/tun:/dev/net/tun \
--volume freshrss_tailscale_state:/var/lib/tailscale \
--env-file .ts.env \
ghcr.io/tailscale/tailscale:latest
# run our FreshRSS service
podman run --detach \
--restart unless-stopped \
--log-opt max-size=10m \
--network container:"$SIDECAR_NAME" \
-e TZ=America/New_York \
-e 'CRON_MIN=1,31' \
-v freshrss_data:/var/www/FreshRSS/data \
-v freshrss_extensions:/var/www/FreshRSS/extensions \
--name "$CONTAINER_NAME" \
docker.io/freshrss/freshrss
Make the file executable by running chmod +x run, the run the script with ./run. Or you can call bash run and not need to run the chmod command.
Shortly, we should see a “machine” with the tag:container under our Tailscale Dashboard’s machine tab called “rss”.
Navigate a web browser to http://rss.${tailnet-name}.ts.net (eg, http://rss.yak-bebop.ts.net) from your tailnet connected computer and you should see the FreshRSS welcome page! Because we don’t have https certificates working anyway, you could use http://rss to go to the same site, but the short names don’t work with HTTPS certs so stick with the longer version.
You could be done at this point, but Tailscale Serve ensures you can work with many different container ports and HTTPS Certs will make your experience much better in a modern browser.
This is the last configuration we need, Tailscale Serve. Tailscale won’t provision a TLS cert for us without this. And the config will tell tailscale what port to proxy to, so we don’t need to type that into our browser either. We didn’t need a port number with FreshRSS because it exposes itself on the correct port, port 80. But for most services we’ll want this set up. And 80 is the wrong port for https (that’s port 443). Make a config directory with ts.json in it, to mount to our tailscale sidecar container. Under the Proxy key is where you would set the port for your service; FreshRSS is on port 80.
{
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://127.0.0.1:80"
}
}
}
},
"AllowFunnel": {
"${TS_CERT_DOMAIN}:443": false
}
}
Since this serve config tells Tailscale to generate a https certificate for us, let’s turn that on in Tailscale before we use it.
In your Tailscale Dashboard, go to the DNS tab and scroll to the bottom. Click Enable HTTPS and go through any of its prompts. Done! Now let’s return to the terminal and restart these containers. The official docs are easy to follow for this step.
Our service container, freshrss, depends on the tailscale sidecar to function. That means we can’t stop tailscale until our freshrss container has stopped. Let’s write a small script to help us always stop the containers in the correct order. Call it stop to again mimic the podman cli.
#!/usr/bin/env bash
# reuse our envvars to get the container names
source .env
podman stop "$CONTAINER_NAME"
podman stop "$SIDECAR_NAME"
Then, we can also make a rm script to fully remove the containers. This could be one script, but I like breaking it into two for a few reasons. One, I might not always want to fully remove the containers. Two, it mimics the podman cli which has pretty good ergonomics for all its power.
#!/usr/bin/env bash
source .env
podman rm "$CONTAINER_NAME"
podman rm "$SIDECAR_NAME"
We need to add a line to our run script to mount the tailscale serve config, making the full file:
#!/usr/bin/env bash
source .env
podman run --detach \
--hostname "$HOSTNAME" \
--name "$SIDECAR_NAME"\
--cap-add net_admin \
--device /dev/net/tun:/dev/net/tun \
--volume freshrss_tailscale_state:/var/lib/tailscale \
--volume "$(pwd)/config":/config \
--env-file .ts.env \
ghcr.io/tailscale/tailscale:latest
podman run --detach \
--restart unless-stopped \
--log-opt max-size=10m \
--network container:"$SIDECAR_NAME" \
-e TZ=America/New_York \
-e 'CRON_MIN=1,31' \
-v freshrss_data:/var/www/FreshRSS/data \
-v freshrss_extensions:/var/www/FreshRSS/extensions \
--name "$CONTAINER_NAME" \
docker.io/freshrss/freshrss
After all that, run the stop script, then the rm script, then the run script again. You should see everything come back up and work, with any state/login/rss feeds you already setup in FreshRSS!
If we delete the “freshrss_tailscale_state” volume, tailscale won’t be able to reuse the same hostname. Instead you’ll end up seeing “rss-1”, “rss-2”, etc. in your list of tailscale machines. To rememdy this, just use the tailscale dashboard to remove those machines, delete the “freshrss_tailscale_state” volume again and rerun the run script to reset the tailscale hostname
If you can’t see the rss machine, or it isn’t connected, run podman ps -a to get a list of all the containers, including stopped ones. If you can see it has exited, you can run podman logs freshrss_tailscale to see what error messages it might have thrown.
Now that we have the container up and running, there’s more we can do to automate! Podman has a great Quadlets feature that will run this all via systemd for us, adding a lot of resiliency. We can add more envvars to our .env file to make our scripts more configurable. We could write an up script to mimic a docker compose up style command. We could automate backing up FreshRSS by copying out the volume data somewhere. We could automate upgrades using podman rename before spinning up a new instance and inserting it where the old one was.
We could enjoy our FreshRSS instance and download a reader like Capy Reader to use it on our phone.
There are so many possibilities! I hope you enjoyed this tutorial.
]]>I never really liked their editors, even their Markdown or Spreadsheet ones. They didn’t feel good, especially on mobile. Like they were making as many as possible, but not refining any of them. So I always used the plaintext editor, even when typing in Markdown.
I didn’t want to fall into the hamster wheel trap of the next new note taking app. Standard Notes stored and synced notes like I needed. Migrating notes to a new experience every couple of months would be such a pain, especially into a new format. And just to try some other editor that will probably charge me money to sync.
A lot has changed in the time since I started using Standard Notes. I’ve gotten less strict about a E2E solution for everything. I favor open standards over the encrypted stuff now, in many cases. I switched email providers from Proton Mail to Fastmail (again, a big UX choice). I’ve learned much more about self hosting and have gotten more comfortable with how to put things on the web (including this blog). And it has been 4 or 5 years since I’ve changed notes apps, Standard Notes hadn’t changed much in that time.
I had heard about Obsidian on a couple podcasts, but mostly ignored it. I was setting up a new laptop at work, where I used the free version of Standard Notes, and decided this would be a good time to give it a try. The promise of all my notes being Markdown files on my computer was super cool. I figured I could script against them myself even! I don’t need any syncing at work, it’s just the one computer.
And wow, I was blown away! A few weeks in and I’m still amazed at how open Obsidian is, how responsive Obsidian is, and how many great features they’ve packed in. I’ve even taken a look at CodeMirror, and might use it in future projects.
I liked it so much at work I decided to download it on my Android phone and see if it could live up to my hype there. And it nailed it! Really just wonderful. The obsidian links make it easy to extends via macros and the markdown looks great.
So I also downloaded it on my laptop too. But now I needed a way to sync between my phone and computer. Since I’ve begun to self host other things, I started to look into that. But they all seemed like they might be a lot of work, I didn’t want something that would be more maintenance than useful.
I looked into the official Obsidian Sync, which costs about the same amount as my Standard Notes subscription at $4/mo. But by now my imagination was going wild with embeddable photos and who knows what else! The official plan only gave me 1GB and sharing with my wife would be another $4/mo for her.
As I was looking at the possibilities, I stumbled into WebDAV as an option via the RemotelySave plugin . My experience with the DAV protocols are somewhat mixed. They’re powerful but tough to use. Fortunately, my Fastmail email has a full WebDAV server. You can even view the files in their app! And my account comes with 10GB of storage, plus I could have my wife just log in with a different app password.
Coming back to this complaint from above, I haven’t migrated much yet. Standard Notes will give me my notes in a .txt, and Obsidian will automatically recognize those if I change them to a .md extension. Some of the titles might be mangled and I might lose some metadata. But I had very little metadata, and titles can be repaired.
I’ve realized that maybe most of my notes are fairly transient anyway. The posts on this blog have a little more staying power, I think. So this is a work in progress, who knows how much I’ll end up moving over.
Time will tell how long this version of note taking lasts for me. But Obsidian is an amazing product and RemotelySave with Fastmail makes it so easy to sync that for now, this is definitely a winner.
]]>I work at a start up small enough that there are no defined levels or strict job titles, so when I heard about the tongue in cheek “part stack” I decided it would be a fun title to give myself. It’s supposed to be a joke on “Full stack Developer” job titles where they mean “front end web pages/SPA and backend application servers,” which feels like a majority of job postings.
But there’s also a whole stack of computers and services to serve your application, why aren’t those considered part of a full stack engineer’s job? I think of that as an Operations role, so maybe those pieces fall under a “DevOps Engineer” title, which smashes the “developer” and “operations” roles together. Maybe all together that’s a “Full Stack DevOps Engineer”?
Of course, all of these vary by company and HR department. And luckily there’s a job description and interview process where companies and prospective employees can get a better understanding of what a role might entail. We know what all of these titles mean, to a certain degree, so what is a Part Stack Engineer?
I work on the part of the stack that drives your business and serves your customers. I can take a website/web application from Hello World to IPO. I can launch a site if you’ll give me a bare metal server or VPS to deploy it on. I can build an application server capable of scaling to meet your demand, making it secure and observable. I can write HTML/CSS/JS to make your website look and feel like the brand you want to present.
If you noticed that everything on that list is related to the web, you might also remember my job title includes “Web Dev.” I would happily call myself “Web Engineer,” I don’t mean to debate developer vs engineer here. Web Dev just rolls off the tongue better than Web Eng. The “web” part is important to me. We live in a world where you want your data to be accessible on your laptop, and your phone, and maybe a work computer, tablet, etc. It has to live somewhere, so a server (yours or mine) is a good place to live. HTTP/WWW is definitely the dominant paradigm for accessing those kinds of things, everybody has a web browser.
Having a web server also deliver the markup makes the whole thing so much more straightforward to develop; you’ll save 100s of hours a year of developer time. There are similar projects for mobile apps. I can deliver a mobile ready website, but an app is one of my weakest areas. So I stuck the “Web” part in my self-proclaimed title because my works revolves around the web.
The web encompasses a lot of modern consumer computing. Any part of that stack is something I am interested in. At this point, 6 years into my professional programming career, I think I have at least a passing familiarity with most of it. And plenty of experience to plan, build, deploy, and operate a web application. So I call myself a “Part Stack Web Dev,” a title I think encompasses a majority of my experience and interests.
PS, if you think you know where “Part Stack” came from, I’d love to know so I can link to it from here.
]]>