• 7 Posts
  • 24 Comments
Joined 8 months ago
cake
Cake day: September 2nd, 2024

help-circle
  • tkw8@lemm.eeOPtoSelfhosted@lemmy.worldmDNS behind a gluetun container?
    link
    fedilink
    English
    arrow-up
    1
    ·
    edit-2
    22 days ago

    I appreciate the response. I updated it and there was some success in that Jellyfin isn’t throwing errors anymore, which is a step in the right direction. So thank you for that. Unfortunately it still isn’t working. I did a little more log digging and found this:

    [16:35:50] [INF] [1] Jellyfin.Plugin.Dlna.Main.DlnaHost: Registering publisher for urn:schemas-upnp-org:device:MediaServer:1 on 172.21.0.2 with uri http://172.21.0.2:8096/dlna/6a8078b6-cb55-4b46-acf0-64e99f2a7a79/description.xml

    I think the issue might(?) be that DLNA is on a docker subnet and my home receiver is on a local 192.169.x.x subnet. I’m not sure though.

    Edit: I also checked the Jellyfin docs and tried opening up ports 1900 and 7359 on the gluetun container. That didn’t do anything though.











  • I appreciate your effort here & the screenshots. Unfortunately, this isn’t what I was looking for. This just imports a “dumb” feed and doesn’t actually integrate with the API. Integrating with FreshRSS’ API, (the app OP mentioned), allows the RSS reader to interoperate with the FreshRSS application. For example, if I read an article on my mobile device, it will be marked as read on FreshRSS. So if I later pull up my feed on Newsboat (on my linux machine) or Readrops (my android tablet), those same articles won’t be presented to me again. Also, if I’ve made any customizations regarding my home feed in FreshRSS those will also be reflected in these other RSS Readers. That’s why the API is the preferred way to connect to these other readers.

    I just didn’t see a place for a user/API key input within feeeed.



  • … plans emerged last week when the Australian Signals Directorate (ASD) published guidance for High Assurance Cryptographic Equipment (HACE) – devices that send and/or receive sensitive information – that calls for disallowing the cryptographic algorithms SHA-256, RSA, ECDSA and ECDH, among others, by the end of this decade.

    With regard to the algorithms used to hash data – particularly SHA-224 and SHA-256 – Buchanan expressed surprise that neither will be approved for use beyond 2030.

    “The migration within five years will not be easy, as every single web connection currently uses ECDH and RSA/ECDSA,” he wrote. “These methods are also used for many other parts of a secure infrastructure.”

    Looks like we could be in for interesting times.