NixOS Networking - Public Room Timeline

	NixOS Networking	905 Members
	Declaratively manage your switching, routing, wireless, tunneling and more.	263 Servers

Load older messages

Sender	Message	Time
15 Jun 2025
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 Looks reasonable enough, but also, why? 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: Klipper opens a unix socket that acts as its API endpoint Moonraker interacts with that API socket to control Klipper, and exposes a websocket. 3 Web frontends like Fluidd or Mainsail interact with the Moonraker websocket for user control via a GUI (nobody is running their printer directly from API calls to Moonraker)	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.com 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: Klipper opens a unix socket that acts as its API endpoint Moonraker interacts with that API socket to control Klipper, and exposes a websocket. 3 Web frontends like Fluidd or Mainsail interact with the Moonraker websocket for user control via a GUI (nobody is running their printer directly from API calls to Moonraker) I 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.network You also don't want to share the same origin for various apps for safety reasons I 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
Luke	With any other proper auth built into Moonraker	19:11:32
K900	That's a lot of assumptions	19:29:43
K900	That the option doesn't explicitly state	19:29:50

Show newer messages

Back to Room ListRoom Version: 6