Add information about talks, firewall, DHCP, DNS, and add Tiamat to IP allocations

[lavajuno]

• Talks page is no longer empty
• A bit more information about the firewall and nftables
• DHCP server is now EOL :(
• Trimmed unnecessary comments from DHCP server config
• Tiamat is now on the 145 subnet listing
• Updated unbound info and config

[Alextopher]

@lavajuno you might want to add this link to the tiamat docs https://terminator.cosi.clarkson.edu/

[lavajuno]

@lavajuno you might want to add this link to the tiamat docs https://terminator.cosi.clarkson.edu/

Definitely, I was just a bit hesitant to put it there because a lot of our network security documentation is private. I'm totally fine personally with Terminator being on there though. I'll poke around to see if it's an issue and if not I will commit it

[Alextopher]

It's listed in the zones repo, so the existence is at least partially public knowledge. It's not a bad idea to make it only accessible from COSI subnets.

Checking if the project is still active and receiving updates is always a good idea too.

There's no reason that service is insecure, unless if there's a security flaw. 😃

[Alextopher]

I'm in the (slow) process of writing a blog post / article about the append only log database paradigm I used for go-talks and some other projects. Here is what some of that could look like as part of the book.

Architecture

Instead of using a typical SQL database (like SQLite) talks uses an unconventional append-only log backed database. All events (creating talks, hiding talks, deleting talks) are timestamped and appended to the "database" as JSON.

{"time":"2022-09-22 00:07:36.748669812+00:00","type":"create","create":{"id":245,"name":"Chris","type":"lightning talk","description":"chris tries his best to explain why rust is awesome","week":"20220928"}}
{"time":"2022-09-22 00:25:59.471196491+00:00","type":"hide","hide":{"id":246}}
...
{"time":"2023-08-28 18:06:43.998097+00:00","type":"delete","delete":{"id":465}}

On program start this log file is read in and simulated, creating an in-memory representation (vaguely a Map id -> Talk). At this point almost any operation is fast.

Some advantage of the append-only log databases are:

• Backups become trivial, copy the file.
• Rollbacks are amazing, delete the last N lines.
• This database is extensible. New event types can be added arbitrarily in a backwards compatible way.
• If needed you can easily rewrite history (table changes, name changes, etc).
• Human "readable", self documenting format.
• There is no ORM and no need to write SQL.

The biggest cons to the paradigm:

• There is no SQL. Queries must be programmed in the native language. This is probably a net-negative on overall accessibility.
• go-talk's database state must be completely stored in memory (unlikely for us to ever exceeded 1 MB).
• It's not particularly nice to store data other than plain text.
• Unconventional. There is often criticism that this kind of approach is "not proven". Although go-talks has stored >1000 events without issue.

[lavajuno]

Might be good to open a separate PR to add that on the Talks page, I'll probably be merging this one soon once I add more info about our current network setup.

[lavajuno]

Switch info and topology is now up to date. It's not perfect but this PR is getting giant and it's better to have up-to-date information on Book. Merging it soon.