 | NixOS Networking | 911 Members |
| Declaratively manage your switching, routing, wireless, tunneling and more. | 264 Servers |
| NixOS Networking | 911 Members |
| Declaratively manage your switching, routing, wireless, tunneling and more. | 264 Servers |
| Sender | Message | Time |
|---|---|---|
| 14 Jun 2025 | ||
 @donjoe:nanashi0x74.dev left the room. | 09:20:47 | |
| 15 Jun 2025 | ||
 Luke | Hey folks, sorry if this is not the right room (I can ask elsewhere if this is not the correct place for questions about nginx); I recently made some updates to the Fluidd and Moonraker services to allow serving these at a path here. I've tested this on my setup, using a single path /printer/ for the new baseUrl and routePrefix options, but I am not sure the nginx declarations are correct. If someone who is an nginx expert could give it a once over I'd appreciate it. In particular, I don't know if any of the proxyPass parts are robust enough to merge yet, or if they would even work if Moonraker and Fluidd have different paths? Though it seems those services may be intended to be served at the same path? | 02:55:05 |
 K900 | Looks reasonable enough, but also, why? | 09:24:44 |
| K900 | Generally sharing the same domain name between multiple services is just A Bad Idea | 09:24:56 |
| K900 | For a variety of reasons | 09:25:00 |
 @c3r5b8:matrix.org left the room. | 13:32:28 | |
 debtquity joined the room. | 14:03:04 | |
| Luke | In reply to @k900:0upti.me It is a fairly uncommon setup (because most people with printers tend not to go about using a domain at all from my time in the 3D printing community), but some people like myself end up exposing these machines under a subpath that only gets served if the request comes from behind a VPN subnet. If you have many machines, like a print farm, you would also benefit from this sort of setup - easier to serve at a subpath than manage a ton of DNS entries for subdomains etc. But if you mean, “why do Moonraker and the web interface share a domain?” That seems to be the default configuration already for the most part, given that Moonraker gets served at “/websocket” as this combination of apps usually runs from the same SBC and is tightly coupled to control a 3D printer running Klipper. The pattern for these printers is as follows:
| 18:45:19 |
| Luke | I see you also commented on git, thanks for taking a look 🙂 | 18:45:52 |
| K900 | In reply to @luke:vuksta.comI understand the pattern | 18:52:25 |
| K900 | I mean specifically having more than one subpath on the same domain | 18:52:42 |
| Luke | Just clarifying 🙂 | 18:52:50 |
| K900 | Generally this should really be done with subdomains | 18:52:52 |
| K900 | Otherwise things get WEIRD | 18:52:56 |
| Luke | Yeah, there have been changes to Fluidd to specifically support this though: https://github.com/fluidd-core/fluidd/issues/423 https://github.com/fluidd-core/fluidd/issues/1206 | 18:55:03 |
| Luke | I agree it is strange | 18:55:11 |
 hexa | You also don't want to share the same origin for various apps for safety reasons | 18:55:18 |
| Luke | Or at least uncommon | 18:55:19 |
| hexa | * You also don't want to share the same origin for various apps for security reasons | 18:55:23 |
| hexa | Even if the sotware supports it we should not | 18:55:48 |
| Luke | In reply to @hexa:lossy.networkI could yse some elaboration on this | 18:55:52 |
| Luke | * I could use some elaboration on this | 18:56:00 |
| hexa | https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy\ | 18:56:07 |
| hexa | * https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy | 18:56:09 |
| hexa | basically every app on the same domain gets the same cookies for one | 18:56:32 |
| hexa | but there's more beyond that | 18:56:54 |
| Luke | Perhaps I am not seeing the risk here - the machines running these services don’t get exposed to public internet (which is maybe not a good arguement, but should be considered). Further, this is a use case supported for print farms in Fluidd afaik? You could run moonraker on say, 20 machines, select a different route prefix for each, proxy those websockets to anothet machine that serves them behind a domain at some subdirectory, and a single server running one instance of Fluidd could manage those 20 printers by inputing the proxied moonraker address, e.g. printer1 is at http://example.com/printer1 (I think, I would have to flush out the details here a bit) | 19:08:07 |
| Luke | * Perhaps I am not seeing the risk here - the machines running these services don’t get exposed to public internet (which is maybe not a good arguement, but should be considered). Further, this is a use case supported for print farms in Fluidd afaik? You could run moonraker on say, 20 machines, select a different route prefix for each, proxy those websockets to another machine that serves them behind a domain at some subdirectory, and a single server running one instance of Fluidd could manage those 20 printers by inputing the proxied moonraker address, e.g. printer1 is at http://example.com/printer1 (I think, I would have to flush out the details here a bit) | 19:09:17 |
| Luke | So using the same domain to manage many different services for 3D printer farms is by design? Or maybe I am not seeing the issue with this setup | 19:10:34 |
| Luke | Also all of this assumes they have their own DNS server to make this private and not a publicly accessable service | 19:11:07 |