19
submitted 5 months ago* (last edited 5 months ago) by Molecular0079@lemmy.world to c/selfhosted@lemmy.world

I've been trying to migrate my services over to rootless Podman containers for a while now and I keep running into weird issues that always make me go back to rootful. This past weekend I almost had it all working until I realized that my reverse proxy (Nginx Proxy Manager) wasn't passing the real source IP of client requests down to my other containers. This meant that all my containers were seeing requests coming solely from the IP address of the reverse proxy container, which breaks things like Nextcloud brute force protection, etc. It's apparently due to this Podman bug: https://github.com/containers/podman/issues/8193

This is the last step before I can finally switch to rootless, so it makes me wonder what all you self-hosters out there are doing with your rootless setups. I can't be the only one running into this issue right?

If anyone's curious, my setup consists of several docker-compose files, each handling a different service. Each service has its own dedicated Podman network, but only the proxy container connects to all of them to serve outside requests. This way each service is separated from each other and the only ingress from the outside is via the proxy container. I can also easily have duplicate instances of the same service without having to worry about port collisions, etc. Not being able to see real client IP really sucks in this situation.

10

On one of my machines, I am completely unable to log out. The behavior is slightly different depending on whether I am in Wayland or X11.

Wayland

  1. Clicking log out and then OK in the log out window brings me back to the desktop.
  2. Doing this again does the same thing
  3. Clicking log out for a third time does nothing

X11

  1. Clicking log out will lead me to a black screen with just my mouse cursor.

In my journalctl logs, I see:

Apr 03 21:52:46 arch-nas systemd[1]: Stopping User Runtime Directory /run/user/972...
Apr 03 21:52:46 arch-nas systemd[1]: run-user-972.mount: Deactivated successfully.
Apr 03 21:52:46 arch-nas systemd[1]: user-runtime-dir@972.service: Deactivated successfully.
Apr 03 21:52:46 arch-nas systemd[1]: Stopped User Runtime Directory /run/user/972.
Apr 03 21:52:46 arch-nas systemd[1]: Removed slice User Slice of UID 972.
Apr 03 21:52:46 arch-nas systemd[1]: user-972.slice: Consumed 1.564s CPU time.
Apr 03 21:52:47 arch-nas systemd[1]: dbus-:1.2-org.kde.kded.smart@0.service: Deactivated successfully.
Apr 03 21:52:47 arch-nas systemd[1]: dbus-:1.2-org.kde.powerdevil.discretegpuhelper@0.service: Deactivated successfully.
Apr 03 21:52:47 arch-nas systemd[1]: dbus-:1.2-org.kde.powerdevil.backlighthelper@0.service: Deactivated successfully.
Apr 03 21:52:48 arch-nas systemd[1]: dbus-:1.2-org.kde.powerdevil.chargethresholdhelper@0.service: Deactivated successfully.
Apr 03 21:52:54 arch-nas systemd[4500]: Created slice Slice /app/dbus-:1.2-org.kde.LogoutPrompt.
Apr 03 21:52:54 arch-nas systemd[4500]: Started dbus-:1.2-org.kde.LogoutPrompt@0.service.
Apr 03 21:52:54 arch-nas ksmserver-logout-greeter[5553]: qt.gui.imageio: libpng warning: iCCP: known incorrect sRGB profile
Apr 03 21:52:54 arch-nas ksmserver-logout-greeter[5553]: kf.windowsystem: static bool KX11Extras::compositingActive() may only be used on X11
Apr 03 21:52:54 arch-nas plasmashell[5079]: qt.qpa.wayland: eglSwapBuffers failed with 0x300d, surface: 0x0
Apr 03 21:52:55 arch-nas systemd[4500]: Created slice Slice /app/dbus-:1.2-org.kde.Shutdown.
Apr 03 21:52:55 arch-nas systemd[4500]: Started dbus-:1.2-org.kde.Shutdown@0.service.
Apr 03 21:52:55 arch-nas systemd[4500]: Stopped target plasma-workspace-wayland.target.
Apr 03 21:52:55 arch-nas systemd[4500]: Stopped target KDE Plasma Workspace.
Apr 03 21:52:55 arch-nas systemd[4500]: Requested transaction contradicts existing jobs: Transaction for  is destructive (drkonqi-coredump-pickup.service has 'start' job queued, but 'stop' is included in transaction).
Apr 03 21:52:55 arch-nas systemd[4500]: graphical-session.target: Failed to enqueue stop job, ignoring: Transaction for graphical-session.target/stop is destructive (drkonqi-coredump-pickup.service has 'start' job queued, but 'stop' is included in transaction).
Apr 03 21:52:55 arch-nas systemd[4500]: Stopped target KDE Plasma Workspace Core.
Apr 03 21:52:55 arch-nas systemd[4500]: Stopped target Startup of XDG autostart applications.
Apr 03 21:52:55 arch-nas systemd[4500]: Stopped target Session services which should run early before the graphical session is brought up.
Apr 03 21:52:55 arch-nas systemd[4500]: dbus-:1.2-org.kde.LogoutPrompt@0.service: Main process exited, code=exited, status=1/FAILURE
Apr 03 21:52:55 arch-nas systemd[4500]: dbus-:1.2-org.kde.LogoutPrompt@0.service: Failed with result 'exit-code'.graphical-session.target/stop

I've filed an upstream bug for this but I was wondering if anyone else here was also experiencing the same issue.

[-] Molecular0079@lemmy.world 67 points 6 months ago

If you use firewalld, both docker and podman apply rules in a special zone separate from your main one.

That being said, podman is great. Podman in rootful mode, along with podman-docker and docker-compose, is basically a drop-in replacement for Docker.

[-] Molecular0079@lemmy.world 167 points 7 months ago

God, it's like they don't want RCS to succeed.

12
64

Currently, I have SSH, VNC, and Cockpit setup on my home NAS, but I have run into situations where I lose remote access because I did something stupid to the network connection or some update broke the boot process, causing it to get stuck in the BIOS or bootloader.

I am looking for a separate device that will allow me to not only access the NAS as if I had another keyboard, mouse, and monitor present, but also let's me power cycle in the case of extreme situations (hard freeze, etc.). Some googling has turned up the term KVM-over-IP, but I was wondering if any of you guys have any trustworthy recommendations.

[-] Molecular0079@lemmy.world 70 points 11 months ago

ProtonVPN is a no log VPN according to their privacy policy: https://protonvpn.com/privacy-policy

They have servers specifically for port forwarding and P2P traffic. I use them and I haven't gotten a DMCA request yet so 🤷🏻‍♂️

[-] Molecular0079@lemmy.world 82 points 11 months ago

So...how long before Apple realizes that game devs are notoriously time-crunched and forcing them to target yet another proprietary graphics API is a stupid move for their gaming ambitions?

[-] Molecular0079@lemmy.world 124 points 1 year ago

It’s always memory management

No wonder everyone's crazy about Rust.

[-] Molecular0079@lemmy.world 84 points 1 year ago

The whole idea of investments always going up is an absurd idea that needs to go. At this point I infinitely prefer a private company over a publicly traded one.

124

I mean, come on, this has to be a joke right XD

[-] Molecular0079@lemmy.world 233 points 1 year ago

Lol, I dunno if it's them expressing their feelings so much as them taking advantage of a business opportunity.

113

cross-posted from: https://lemmy.world/post/4930979

Bcachefs making progress towards getting included in the kernel. My dream of having a Linux native RAID5 capable filesystem is getting closer to reality.

27

Bcachefs making progress towards getting included in the kernel. My dream of having a Linux native RAID5 capable filesystem is getting closer to reality.

20
submitted 1 year ago* (last edited 1 year ago) by Molecular0079@lemmy.world to c/linux_gaming@lemmy.world

Patch 2 seems to have drastically slowed down the Vulkan Renderer. Before I was able to get 80-110FPS in the Druid Grove, but now I am only getting 50fps. DX11 seems fine though, but I prefer using Vulkan since I am on Linux.

Arch Linux, Kernel 6.4.12

Ryzen 3900x

Nvidia 3090 w/ 535.104.05 drivers

Latest Proton Experimental

15
submitted 1 year ago* (last edited 1 year ago) by Molecular0079@lemmy.world to c/selfhosted@lemmy.world

I am using one of the official Nextcloud docker-compose files to setup an instance behind a SWAG reverse proxy. SWAG is handling SSL and forwarding requests to Nextcloud on port 80 over a Docker network. Whenever I go to the Overview tab in the Admin settings, I see this security warning:

    The "X-Robots-Tag" HTTP header is not set to "noindex, nofollow". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

I have X-Robots-Tag set in SWAG. Is it safe to ignore this warning? I am assuming that Nextcloud is complaining about this because it still thinks its communicating over an insecured port 80 and not aware of the fact that its only talking via SWAG. Maybe I am wrong though. I wanted to double check and see if there was anything else I needed to do to secure my instance.

SOLVED: Turns out Nextcloud is just picky with what's in X-Robots-Tag. I had set it to SWAG's recommended setting of noindex, nofollow, nosnippet, noarchive, but Nextcloud expects noindex, nofollow.

18
submitted 1 year ago* (last edited 1 year ago) by Molecular0079@lemmy.world to c/linux@lemmy.world

cross-posted from: https://lemmy.world/post/3989163

I've been messing around with podman in Arch and porting my self-hosted services over to it. However, it's been finicky and I am wondering if anybody here could help me out with a few things.

  1. Some of my containers aren't getting properly started up by podman-restart.service on system reboot. I realized they were the ones that depended on my slow external BTRFS drive. Currently its mounted with x-systemd.automount,x-systemd.device-timeout=5 so that it doesn't hang up the boot if I disconnect it, but it seems like Podman doesn't like this. If I remove the systemd options the containers properly boot up automatically, but I risk boot hangs if the drive ever gets disconnected from my system. I have already tried x-systemd.before=podman-restart.service and x-systemd.required-by=podman-restart.service, and even tried increasing the device-timeout to no avail.

When it attempts to start the container, I see this in journalctl:

Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: libpod-742b4595dbb1ce604440d8c867e72864d5d4ce1f2517ed111fa849e59a608869.scope: Deactivated successfully.
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : runtime stderr: error stat'ing file `/external/share`: Too many levels of symbolic links
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : Failed to create container: exit status 1
  1. When I shutdown my system, it has to wait for 90 seconds for libcrun and libpod-conmon-.scope to timeout. Any idea what's causing this? This delay gets pretty annoying especially on an Arch system since I am constantly restarting due to updates.

All the containers are started using docker-compose with podman-docker if that's relevant.

Any help appreciated!

EDIT: So it seems like podman really doesn't like systemd automount. Switching to nofail, x-systemd.before=podman-restart.service seems like a decent workaround if anyone's interested.

42
submitted 1 year ago* (last edited 1 year ago) by Molecular0079@lemmy.world to c/linux@lemmy.ml

I've been messing around with podman in Arch and porting my self-hosted services over to it. However, it's been finicky and I am wondering if anybody here could help me out with a few things.

  1. Some of my containers aren't getting properly started up by podman-restart.service on system reboot. I realized they were the ones that depended on my slow external BTRFS drive. Currently its mounted with x-systemd.automount,x-systemd.device-timeout=5 so that it doesn't hang up the boot if I disconnect it, but it seems like Podman doesn't like this. If I remove the systemd options the containers properly boot up automatically, but I risk boot hangs if the drive ever gets disconnected from my system. I have already tried x-systemd.before=podman-restart.service and x-systemd.required-by=podman-restart.service, and even tried increasing the device-timeout to no avail.

When it attempts to start the container, I see this in journalctl:

Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Got automount request for /external, triggered by 3130 (3)
Aug 27 21:15:46 arch-nas systemd[1]: external.automount: Automount point already active?
Aug 27 21:15:46 arch-nas systemd[1]: libpod-742b4595dbb1ce604440d8c867e72864d5d4ce1f2517ed111fa849e59a608869.scope: Deactivated successfully.
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : runtime stderr: error stat'ing file `/external/share`: Too many levels of symbolic links
Aug 27 21:15:46 arch-nas conmon[3124]: conmon 742b4595dbb1ce604440 : Failed to create container: exit status 1
  1. When I shutdown my system, it has to wait for 90 seconds for libcrun and libpod-conmon-.scope to timeout. Any idea what's causing this? This delay gets pretty annoying especially on an Arch system since I am constantly restarting due to updates.

All the containers are started using docker-compose with podman-docker if that's relevant.

Any help appreciated!

EDIT: So it seems like podman really doesn't like systemd automount. Switching to nofail, x-systemd.before=podman-restart.service seems like a decent workaround if anyone's interested.

70

cross-posted from: https://lemmy.world/post/3754933

While experimenting with ProtonVPN's Wireguard configs, I realized that my real IPv6 address was leaking while IPv4 was correctly going through the tunnel. How do I prevent this from happening?

I've already tried adding ::/0 to the AllowedIPs option and IPv6 is listed as disabled in the NetworkManager profile.

[-] Molecular0079@lemmy.world 61 points 1 year ago

The problem with PeerTube is that there's no built-in way for creators to get paid. If there are no ads or sponsors, then the only alternative is some kind of value for value system like what Podcasting 2.0 has. Until some kind of well integrated funding system gets built for PeerTube, creators really are not going to be incentivized to publish stuff on the platform.

[-] Molecular0079@lemmy.world 132 points 1 year ago

Jesus Christ. Why does it feel like tech industry is just getting shittier and more expensive, while all the cool consumer options are being axed. Intel Nucs were a relatively cheap way to get a cute little desktop machine or a home server. I am sad that they're going away. I guess there's always Minisforum, but still...

[-] Molecular0079@lemmy.world 60 points 1 year ago

Gotta say, it's weird seeing a iOS interface on an Android device XD, but it feels very smooth and polished, especially for a web app.

[-] Molecular0079@lemmy.world 115 points 1 year ago

Those are packages that lot of other packages rely on and so as a result just needs more testing. Sometimes Arch is faster, sometimes other distros are faster. This is relatively normal.

[-] Molecular0079@lemmy.world 58 points 1 year ago

Maybe they just don't want to give up on a community in which they put so much time, effort, and passion to help shape.

view more: next ›

Molecular0079

joined 1 year ago