51–60 of 87 posts
The shell script starts with the following comment: # All the code is wrapped in a main function that gets called at the # bottom of the file, so that a truncated partial download doesn't end # up executing half a script.
A serious question for any Linux-heads here, no insult intended. How is it possible that there are ELEVEN different possible package managers that need to be supported by an installation script like this? I can understand that some divergences in philosophical or concrete requirements could lead to two, three, or four opinionated varieties, but ELEVEN? Does that mean that if I want to write an app that runs on Linux…
If you write an app that runs on Linux, you should support flatpak, and (for bonus points) nix. The rest should be done by the distros' maintainers.
It's probably easier to script up the installation via package manager. You also get the benefit of upgrades along with the rest of the system.
Furthermore, I haven't seen a single instance of Flatpak being used to install applications on headless servers.
I also don't know many sysadmins who would be happy that each application they install in their servers will come with a full set of dependencies rather than being dynamically linked to the base system.
#!/usr/bin/env bash
set -u
grep -wq '^# asfewdq42d3@asd$' $0
[ $? -ne 0 ] \
&& echo "script is not complete - re-download" \
&& exit 1
echo "script is complete"
# asfewdq42d3@asd {
code
}
If only there was a way to transactionally run shell scripts such that if they don't complete fully, the changes are automatically reverted. Edit: cue the HN responses to use nix, and other solutions
Potentially sounds like a job for a BTRFS snapshot?
Solaris handled this by having a config file that you could specify which files to copy between boot environments. Don't have /var/mail,/etc/passwd,/etc/shadow,/etc/hosts,.... in a different FS ? Better remember to copy it, or you lose your emails,users,hosts,etc
The problem with this kind of failure mode is that it's silent and generally irreversible. There generally aren't tools to MERGE files that conflicted later on if you discover the issue while the old boot environment snapshot is still around.
On the other hand, this is sort of how Docker (and Solaris zones) work -- and why you can't upgrade a container in a container-like way, you must replace the entire container (i.e., any upper-COW is lost, unless you export it and build something new atop it outside of any sort of reconciled process).
On the other other hand, I've actually used BtrFS snapshots for exactly this successfully in exactly 1 case -- a read-only volume containing my OS files (12 files total; Kernel, Kernel Debug, Several Initramfs) for PXELINUX/EXTLINUX booting, for which can be atomically upgraded. Since it was read-only and the only operation supported on that volume was replacing the files, and it only had those 12 files, it was safe to do so.
A serious question for any Linux-heads here, no insult intended. How is it possible that there are ELEVEN different possible package managers that need to be supported by an installation script like this? I can understand that some divergences in philosophical or concrete requirements could lead to two, three, or four opinionated varieties, but ELEVEN? Does that mean that if I want to write an app that runs on Linux…
Sure, there is the linux kernel in different version and patch states, but everything else including on how to manage software(package manager) is something the distribution decides.
As there is no standard and for historic reasons, different distributions choose different package managers.
If you want to support linux you normally decide on which distribution you want to support and more importantly which version of them.
The big ones out there are probably ubuntu, fedora and arch.
Then you can decide between building packages for the different package managers or just build a static/dynamic binary that works on the distros and runs on them.
You can also use flatpack and snap which makes it easier to support different versions of the same distribution, but you run in a sandbox and afaik lower level access to the graphic stack(games) is a mess.
Yeah it is a mess, but at least most distributions have the same service/bootup manager
I've seen scripts (self-extracting archives for Linux, for example) that checksum themselves either by some trickery, or just ignoring the first line after the shebang (which itself is the computed checksum of the rest of the file).
A serious question for any Linux-heads here, no insult intended. How is it possible that there are ELEVEN different possible package managers that need to be supported by an installation script like this? I can understand that some divergences in philosophical or concrete requirements could lead to two, three, or four opinionated varieties, but ELEVEN? Does that mean that if I want to write an app that runs on Linux…
Normally it's not your job to package it yourself the distro maintainers do that
This probably means you can edit the script while it's running without it falling over confusingly. Might cargo cult this pattern - I'm very prone to editing a build.sh while it runs.