Incus Scripts is a collection of tools to simplify the deployment of incus instances. Originally created by tteck, these scripts are now continued by the community. Our goal is to preserve and expand upon tteck's work, providing an ongoing resource for Incus users worldwide.

This project is a fork of community-scripts that is continually updated to work with incus instead of ProxmoxVE.

This page has links to ask the talks regarding containers at FOSDEM held Feb 1st and 2nd. Most interesting to me is https://fosdem.org/2025/schedule/event/fosdem-2025-5742-bringing-application-containers-to-incus/ .

I’m running a rootless podman container listening on port 8080 on OpenSUSE Tumbleweed.

From the same host, there's no problem accessing the container. Trying to access the container remotely fails due to firewalld blocking the connection.

What I don't understand is this:

If I configure firewalld to forward port 80 to the container on port 8080 using

firewall-cmd --add-forward-port=port=80:proto=tcp:toport=8080

I can access the container from a remote computer using port 80.

However, if I try:

firewall-cmd --add-forward-port=port=8080:proto=tcp:toport=8080

I'm not able to reach the container. It seems that every port I try will work except for port 8080 in this case, and I can't find any references explaining why this might be the case.

What's going on here? Is it a conflict by trying to forward a port to itself? Is there any way to allow port 8080? Trying to allow port 8080 in the public zone fails as well.

Hello,

I have two Podman containers. One container that contains Linkstack and another container for the Nginx Proxy Manager. Now I want the Nginx Proxy Manager to retrieve the website from the Linkstack container. Unfortunately this does not work.

I integrate the two containers in a network. I realize this with podman-compose.

First, I created the network with "podman network create n_webservice".

Compose.yaml

`services: NGINXPM: networks: - n_webservice container_name: NGINXPM volumes: - /home/fan/pod_volume/npm/data/:/data/ - /home/fan/pod_volume/npm/letsencrypt/:/etc/letsencrypt ports: - 8080:80 - 4433:443 - 9446:81 image: docker.io/jc21/nginx-proxy-manager:latest linkstack: networks: - n_webservice container_name: linkstack ports:

I am trying to create a podman compose of NGINX and PHP:FPM. I was able to get NGINX to work on its own using the docker.io./bitnami/nginx image. I gotten close I believe to getting the PHP:FPM to work also but due to an issue with NGINX not cooperating with the PHP:FPM.

In the logs of the NGINX container, I get this error every time I load localhost:8080 in the browser...

 undefined

    
10.89.4.2 - - [24/Jul/2024:20:18:35 +0000] "GET / HTTP/1.1" 404 47 "-" "Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0" "-"
2024/07/24 20:18:35 [error] 44#44: *1 FastCGI sent in stderr: "Primary script unknown" while reading response header from upstream, client: 10.89.4.2, server: localhost, request: "GET / HTTP/1.1", upstream: "fastcgi://10.89.4.3:9000", host: "localhost:8080"

  

And when I load localhost:8080 in the browser, it displays a blank page which says "File not found.".

I am using podman 5.1.2 on Linux Mint 21.3. My goal is to simply NGINX and PHP to work, to be able

On Linux, thr best package type for a portable application is an AppImage since all the dependances are inside the AppImage, its all in one file and can run on any linux distro.

On Android, you dan download an APK and install it manually which is the closest thing to a portable Android app.

Therefore, in the service/server self hosting world. Are containers (docker/podman images) the equivalent to a portable executable of a service? AppImages downside is its size since all the dependancies are bundle with it. Containers not only bundle its dependnacies but the OS to run run them. For a stable, low incompatibility and low dependancy hell, are containers the way to go for portable services?

I know container images are not distributed as tar files often and mostly pulled from a registry, however they can be saved and loaded as portable tar files.

cross-posted from: https://sh.itjust.works/post/1163818

Update: The guide on github has been updated and has addopted a different method. Notably, it:

A) still accomplishing my goal of avoiding running the process inside as root.

B) uses the linuxserver.io image rather than the syncthing/syncthing one (my method does not allow for the linuxserver.io image to run), the linuxserver one is based on > alpine, I truly forget what the other one is based on.

An archived version of the guide I followed to create my setup has been placed bellow, the updated (and all subsequent version) can be found here

I saw this guide discussing how to run Syncthing in > a podman container on immutable OSes and decided to try and create a better solution that avoids running the process inside as root. I am new t

I'm currently using a Windows machine as the "server" in my home lab, but I just ordered some new hardware and I'd like to change things up to add some more flexibility and capability.

Based on my research so far, my plan is to install Proxmox on the bare metal and use it to run any regular VMs I need. However, I am still trying to figure out what to do about containers.

I know Proxmox also, supports LXC containers, but based on everything I've read, I think I'd like to use something more "industry standard". I was thinking Docker, but it sounds like Podman is lighter and more secure, so I am now leaning that direction. I plan on setting up an Ubuntu server VM in Proxmox and running Podman on that.

I'm thinking of running full blown VMs for more complex applications (Plex for example), but containers for simple applications (Pihole, ddclient, cloudflared, etc).

Does that all sound like a reasonable plan? Are there any obvious gotchas I might be missing? Any tips or resources you'd

https://www.phoronix.com/news/Canonical-Pulls-In-LXD

Most are scratch-based, with "Nobody" set as the main user. Enjoy.

This looks like it could be amazing. Maybe a self hosting dream, or a flash in the pan.

Let's start off with what a container is compared to a virtual machine.

This is the place to discuss various Container platforms, runtimes, and technologies. Whether it is big daddy Docker, or something newer like Podman. Grand-daddy LXC, or the OCI. If it is about containers, let's talk.