LEdoian's Blog

How to convert CBZ to PDF

2024-02-17T16:55:00+01:00

Extract the archive (cbz is just a zip, cbr is a rar, …)
Convert individual pictures to PDF using img2pdf
- Many other ways including convert from ImageMagick tend to do weird stuff like breaking aspect ratios or adding margins
Merge files into the single PDF, e.g. using qpdf --empty --pages *.pdf -- output.pdf.

References

Why

My eBook reader (PocketBook Touch Lux) does not seem to be able to handle cbz.

Do not forget about IPv6 DNS

2024-01-24T03:20:00+01:00

Do you think IPv6-only internet works OK? I am going to tell you that it does not, but it is not immediately visible. TL;DR: The internet can be broken also by forgetting to add AAAA records of the nameservers. This creates IPv4 requirement for the resolving even when the target is reachable using IPv6.

Quick recap

Connecting to a website is easy, right? You type in the name, you get the front page.

This is a very naïve idea of connecting to a server.

OK, it is a bit harder: the computer needs an IP address, so we need to use this magic box called DNS. The flow looks something like this:

Slightly better, now we at least know the machine-readable address.

And for IPv6-only everything on the picture has to have IPv6 connectivity and AAAA DNS records.

Reaching IPv4 land from IPv6-only

There are few^H^H^Hmany sites that still only support IPv4. To reach them, we need someone who can reach both the IPv4- and IPv6-land to go there on our behalf – a proxy. This proxy can be ad-hoc (I often use ssh -D) or there are well-known protocols like NAT64 with DNS64 to do that in a standard and lightweight manner. [1] In that case, the connection looks like this:

And now we can reach the whole internet.

You might already know that you need some workaround like this to reach GitHub. What I think you might not know, you need similar workaround to reach the Wikipedia.

Disclaimer: I like Wikipedia and this is not meant to shame them, just use as an example. I am aware of several other sites suffering from the same problem, including at least one IPv6 test. [2] (It would be nice if they added the missing piece in the puzzle, though.)

Enter DNS

Our picture has one unexplored magic box: the DNS. As per the definition (which I just made up and was not bothered to even fully formulate):

yada yada distributed database of records attached to the strings – domain names. The records hold various information about the domain depending on the type.

There are three interesting types of records: A records give IPv4 addresses, AAAA give IPv6 addresses and NS give names of servers who know about the particular subtree of the database. And to actually resolve the final AAAA record the (recursive) resolver starts at the root zone and tries to find the answer. [3] The resolution algorithm can be visualised like this:

Yeah, it's a mess.

There is one extra tricky bit: the NS records contain names, not addresses, so when resolving we need two queries for each layer (very simplified): first we ask for the final domain (blog.ledoian.cz) and get a NS record (when the server does not have the answer) and then we need to ask for the A or AAAA record of the name from that record, so that we can connect to the server mentioned in the NS record. (This allows a nameserver to be made redundant and/or reside on other types of network.)

You might start to see the issue. When the DNS was just a black box, we could paint the whole picture green and call it a day. And from the regular user's point of view, that is the case, just use some public DNS like 1.1.1.1, 8.8.8.8 or 9.9.9.9. Oh, right, I meant these easy-to-remember addresses: 2606:4700:4700::1111, 2001:4860:4860::8888 and 2620:fe::fe, respectively. The point is, they will give you the answer because they are dual-stack, not IPv6-only.

In a way, those servers (or other dual-stack resolvers) act like another proxy, similar to the SSH, NAT64 and NAT44 ones mentioned earlier. This may not be much of a problem for many people. But if you have any reason to use your own recursive DNS server (privacy reasons, DNSSEC validation, ISP provides bad service, you are the ISP, …) inside an IPv6-only network, you will have issues. [4]

Example: Wikipedia

Let's now see this in action. You know Wikipedia, right? And you can reach Wikipedia on IPv6, right? It has an AAAA record (don't mind the CNAME, that means that the server is really called some other way):

$ dig en.wikipedia.org AAAA
[…]
en.wikipedia.org.   18737   IN      CNAME   dyna.wikimedia.org.
dyna.wikimedia.org. 323     IN      AAAA    2a02:ec80:600:ed1a::1

And this record does work:

$ ncat --ssl 2a02:ec80:600:ed1a::1 443 <<GO
GET /wiki/Main_Page HTTP/1.1
Host: en.wikipedia.org

GO
HTTP/1.1 200 OK
[…]
content-language: en
content-type: text/html; charset=UTF-8
content-length: 98078

<!DOCTYPE html>
[…]

But we can dig deeper: let's see what servers we are really asking:

$ dig en.wikipedia.org AAAA +trace

; <<>> DiG … <<>> en.wikipedia.org AAAA +trace
;; global options: +cmd
.                   78918   IN      NS      e.root-servers.net.
.                   78918   IN      NS      f.root-servers.net.
.                   78918   IN      NS      g.root-servers.net.
.                   78918   IN      NS      h.root-servers.net.
.                   78918   IN      NS      i.root-servers.net.
.                   78918   IN      NS      j.root-servers.net.
.                   78918   IN      NS      k.root-servers.net.
.                   78918   IN      NS      l.root-servers.net.
.                   78918   IN      NS      m.root-servers.net.
.                   78918   IN      NS      a.root-servers.net.
.                   78918   IN      NS      b.root-servers.net.
.                   78918   IN      NS      c.root-servers.net.
.                   78918   IN      NS      d.root-servers.net.
;; Received 525 bytes from … in 0 ms

org.                        172800  IN      NS      c0.org.afilias-nst.info.
org.                        172800  IN      NS      a2.org.afilias-nst.info.
org.                        172800  IN      NS      a0.org.afilias-nst.info.
org.                        172800  IN      NS      b0.org.afilias-nst.org.
org.                        172800  IN      NS      b2.org.afilias-nst.org.
org.                        172800  IN      NS      d0.org.afilias-nst.org.
;; Received 788 bytes from 202.12.27.33#53(m.root-servers.net) in 24 ms

wikipedia.org.              3600    IN      NS      ns0.wikimedia.org.
wikipedia.org.              3600    IN      NS      ns1.wikimedia.org.
wikipedia.org.              3600    IN      NS      ns2.wikimedia.org.
;; Received 658 bytes from 2001:500:48::1#53(b2.org.afilias-nst.org) in 20 ms

en.wikipedia.org.   86400   IN      CNAME   dyna.wikimedia.org.
;; Received 94 bytes from 208.80.153.231#53(ns1.wikimedia.org) in 132 ms

Hey, there are IPv4 addresses in there! I know, this is cheating, the output is from a dual-stack machine. But we can still simulate IPv6-only resolution by adding -6 flag:

$ dig en.wikipedia.org AAAA +trace -6

; <<>> DiG … <<>> en.wikipedia.org AAAA +trace -6
;; global options: +cmd
.                   78915   IN      NS      d.root-servers.net.
.                   78915   IN      NS      e.root-servers.net.
.                   78915   IN      NS      f.root-servers.net.
.                   78915   IN      NS      g.root-servers.net.
.                   78915   IN      NS      h.root-servers.net.
.                   78915   IN      NS      i.root-servers.net.
.                   78915   IN      NS      j.root-servers.net.
.                   78915   IN      NS      k.root-servers.net.
.                   78915   IN      NS      l.root-servers.net.
.                   78915   IN      NS      m.root-servers.net.
.                   78915   IN      NS      a.root-servers.net.
.                   78915   IN      NS      b.root-servers.net.
.                   78915   IN      NS      c.root-servers.net.
;; Received 525 bytes from … in 0 ms

org.                        172800  IN      NS      d0.org.afilias-nst.org.
org.                        172800  IN      NS      c0.org.afilias-nst.info.
org.                        172800  IN      NS      b2.org.afilias-nst.org.
org.                        172800  IN      NS      a0.org.afilias-nst.info.
org.                        172800  IN      NS      b0.org.afilias-nst.org.
org.                        172800  IN      NS      a2.org.afilias-nst.info.
;; Received 816 bytes from 2001:500:2::c#53(c.root-servers.net) in 8 ms

wikipedia.org.              3600    IN      NS      ns0.wikimedia.org.
wikipedia.org.              3600    IN      NS      ns1.wikimedia.org.
wikipedia.org.              3600    IN      NS      ns2.wikimedia.org.
couldn't get address for 'ns0.wikimedia.org': not found
couldn't get address for 'ns1.wikimedia.org': not found
couldn't get address for 'ns2.wikimedia.org': not found
dig: couldn't get address for 'ns0.wikimedia.org': no more

Some of those IPv4 addresses were benign – the respective servers are reachable both using IPv4 and IPv6 address or there is an alternative server that is reachable using IPv6. That is the case for the root nameserver – in the second case, we used C, which has IPv6 address (2001:500:2::c). In fact, the M server also has IPv6 address, but dig chose the IPv4 one (it should not matter):

$ dig m.root-servers.net AAAA
[…]
m.root-servers.net. 77991   IN      AAAA    2001:dc3::35

But the latter case is the bigger issue. For the domain wikipedia.org there are three nameservers:

$ dig wikipedia.org NS -6
[…]
wikipedia.org.              86400   IN      NS      ns0.wikimedia.org.
wikipedia.org.              86400   IN      NS      ns1.wikimedia.org.
wikipedia.org.              86400   IN      NS      ns2.wikimedia.org.

This is the last answer that we could get on an IPv6-only network, because none of these three servers has AAAA record (some of them may have IPv6 address unknown to us):

$ dig ns0.wikimedia.org AAAA
[…]
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59468
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

The NOERROR status says the domain name exists, but we got zero answers for AAAA records. This is the case for all three nameservers. And here is the ultimate picture of what is happening and what goes wrong.

The breakage in action

Also note that the connection from the laptop to the DNS resolver may in fact consist of a chain of several (caching, non-recursive) DNS resolvers, so that the final DNS resolver can have dual-stack connectivity.

The problems with this state

So, what is the deal. We just need to have a dual-stack DNS resolver somewhere, and that's it, no? Well, yes but actually yes.

There are two problems with this: First, this means that any new ISP needs to have at least some IPv4 address, even if they intend to just use IPv6 services. IPv4 addresses are scarce, expensive and small blocks don't route well, which is not great both from the new ISP's and from overal routing's point of view. It also hinders IPv6 deployment and postpones IPv4 abandonment, needlessly.

The second issue is that this is not very visible. We are building IPv6 world, but deep inside it still relies on IPv4, which might lead to great surprise when we start cutting off IPv4 internet. And it might lead to false sense of having IPv6 deployed, which is not true to the whole extent.

Insert "It was DNS" meme here.

Solution

The solution of this state is simple: get IPv6 connectivity to your authoritative DNS server (or use another) and do not forget to add an AAAA record for it in DNS. If the DNS server already has IPv6 it is probably just a matter of adding a single line to the zone file (and a second one for the DNSSEC signature), which should not be a big deal.

Unfortunately, this needs to be done for the whole DNS chain. Especially domain names at universities are infamous for very nested domains. A domain name may look like machine.department.location.faculty.university.some-common.suffix. That tree is deep and so is the resolution of this problem.

Amusing bug of almost good deployment

We have seen there may be multiple NS records for a domain and thus multiple nameservers. This is good for redundancy. But this does not mean that the servers will have the same records – they are only supposed to give equivalent answers (as far as I know).

I have come across a silly misconfiguration: a domain which has several nameservers, which serve a slightly different set of NS records for its subdomain. Specifically, the servers which were only reachable using IPv4 were exactly the servers that knew about one additional nameserver for the subdomain, which, incidentally, was the only one that was IPv6-capable.

So, while all the correct records were present in DNS (somewhat/somewhere), this still meant that IPv6-only resolution was doomed to fail because the IPv6 nameserver chain was broken. (This has already been fixed.)

[1]	This is very much the same as when you try to reach the IPv4-public-land from IPv4-private-land, that is, from a private range of IP addresses. This is called either just NAT, or NAT44 to denote IPv4-to-IPv4 NAT.

[2]	There are several more tests that do not even have the AAAA record, lol.

[3]	In my example, there is a single recursive DNS resolver external to my machine in order not to complicate it too much. The real deployment is often trickier.

[4]

I have not yet tried to run a recursive DNS in a network with DNS64 and NAT64. Could be fun :-D My wild guess is that I would need CLAT (i.e. the full 464XLAT deployment) to make that work, since the resolver is connecting directly to IPv4 addresses and would need to learn to use NAT64 to resolve them. (The CLAT could be built right into the resolver, though).

About this blog

2024-01-10T16:47:00+01:00

This is my blog and this article describes its setup and other details about my intentions. The actual setup is probably the most interesting tech-wise.

What is this?

My own space on the internet where I can post whatever and link others to it. It might end up containing rants, guides, ideas, or maybe nothing at all in the end. Only the future will tell.

The blog might even serve as my personal web page/introduction. Maybe. Maybe not…

The main motivation is to have low-effort way to post random stuff. Which leads to my requirements for this thing.

Requirements

(The requirements are a bit too idealistic, so not all of them were satisfied…)

low-effort, me-friendly, low-maintenance – I don't want to have to learn too many new technologies to use this. This includes the required technologies: Python, Markdown/reStructuredText, Jinja2, git, …
Technical and math content ~~friendly~~ compatible – I expect that to appear here.
Static site – for security, coolness factor and control. Also static on the front-end, because I don't like JavaScript and/or running untrusted code on my machine (even when in a sandbox). The SSG should likely be aimed at creating blogs, not documentation. Also, self-contained, as in not depending on third-party sites.
No moving parts in the infrastructure (or as few as possible) – if it works on my machine, it should just get mirrored to the public site with as few modifications as possible.
Transparent – I should be able to understand it, maybe others could also use it as a resource or take inspiration. (At one point, this deployment itself started being interesting, so if I can share the background as well as the final webpage, it would be cool.)
Followable – I know you internet guys like to ~~stalk~~ follow people :-)
Aligned with my values: minimalist, simple, extensible/hackable, FLOSS
If the platform could distinguish translations and do strikethroughs, it would be nice, but that is not a hard requirement.

There are several features of conventional blogs that I consider to be a non-goals or even anti-goals. Mostly it is about interactivity – I don't aim for having any kind of comments here, or really anything that would require JavaScript or complex HTML/CSS. And appearance goes past me as well, I instead try to let the browser decide how to display this page – more on that below.

The workflow I wanted to achieve is something like: Write the content, git it, build it (locally, no CI/CD), push it, done. Single write, single push, very simple.

And I managed to achieve something like that, via learning (too much?) about git.

The setup

Naturally for a sysadmin/netadmin, the setup consists of 7 ~~ISO/OSI~~ layers:

Physical layer: cheap Hetzner VPS. Not physical, but whatever.
Network layer: Nginx
Persistence layer: this git repo. I will elaborate below why can you see this both rendered here and in the source form in Forgejo.
Content layer: Markdown or reStructuredText files.
Business logic layer: Pelican. It's rather popular and written in Python, I didn't look further.
Presentation layer: I hacked my own theme, because I didn't like any in the pelican-themes repo. I was a bit inspired by the layout of eevee's blog, but I wanted a dark theme. And as you can see, I can't do quality frontend, so it ended up horrible… :-D
Stalking layer: Pelican's built-in RSS and Atom feed generators. Not linked from anywhere at the moment, but the repo will tell you what hides under the /feeds/ path. Or you can utilize the repo (for personal use – the content's license is not decided at the moment)…

Most of this is straightforward, the fancy part is my repo. The repo contains both source and rendered content, so that I can point Nginx right at a checkout and have Git solve both persistence and deployment without additional moving parts.

There are two tricks in the configuration of Git repositories: pushing to a checked out repo is enabled by configuring receive.denyCurrentBranch = updateInstead in the target repository (which is just a normal repo, not a bare one), and then I just told my source repositories [1] to use two push targets for the remote (the first line replaces the original push address for some reason):

git remote set-url --add --push blog_remote gitea@gitea.ledoian.cz:LEdoian/blog.git
git remote set-url --add --push blog_remote blog_user@blog.ledoian.cz:blog_dir

The blog user is just a user with SSH access via authorized keys, no special sauce there. Nginx is then pointed to serve ~blog_user/blog_dir/output/ at blog.ledoian.cz. (The git-remote(1) manpage requires me to have both repositories in sync, but as long as I configure all my repositories this way, I should be safe, and I think I could get away with my blog checkout getting behind accidentally.)

My workflow and lots of drafts

It's Git so it's only natural for me to use various branches and repositories even for a dumb blog. There are in fact 4 stages an article may go through [2]:

A private draft: lives on a branch priv/something, may contain private infos (like when I would just copy-paste from terminal without redaction) and this branch will probably never be merged to the main repo. Nothing about these branches is guaranteed.
A public WIP draft: uses a branch called pub/something which is pushed to Forgejo (and in fact also to the blog itself, but that is just an implementation detail). The draft is either does not build or is very incomplete and I expect to add stuff in a way that could break the build, so I put it on a separate branch. The branch will be probably merged to the main branch (called blog) when it is ready.

The pub/… branches can be created either manually or by cherry-picking from the respective priv/… branch, but that will likely not be distinguishable. (I am too lazy to keep the references even in the commit logs.)
When a draft is almost ready (or the content has simple syntax), it gets placed on the blog branch. The only thing that designates it as a draft is status: draft in the frontmatter, which means that the article will get rendered and put somewhere on the public blog, but not reachable from the title page ("unlisted").
Of course, eventually (and hopefully) the article gets published for everyone to see. At that point, it is complete (or at least that is what I thought when marking it as published). Possibly it might be updated in the future, but no such update is anticipated at the moment of publishing. [3]

I use Git to synchronize my private branches among machines, so there are actually two "server-side" repositories (private and public one) and thus two remotes. [4]

As for the actual workflow, for the main branch it usually consists of: writing content, committing it, building the web, checking it locally, committing the built blog and pushing it. Sometimes I do the commits together, but I always separate the rendering/building commits from the content-creating ones, so that I can handle those differently if needed (i.e. there is no point in cherry-picking the built content, I can generate it). [5]

For other branches I use some applicable subset of the steps above, probably.

Design considerations

The appearance of the blog is maybe not nice. That is for two reasons: I don't have the right idea about how to make it much better and I want to have a rather simple CSS for the web. The latter wish is because I tend to tweak appearance of sites I visit using my own styles, so I would like you to be able to do the same.

And for the former reason, if you have any ideas / improvements (including user styles), hit me at blog@pokemon.ledoian.cz :-)

My overall idea is a dark-by-default [6] minimalist page with a single menu on the right containig all the relevant links. The page should not dictate too much but rather let the user agent decide the rendering (it does anyway…).

I want my blog to render similarly in Gecko-, WebKit- and Blink-based browsers (e.g. Firefox, Badwolf, Qutebrowser). Others should be usable. Browser-/engine-specific styles are not welcome – let's keep it simple. And no JavaScript…

Work in progress / TODOs

This thing is at the moment very barebones, which is sufficient for the main purpose. However, I would like to have some features here, one day, hopefully:

Dates in the article headers (and maybe more improvements of the theme, see above)
Stable category and tag names and a page with a description of them. As of now I haven't really invented a system of sorting my content, which leads to a mess… Please don't rely on categories having any particular name / URL for now.
Link the RSS feeds from somewhere
Personal info with links to my other profiles
Some linking to the Fediverse and using it for comments (since there will be no comments here)
Sensible translations, maybe (if I/someone ever get to write the same content again in a different language…)
Improve the list of talks I've given (create some kind of sensible table maybe?)
Decide on a licence for the content (If you want to utilize something here before I do that, please ask me, I think we can find a way :-))

If you are so upset with this blog (or maybe bored) that you want to improve it, send me patches / ideas. I don't expect anyone to do that, though :-D (And I do not promise you that I will use the patch, even if it matches all my opinions above. I also have some gut feelings about what I like…)

Also, tell me if you hate something else about my page. I want to at least know whom I upset :-D (but I will probably also think about your gripes and whether I can and should try to avoid them…)

[1]	I also use multiple machines on which I can write stuff.

[2]

I am lazy and chaotic (good), so the stages are optional and non-linear, and sometimes involve paper. This article is a prime example: parts of it were on two different private branches, but at the end I wrote it from scratch directly on the main branch. And the requirements were written on a paper originally.

Nevertheless, the general idea still holds and may inspire others, so it makes sense to keep this part in the article. (Also, this footnote might not make sense before reading the definition of the stages, but I didn't find a better place to put it…)

[3]	Well, given this article contains some future plans, I actually anticipate update of this one, but maybe not in the near future. So the outline is not really correct, but I make the rules :-) (There were some build breaks on the main branch, too :-D)

[4] I would love if my Forgejo could have "private branches", but I understand that the overhead for doing this is not nice, since it would need to be able to decide for any object, whether it is public or not (you can do git fetch <remote> <object-hash>) and somehow keep track even with rebases, merges, force-pushes, many branches, … Having a separate private repository is not a big problem in comparison.

[5] Git purists might want to tell me that committing build artifacts is not good practice. I know and I explicitly don't care in case of this repo, because here I prioritise my own comfort of being able to check everything locally and then be reasonably sure the deployed version will also work, all this with only a single push somewhere. Of course, one could argue that with that there is no reason to create two commits, but it does not really bother me to run something like git commit -m"render" output/ when I am sure it works, and this keeps readable diffs separate from the non-readable ones (i.e. the changes in generated HTML).

[6] Having the page be dark-by-default is my preference, but I respect that others may prefer light sites. However, I have not yet determined what colors should be used (probably still cyan / blue / maybe purple-ish, but I don't know what shade) nor understood how to use @media(prefers-color-scheme) in a maintainable and simple way (in the context of my theme). So naturally, this is postponed to the future…

Smršť 2023 (CZ)

2023-12-02T18:00:00+01:00

Na Smršti jsem přednášel o distribuci SW a o technicky zajímavých železničních neštěstích.

Materiály

Slidy ke přednášce o neštěstích

(Pozn.: Možná se ještě změní adresa téhle stránky, protože je to celé WIP…)