ominous ocelot

Ah. I thought there is an option in docker compose I could use.

And a docker image prune - a while the containers are running? :)

I don’t understand. docker compose up starts the container. When does the docker compose pull happen? Or is there an update directive in the compose file?

Thanks to all replyers. My brain came up with dots per inch, which didn’t make any sense at all.

DPI?

Netplan config? Sure:

network:
  ethernets:
    enp35s0:
      dhcp4: false
    enp36s0:
      dhcp4: false
  vlans:
    enp35s0.100:
      id: 100
      link: enp35s0
      dhcp4: false
    enp35s0.101:
      id: 101
      link: enp35s0
      dhcp4: false
  bridges:
     br0:
	   # untagged
       interfaces: [enp35s0]
       dhcp4: false
     br0.100:
	   # vlan 100
       interfaces: [enp35s0.100]
       dhcp4: false
     br0.101:
	   #vlan 101
       interfaces: [enp35s0.101]
       dhcp4: true
  version: 2

I’m not sure if the version-property is still required. The only interface with an IP is br0.101. Opnsense provides DHCP (v4).

You can attach multiple ethernet-devices to a bridge (which I did not):

      br0.100:
        interfaces:
          - enp35s0.100
          - two
	        - three

I’m not sure if you can attach the docker bridge via netplan - it has to exist at boot time, I think. My docker containers run inside a VM (kvm) with one interface, which sits in one of the VLANs. The VM’s interface is a bridge device (br0.100). The VM ethernet device is attached to the bridge, it receives its IP from the router and behaves like a real server.

I don’t think I know the reason for the issue you’ve described. I don’t have enough information for that.

First thing would be: Is the routing and firewalling OK? Later: DNS. Even later: services reachable?

The Opnsense instance has configured multiple VLANs and zones too? With one server interface in each? The packets between the vlans take a path via the router?

I tried to give my server multiple interfaces on different VLANs once, but ran into problems with that approach. I then added one bridge interface per VLAN to the server and gave it just one IP on one vlan. That way the server isn’t tempted to route things itself or deliver packets on a wrong interface. An entire class of possible errors was removed that way. Docker containers and VMs still can have IPs in their respective VLANs/ nets.

It is worth noting that docker firewalling and ufw don’t play well together, which could be the reason for unreachable services. Moving the docker host into a LXC abstracts the issue away. Incus can run OCI containers itself and may be an alternative to docker (but not docker compose).

I can’t say anything about over-engeering. It is a hobby after all and you decide what is important and how much complexity you need. :)

I would guess, Fortnite has peaked a while ago and entered the decline phase. So…

One could argue, that it would have been nice to split the revenue more evenly. But shrinking an unprofitable business isn’t bad per se. Or ist it?

Logseq has how many? And it’s stalled really… from an external viewpoint.

https://github.com/logseq/logseq/graphs/contributors

About 4. Plus the people who maintain plugins.

https://github.com/logseq/logseq/graphs/commit-activity

They didn’t stop working on the code. But you’re right, it doesn’t feel like it UI wise. Which can be a good thing if the status quo is fine.

Markor

Promising. I will take a look.

Yeah, personally, I think they’d gradually make it db first and then markdown will gradually become an import / export function.

Can be. One of the reasons I like md - i’m not bound to one solution.

Still. At one point I will look at silverbullet.

Thanks!
For the interested: They’re working on a logseq edition with db backend as a basis for real time collaboration, better performance, data loss prevention during sync.

FAQ states:

Are you going to deprecate Markdown files support? No, we’ll continue to support both file-based and database-based graphs, with a long-term goal of achieving seamless two-way sync between the database and markdown files. This will allow you to leverage the benefits of the database version while still being able to use other tools.

It looks like, for the moment the md version is there to stay. I’d very much like that, because syncing with git or syncthing.

I’m not sure how useful the collaboration part will be for me. Other tools would have to make room for it in our workflow (ticket system, wiki).

Same here. Silverbullet looks tempting, markdown files and roughly the same feature set as logseq. I tried it out for a few minutes but did not go further.

What holds me back

• there is just one maintainer. What if…
• migration would take some work
• I’m lazy and haven’t tested it out yet

I use logseq and mainly the tagging/ backlink feature (frontmatter and inline) + the usual md language to structure my personal knowledge. Very few queries which I would have to rewrite.

I do not have a real reason to switch away from logseq. It works well enough. There is the occasional full text search search bug which can be circumvented with ripgrep or the like. It takes quite some time to start up - once or twice a day. Otherwise it works.

You say they plan to drop the md support in favour of a DB? Would you please provide a link? Thanks.

Ah. The approach that squirrel@piefed.zip suggested. ;)

Thanks for the tutorial though.

Unattended-Upgrades. Most of the time it is better to risk a faulty upgrade instead of an unpatched remote ACE.

I don’t get the resentment for yuno. In the end it is a hobby. You can have fun building everything from scratch. And you can have fun, using pre configured services.

What counts is that you get away from big corp.

Can’t say much about your tutorial though. Didn’t read it. I’m sorry. ;)