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

Serving a website on a Raspberry Pi Zero running in RAM

btxx.org

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Serving a website on a Raspberry Pi Zero running in RAM

#51

Post by basilikum »

The Pi Zero has 512MB RAM and a one GIGA Hertz CPU. It's a fucking super computer. Maybe not today, but not that long ago and back then people were running much more intensive things on them than hosting a website. It should be perfectly capable of handling TLS. AES might be a bit haeavy without hardware acceleration, but you can also do only ChaCha20 as the single supported server cipher. It would be easy to DDOS, but you should be able to mostly address that with firewall rules rate limiting connection attempts upstream.

I don't mean to shit on this, exploration is nice and putting perfectly fitting hardware to use instead of throwing abundant unnecessary hardware on every simple problem — just to bring it to crawl with loads of shitty bloates software — is good, but it's not particularly impressive.

Re: Serving a website on a Raspberry Pi Zero running in RAM

#52

Post by mercutio2 »

amatecha wrote: post #44
wang_li wrote: post #13

Earlier quoted context omitted.

It is more than a little weird. A pi zero is more than capable of handling HTTP/1.2 and TLS 1.3 for a handful of connections per second. This machine is 10x what we were running web servers on in the '90s. Also, all web pages are served from RAM. It's automatic that modern OSes will cache this stuff on first access.

Yeah, I ran a phpbb forum (alongside my normal static site) on a 486 in 2003 or so. It worked. It was slow, but it worked just fine for my friends and I! I remember it took multiple minutes to generate the SSH server key after the initial install lol

A 486 in 2003? Pentiums were shipping by the mid-90s, did you just have super old hardware lying around?

I retired my 486 in ‘95 or thereabouts…

Re: Serving a website on a Raspberry Pi Zero running in RAM

#53

Post by Antirust3743 »

indigodaddy wrote: post #26
spijdar wrote: post #12

Earlier quoted context omitted.

Yeah, I've seen this in more than a few places. There was a blog "running on a Wii" that, IIRC, was doing the same thing. On the one hand I get it, TLS is pretty heavy, and it makes sense to take advantage of a VPS or Cloudflare or however you want to do it. But once you are spinning up a VPS, the question is ... why the Pi? The VPS in the article has less RAM, but more storage. If you're already doing TLS terminatio…

The TLS termination isn't actually on the VPS. The article details that Tierhive has an haproxy edge service (handling the TLS), that then has the vps as the backend, but that vps is just doing tcp proxying with socat to the ddns exposed home server fqdn. Feels like a lot of unnecessary loops. Kinda fun I guess but, just, why

Yes it is, "we plan to use our external VPS for handling the TLS termination". Edit: Ah I see you are just pointing out termination is on haproxy service not VPS. Thought you were implying it was terminating on pi, my apologies.

Re: Serving a website on a Raspberry Pi Zero running in RAM

#54

Post by walrus01 »

wang_li wrote: post #13
c0nsumer wrote: post #8

This feels a little weird because while they are running the website itself (HTTP) off the Pi, they are handing off all TLS to a cloud provider. So while the content is in RAM on the Pi, a lot of the heavier lifting (TLS termination) is done elsewhere, which saves a ton of CPU load on the Pi.

It is more than a little weird. A pi zero is more than capable of handling HTTP/1.2 and TLS 1.3 for a handful of connections per second. This machine is 10x what we were running web servers on in the '90s. Also, all web pages are served from RAM. It's automatic that modern OSes will cache this stuff on first access.

Anyone remember 32 bit/33 MHz PCI slot SSL accelerator cards? As I recall openbsd had kernel driver support for several

Re: Serving a website on a Raspberry Pi Zero running in RAM

#55

Post by jorvi »

spijdar wrote: post #12
c0nsumer wrote: post #8

This feels a little weird because while they are running the website itself (HTTP) off the Pi, they are handing off all TLS to a cloud provider. So while the content is in RAM on the Pi, a lot of the heavier lifting (TLS termination) is done elsewhere, which saves a ton of CPU load on the Pi.

Yeah, I've seen this in more than a few places. There was a blog "running on a Wii" that, IIRC, was doing the same thing. On the one hand I get it, TLS is pretty heavy, and it makes sense to take advantage of a VPS or Cloudflare or however you want to do it. But once you are spinning up a VPS, the question is ... why the Pi? The VPS in the article has less RAM, but more storage. If you're already doing TLS terminatio…

This reminds me of the recent "running Doom on DNS" post which in actuality was "running Doom from DNS [as a storage device] on my PC" which is multitudes less impressive.

Re: Serving a website on a Raspberry Pi Zero running in RAM

#56

Post by dividuum »

I guess "Diskless" was defined by the same people that invented the term "Serverless"? That Pi is still using an SD card to boot from.

A Pi with Ethernet can truly boot diskless via TFTP. And later Pi4 and Pi5 can even boot directly from the internet by getting their initial "boot.img" FAT partition via HTTP from anywhere. That would be diskless.

Re: Serving a website on a Raspberry Pi Zero running in RAM

#57

Post by indigodaddy »

Antirust3743 wrote: post #53
indigodaddy wrote: post #26

Earlier quoted context omitted.

The TLS termination isn't actually on the VPS. The article details that Tierhive has an haproxy edge service (handling the TLS), that then has the vps as the backend, but that vps is just doing tcp proxying with socat to the ddns exposed home server fqdn. Feels like a lot of unnecessary loops. Kinda fun I guess but, just, why

Yes it is, "we plan to use our external VPS for handling the TLS termination". Edit: Ah I see you are just pointing out termination is on haproxy service not VPS. Thought you were implying it was terminating on pi, my apologies.

The VPS is running socat only and just doing tcp forwarding. There is a shared haproxy also run by their same host, sitting in front of the VPS and is handling the TLS. I encourage you to read the article fully. They probably should have said "VPS provider" instead of VPS for the TLS bit.

Re: Serving a website on a Raspberry Pi Zero running in RAM

#58

Post by walrus01 »

c0nsumer wrote: post #8

This feels a little weird because while they are running the website itself (HTTP) off the Pi, they are handing off all TLS to a cloud provider. So while the content is in RAM on the Pi, a lot of the heavier lifting (TLS termination) is done elsewhere, which saves a ton of CPU load on the Pi.

Considering that a 'base' raspbian type install can be something like 160MB of RAM used with openssh running and a lot of other launched-from-systemd daemons in the background, that leaves plenty of RAM available for a stock apache2 or nginx setup with TLS. No it won't be able to serve a ton of simultaneous requests, but I'm in agreement with the other comments here that doing purely port 80/http and putting it behind a secondary TLS proxy is not really "serving the website" from the raspberry pi.

Re: Serving a website on a Raspberry Pi Zero running in RAM

#59

Post by vednig »

dividuum wrote: post #56

I guess "Diskless" was defined by the same people that invented the term "Serverless"? That Pi is still using an SD card to boot from. A Pi with Ethernet can truly boot diskless via TFTP. And later Pi4 and Pi5 can even boot directly from the internet by getting their initial "boot.img" FAT partition via HTTP from anywhere. That would be diskless.

except in RAM based OS the page size and computation resources reduce significantly as OS is using the same memory to run instead of reading from disk and eating up critical memory area for applications, only thing in between a full crash and OS is the swap storage, macOS and Windows would never be even able to achieve this it is possible only due to Linux/BSD and it's level of optimization.

a better way would be to boot via nvme SSD, ethernet boot has a dependency of network, what if you need to debug when network is down or debug the errors/bugs network itself ?

Post reply on HN