(First blog post ever, would appreciate your input!)

Edit: Title was a lil clickbaity

  • irmadlad@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    ·
    5 hours ago

    I found an 8-year-old project on GitHub that had similar ideas but is unmaintained and not quite what I needed.

    In the back on my mind I was thinking ‘I could have sworn I had seen Dockwell somewhere before’.

    It’s one night of work, so take that for what it is

    The honesty is refreshing.

    It’s interesting for sure. I was intrigued when I saw OG Dockwell, but like you, saw it was quite stale.

  • litchralee@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    3
    ·
    5 hours ago

    This blog post comes to me at an interesting time, for I’ve been gathering info to rebuild my router using FreeBSD. Specifically, I bought a hard-copy of The Book Of PF, 4th Edition, for configuring PF for routing and firewalling. Like with all good firewalls, the PF rulesets start with blocking all traffic. But unlike the VyOS-based rules used by my outgoing Ubiquiti router, PF does not implicitly include rules for common use-cases, such as enabling hairpin NAT for Legacy IP. Nor does the syntax assume that rules are only for inbound, as the shortest syntax will actually apply a rule in both directions on every interface.

    To that end, one of the tenants for configuring a PF firewall is to also filter outbound traffic, as a matter of: 1) asserting control over the network, and 2) implementing the principle of least privilege. I can reasonably accept that my home’s guest WiFi network should be fairly free flowing for outbound traffic, but that shouldn’t apply to my IoT VLAN. Quite frankly, my IoT VLAN only allows outbound connections to four specific NTP servers hosted by ntp.org, because my thermostat has a badly-designed real-time clock and I refuse to allow network access for devices that historically never needed it.

    Before containers, firewalls implemented the DMZ idea, where any host that runs an externally-accessible service would be within the DMZ, to prevent infiltrating the broader LAN if something goes wrong. Your solution achieves a sort-of DMZ, but does it at the Docker host. Whereas a true DMZ would segment the rest of your network off, so as to further reduce risk, since iptables is the only line of defense.

    That said, zooming out, this caught my attention:

    The breaking point came when I wanted to host Gemini FastAPI, a project that wraps Google’s internal Gemini API into an OpenAI-compatible interface, useful for using your Gemini Pro subscription outside Google’s walled garden. The catch: it needs your browser cookies, which means full access to your Google account.

    The very premise of Gemini FastAPI seems flawed to me, if it’s trying to create a wrapper when Google clearly does not want that to exist. The challenges that you observed, such as the brittleness of IP allowlists, would suggest to me that the overall endeavor is going to be brittle, by Google’s design.

    To be clear, that doesn’t mean you shouldn’t pursue this, in the same way that yt-dlp exists for the legitimate use for accessing YouTube. But what both yt-dlp and Gemini FastAPI will never escape is that they only exist because Google hasn’t cracked down on it further. When every indication is showing that this is the road with even more trouble beyond the next curve, is this what you want to invest time and effort into? There are other platforms and protocols that replace YouTube, or at least minimize one’s dependency on a clearly antagonistic host.

    At bottom, I think the question is whether connecting to Gemini is really worth all of this trouble, when they evidently don’t want you to do this, and it adds yet another dependency upon Google. Even if you believe Google is 100% benevolent and their lack of a built-in support for using Gemini externally is just a minor oversight, you will have to pick which services you will base your own infrastructure upon. This is, after all, c/selfhosted.

  • potatoguy@mbin.potato-guy.space
    link
    fedilink
    arrow-up
    4
    ·
    6 hours ago

    Also, an interesting thing is using systemd-resolved for DNS-over-TLS or hosts blocking.

    I configure it to my nextdns account and podman uses it for all requests, so I can block dns records from anywhere and use some tracking, mining, NSA, minimum domain age, etc, blocklists.

  • Decronym@lemmy.decronym.xyzB
    link
    fedilink
    English
    arrow-up
    3
    arrow-down
    1
    ·
    edit-2
    23 minutes ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    DNS Domain Name Service/System
    IP Internet Protocol
    IoT Internet of Things for device controllers
    LXC Linux Containers
    NAS Network-Attached Storage
    NAT Network Address Translation
    SSL Secure Sockets Layer, for transparent encryption
    TLS Transport Layer Security, supersedes SSL

    [Thread #282 for this comm, first seen 10th May 2026, 02:00] [FAQ] [Full list] [Contact] [Source code]