Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

docs.linuxserver.io

Post reply on HN
Print view View original

51–60 of 81 posts

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#51

Post by jazzyjackson »

bo0tzz wrote: post #40

My pipedream is to have a containerized desktop environment like this that outputs directly to a physical monitor over HDMI/DP without needing an X server on the host machine. So far I haven't found any clear answers on whether that's possible at all.

I feel I've been nerdsniped or, some other term for your quest being contagious, I also now need to know if this is possible

I found a thread from someone who seems to know what they're talking about saying it's not going to happen "on your hardware", but doesn't mention what hardware might be required

https://forum.level1techs.com/t/can-intel-integrated-gpu-out...

Edit actually reading that link again it sounds like a USB adapter worked right away as a monitor for the VM and the OP is asking how to prevent this ! So seems you just need to enable GPU passthrough, and a USB HDMI will appear to your VM ? Will have to try this later today

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#52

Post by macinjosh »

chrisweekly wrote: post #2

> "Warning Do not put this on the Internet if you do not know what you are doing. By default this container has no authentication and the optional environment variables CUSTOM_USER and PASSWORD to enable basic http auth via the embedded NGINX server should only be used to locally secure the container from unwanted access on a local network. If exposing this to the Internet we recommend putting it behind a reverse pro…

If a good password is used HTTP basic auth is plenty secure over HTTPS so that everything is encrypted.

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#53

Post by doubled112 »

dspillett wrote: post #35
hifikuno wrote: post #5

Earlier quoted context omitted.

Yeah, I made a mistake with my config. I had setup SWAG, with Authelia (i think?). Got password login working with 2fa. But my dumbass didn't realize I had left ports open. Logged in one day to find a terminal open with a message from someone who found my instance and got in. Called me stupid (I mean they're not wrong) and all kinds of things and deleted everything from my home drive to "teach me a lesson". Lesson pa…

> Lesson painfully learnt. There are actually two lessons there: 1. Be careful what you open to the public internet, including testing to make sure you aren't accidentally leaving open defaults as they are. 2. Backups. Set them up, test them, make sure someone successfully gaining access to the source box(es) can't from there wipe all the backups.

An offline backup is incredibly inconvenient, but also very effective against shenanigans like these.

Also agree that backups should be "pulled" with no way to access them from the machine being backed up.

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#54

Post by windexh8er »

Havoc wrote: post #36
windexh8er wrote: post #14

I've been using the LSIO Webtop images for a few years. They're awesome for composable desktops that I run behind a VPN for a quick and easy dirty connection at home. Combine the Webtop images by forcing it's traffic through the Gluetun [0] container and you're up and running. These Webtop containers are nice and snappy as well thanks to Kasm. Awesome OSS. [0] https://github.com/qdm12/gluetun

This is me being rather lazy admittedly, but do you have a compose/similar for connecting them by chance?

Basically the same, but a bit more complete in terms of the exposed config: https://pastebin.com/hPvs08qh

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#56

Post by jillyboel »

hifikuno wrote: post #5
chrisweekly wrote: post #2

> "Warning Do not put this on the Internet if you do not know what you are doing. By default this container has no authentication and the optional environment variables CUSTOM_USER and PASSWORD to enable basic http auth via the embedded NGINX server should only be used to locally secure the container from unwanted access on a local network. If exposing this to the Internet we recommend putting it behind a reverse pro…

Yeah, I made a mistake with my config. I had setup SWAG, with Authelia (i think?). Got password login working with 2fa. But my dumbass didn't realize I had left ports open. Logged in one day to find a terminal open with a message from someone who found my instance and got in. Called me stupid (I mean they're not wrong) and all kinds of things and deleted everything from my home drive to "teach me a lesson". Lesson pa…

No backups?

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#57

Post by mschuster91 »

Timber-6539 wrote: post #22
satertek wrote: post #3

Earlier quoted context omitted.

That warning applies to anything you run locally. And going further, in this day and age, I would never put up any home service without it being behind Cloudflare Access or some form of wireguard tunnel.

Just put up basic auth infront of your services and be done with it.

Good luck when the TCP or SSL stack has an issue. These bugs are rare but they do exist and you're getting fucked royally if your entire perimeter defense was a basic auth prompt.

Windows and Linux have both had their fair share of network stack bugs, OpenSSL had Heartbleed and a few other bugs, and hell you might even run into bugs in Apache or whatever other webserver you are using.

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#58

Post by mschuster91 »

baq wrote: post #43
j16sdiz wrote: post #42

Earlier quoted context omitted.

HTTP auth can work with kerberos. Chrome, Firefox, Internet Explorer -- all support some form of kerberos auth in HTTP/HTTPS.

I mean, I'm aware of SPNEGO etc. It's just that it was... ignored(?) by the startups/the community/google? Whatever little support there is is comparatively a worse experience than what we've got now for no really good reason.

Kerberos is old neckbeard tech, highly complex to set up, with layers upon layers of legacy garbage. Trying to get it working is ... a nightmare, I prefer even the garbagefest that is Keycloak over dealing with Kerberos. At least that just requires somewhat working DNS and doesn't barf when encountering VPNs, split horizon DNS or split tunnels.

The only places I've seen a working Kerberos setup outside of homelabs is universities (who can just throw endless amounts of free student labor power onto solving any IT problem) and large governments and international megacorps.

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#59

Post by gbraad »

chrisweekly wrote: post #2

> "Warning Do not put this on the Internet if you do not know what you are doing. By default this container has no authentication and the optional environment variables CUSTOM_USER and PASSWORD to enable basic http auth via the embedded NGINX server should only be used to locally secure the container from unwanted access on a local network. If exposing this to the Internet we recommend putting it behind a reverse pro…

I created personalized image with tailscale and kasmvnc for this particular reason, ... not on a public VPS. you can find images on my github as inspiration; do not directly copy unless you understand what you are doing.

Re: Webtop – Alpine,Ubuntu,Fedora,and Arch containers containing full desktop envs

#60

Post by dspillett »

doubled112 wrote: post #53
dspillett wrote: post #35

Earlier quoted context omitted.

> Lesson painfully learnt. There are actually two lessons there: 1. Be careful what you open to the public internet, including testing to make sure you aren't accidentally leaving open defaults as they are. 2. Backups. Set them up, test them, make sure someone successfully gaining access to the source box(es) can't from there wipe all the backups.

An offline backup is incredibly inconvenient, but also very effective against shenanigans like these. Also agree that backups should be "pulled" with no way to access them from the machine being backed up.

I use a soft-offline backup for most things: sources push to an intermediate, backups pull from the intermediate, neither source not backup can touch each other directly.

Automated testing for older snapshots is done by verifying checksums made at backup time, and for the latest by pushing fresh checksums from both ends to the middle for comparison (anything with a timestamp older than last backup that differs in checksum indicates an error on one side or the other, or perhaps the intermediate, that needs investigating, as does any file with a timestamp that differs more than the inter-backup gap, or something that unexpectedly doesn't exist in the backup).

I have a real offline backups for a few key bits of data (my main keepass file, encryption & auth details for the backup hosts & process as they don't want to exist in the main backup (that would create a potential hole in the source/backup separation), etc.).

Post reply on HN