this post was submitted on 25 Oct 2023
33 points (76.2% liked)

Selfhosted

39257 readers
202 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 1 year ago
MODERATORS
 

I'd like to have my own server at home sorta like a home AWS.

How to set up one and make it available to anyone over the Internet? What tech specs should I buy (RAM, CPU, # of cores, operating system, etc.)?

How much does it cost to keep one running all the time?

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 2 points 11 months ago* (last edited 11 months ago) (1 children)

There multiple issues with those Debian images and while I would love to run them, they don't cut it. Generic images might underperform in your board, the GPIO and other low level components will, most likely, not work and you might burn your storage as logging and other I/O intensive operations aren’t tweaked for SD cards.

There's also Armbian (https://www.armbian.com/rpi4b/) but only Ubuntu based right now. Armbian could be a great solution however there has been not much interest in the RPi board most likely due to what I pointed before.

[–] [email protected] 3 points 11 months ago (1 children)

Also WRT telemetry: https://forums.raspberrypi.com/viewtopic.php?t=341514

The only telemetry is pertaining to what the imager is burning to the card. So if you don't use the imager there's no telemetry, if you use the imager but disable telemetry, there's no telemetry, if you don't disable it, it just sends back what you're installing.

[–] [email protected] 1 points 11 months ago (1 children)

Here the problem: they're forcing people into the Raspberry Pi Imager with shady tactics. Without it you won’t be able login via network out of the box and by default it enables telemetry. This isn't okay.

[–] [email protected] 1 points 11 months ago (1 children)

I've already spoken about the "telemetry" but here's your ssh login. Literally all the installer is doing is adding a blank file.

https://phoenixnap.com/kb/enable-ssh-raspberry-pi#:~:text=If%20you%20use%20your%20Raspberry,SD%20card%20to%20enable%20SSH.

Then if you don't want to do that every time, just create an image for it. That's your new image to flash onto the SD cards.

There's nothing stopping you from not using the imager. dd works just fine. There's no telemetry on the OS itself, so here's how you personally get what you're looking for.

  • dd the base image to a card
  • verify the card and image are working properly by booting on a pi
  • turn off pi
  • insert card into computer and create file in boot directory
  • create a new bootable backup image from the card, and save that on the computer it's plugged into, cloud or local backup storage you're running, whatever
  • dd that image as the base image for all new cards.
[–] [email protected] 1 points 11 months ago (1 children)

but here’s your ssh login. Literally all the installer is doing is adding a blank file.

Yes and why are they forcing us to go through hoops / non standard BS instead of doing it like any other SBC and just enabled by default. Armbian does it and once you login you're required to change the password for security.

I remember before the imager the RPi also had SSH enabled by default. Don't sugar coat it around security, this is bullshit to force people into their imager.

[–] [email protected] 3 points 11 months ago (1 children)

None of this forces you to use their imager though... It's barely a hoop, most people running multiple pi's as servers will have done this for a reason other than ssh anyway.

And yes one solution to this security problem is to require changing the username and password, the more effective solution is to not have the process running at all, unless specifically enabled. I'm sure that sentence sounds familiar from your company's security team.

Raspberry pi's serve a lot of purposes, many of those purposes don't need ssh. But if you enable it by default that opens the pi up to being a target, which we saw be a huge problem before this change.

Also, this is not the only distribution that has ssh disabled by default. It's just the only popular distribution I'm aware of that doesn't have a server image option 🤷‍♂️ it's actually standard security procedure.

For example, if you install Ubuntu desktop, it'll have ssh disabled, because it is standard. Pretty much any distro should do this as well as long as it's not their "server" ISO.

In any case it's a good practice to backup your images regardless of what hardware you're running on, especially if you're running a cluster, it allows for easy reproduction across the cluster.

[–] [email protected] 1 points 11 months ago (1 children)

The most common use case for a RPi is people who just want to hook it into some electronics and play a bit with it, very much like a modern day Arduino. The second most common is some kind of server be it simple SMB share, DLNA wtv. The 3rd case is custom images like retropi, home assistant etc... In the first tow having SSH by default greatly simplifies things.

People who deploy professionally / on scale / create customs images for other things are tech savvy enough and know how to disable SSH - no need to have it disabled by default.

[–] [email protected] 1 points 11 months ago (1 children)

People who deploy professionally / on scale / create customs images for other things are tech savvy enough and know how to disable SSH - no need to have it disabled by default.

I think you've solved your own problem. The people that are savvy enough to do it know how to enable it and it's not a real impact to them. But by disabling it, the people that don't are protected. Which is why this is a standard practice across Linux distros.

[–] [email protected] 1 points 11 months ago

It could be standard practice across Linux distros but not standard across SBCs...