Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
This entire trend needs to die. Package managers exist. Use them. Shun and shame sites that promote shell script installers.
Apples and oranges.
Package managers only install a package with defaults. These helper scripts are designed to take the user through a final config that isn’t provided by the package defaults.
No need to be elitist about such things.
EDIT: this particular repo is highly regarded in the community. It is very akin to the AUR. It’s not some haphazard collection of scripts.
Whether there's a setup wizard doesn't have anything to do with whether the tool comes from a package manager or not. Run "apt install ddclient", for example, it'll immediately guide you through all configuration steps for the program instead of just dumping a binary and some config text files in /etc/.
So that's not the bottleneck or contradiction here. It's just very unfortunate that setup wizards are not very popular as soon as you leave Windows and OSX ecosystems.
No, package installers support configuration. Plenty of packages (e.g. postfix) prompt for configuration at install time.
This is trivially solved by having a "setup" script that is also installed by the package manager.
Heellll no, the scripts are publically available to read over if you're sketched out. They save you so much time to actually get to using the service. 98% of my homelab is from these same helper scripts too.
RIP tteck
Have you ever looked at what was once ttek scripts? They're a spaghetti of calls to other scripts. It's not pretty. And not intuitive to audit.
Wtf you're my opposite D:
I did and had a decent time with ctrl shift F'ing around. Took a moment since bash isn't my strong suit.
You can install with package managers and include with it a helper script to setup the service. No big deal.
But can you spot the difference between
http://myservice.com/script.shandhttp://myserv1ce.com/script.shif you use a font that doesn't make it clear? If you get people used to just copy/pasting/running scripts then there's a risk they'll run something entirely different by accident.There's no good reason to install things this way.
But this is a trusted source with years of credibility. Why would any sensible competent tech user copy paste from other places because this one worked.
You'll be pissed when you hear about Linux game server manager then. It's all helper scripts over https
Because sites like this and people like you are normalizing the practice. I have seen numerous curl | sh commands pasted on lemmy telling people "how easy it is to install blank".
Nobody has ever explained why. What is the difference between executing a script directly from curl, and adding a repository which downloads a package which contains a script.
The URL can point to a different file. People can post maliciously similar URLs and trick you into running something else.
With a repository you have some semblance of "people have looked at this before". Packages are signed and it will provide a standard way to uninstall and upgrade in the future.
There's literally no good reason to replace it with a shell script on a website.
I fully agree that a package manager repository with all those tools would be preferable, but it doesn't exist, does it? I mean... content is king. If the only way to get a certain program or functionality is a shell script on a website, then of course that's what is going to be used.
There is no functional difference to piping a script vs running an AUR or other user repository install.
If anything it is easier to self audit the script.
But nobody ever actually audits the stuff they run so...
Eh... I have my own repo that pulls the PVE repo and updates a bunch of things to how I want them to be and then runs a local version of the main page. While I don't stare at every update they make... There's likely enough of us out there looking at the scripts that we'd sound some alarms if something off was happening.
Which puts you ahead of the curve. But you are still depending on enough other people to be watching every update and so forth.
I am not saying I am much better. But it is one of those things where anyone considering the selfhosted Fun should REALLY spend some time dealing with software supply chains and the like. Too many people just figure "it is open source so it is safe" or, even in this thread, assume something is more or less safe based upon what app pulls it.
Sure, but my point is that it's no different to an AUR/user repo. At some point you're just trusting someone else.
I think the whole "Don't put bash scripts into a terminal" is too broad. It's the same risk factor as any blind trust in ANY repository. If you trust the repo then what does it matter if you install the program via repo or bash script. It's the same. In this specific case though, I trust the repo pretty well. I've read well more than half of the lines of code I actually run. When tteck was running it... he was very very sensitive about what was added and I had 100% faith in it. Since the community took it over after his death it seems like we're still pretty well off... but it's been growing much faster than I can keep up with.
But none of these issues are any different than installing from AUR.
The rule should just be "don't run shit from untrusted sources" which could include AUR/repo sources.
I’m a real beginner with this stuff and I read through the install scripts before running them. But it wasn’t for security, I just wanted to see if I could learn some tips since I had already struggled to do it manually.
How do you "undo" whatever that script did?
AUR repo items don't necessarily clean themselves up properly either. So I'm not sure why you think that's part of some requirement for the scripts if we're comparing the 2.
Edit: But in the case of this specific repo... You delete the lxc or vm that you created.
In the case of these ones you just remove the LXC/VM it created.
Neat. Now you have a snowflake install. How do you upgrade it?
Upgrade what? The LXC/VM you just removed because of a wonky script?
You went on with this for way too long, my guy. We get it, you don't like the helper scripts.
Did you purposefully misunderstand me? How did you not know that I meant "how do you update the thing you installed with a rando shell script" and not "how do you update something after removing it"?
You go into the LXC's console and type
update, or use whatever package manager is available in the LXC.I'm pretty sure for most of them you just type
updateand it will update.Fun fact, a malicious server can detect the difference between you loading the script for inspection in your browser, and you doing
curl | sh, and could serve an entirely different script.https://lukespademan.com/blog/the-dangers-of-curlbash/
Yeah - it's remarkable that I receive pushback about it. I guess it's down to the technical immaturity of your average home-gamer vs. people who support Linux systems for a living?
IMO these kinds of poor man's automation scripts are only useful to novice sysadmins but those are exactly the kind of people who shouldn't be running scripts they piped from the internet for both the fact that it's risky behaviour and the fact they don't then get the experience doing this manually for themselves to move on from being novice.
That said, let's not gate keep. If novices don't want to gain experience actually doing sysadmin work and level up their abilities and just want stuff that will probably work but that they'll not be able to fix easily if it doesn't, at least it's a starting point and when things break some of them will look deeper.
This shouldn't be an excuse for promoting risky behavior.