I only discovered this recently, and it’s very handy.
Piping scripts directly to bash is a security risk. You can always download the scripts, inspect them and run locally if you so choose.
Piping scripts directly to bash is a security risk. You can always download the scripts, inspect them and run locally if you so choose.
This entire trend needs to die. Package managers exist. Use them. Shun and shame sites that promote shell script installers.
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.Piping scripts directly to bash is a security risk
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.
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.
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.
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.
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.
This is trivially solved by having a “setup” script that is also installed by the package manager.
I asked repository maintainers and they said “LXC is not for apps” and of course docker is a good way to waste your weekends. So we don’t have repositories, we have scripts.
If you disagree, go tell them
https://discuss.linuxcontainers.org/t/where-can-i-find-the-biggest-lxc-container-repository/14946
Until then, people who have sacrificed enough of their weekend to the linux gods will be pipe internet text into their root consoles
Until then, people who have sacrificed enough of their weekend to the linux gods will be pipe internet text into their root consoles
“I’ll do what’s easy even if it’s not good” is a terrible approach to, well, anything. I would expect people in this community to look for guidance on what the best way to do things is. Seems I’m wrong.
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.
That said, let’s not gate keep.
This shouldn’t be an excuse for promoting risky behavior.
