• 0 Posts
  • 8 Comments
Joined 8 months ago
cake
Cake day: August 14th, 2025

help-circle
  • 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).


  • 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. :)




  • 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.