Ibramenu: Bash-based self-hosted app deployment
ibramenu.io
ibramenu.io
[0] https://ericaheinz.com/notes/give-it-the-craigslist-test/
It's a trusted, proven system, that's free and open source and is easy to use. It's truly an endlessly scalable thing.
See also other subcomments.
(Edit) So, I checked out the repository, I personally wouldn't use it or recommend it to anyone. It's a collection of bash scripts, it'd be a pain to debug, log and fix. Ansible playbooks are a much better option. You should be able to version control your deployments and configurations these days.
More specialized systems may bring the burden that they are harder to debug (Ansible is also astonishing hard to read the debugs' -vvv output btw.) but with the benefit to be better suited for the specialized job.
And as long as you've got the sources, you can easily put it under version control. I fail to see why this should be only possible with python scripts and yaml files and not with shell scripts.
it writes its alias in the global space instead of the local user
echo $insert_alias | sudo tee -a /etc/bash.bashrc
This feels like a tool for users switching from windows to linux, to be able to flatten the learning curve. For any user that is a little bit familiar with linux, this i a major downgrade to any other toolset IMO.
i would open an issue, but they don't offer that on the repo
to post feedback you have to register with a service called "Canny"
the other issues channel is discord
a few suggestions:
- run shellcheck and fix the issues and warnings
- publish tags, so people can select versions
- add customization to the installed packages
- actually document how to use the parameters, the scripts offer, instead of just not doing that
- add an uninstall script!
- add a silent command (run with parameters to automate the menu selects, why would i want to do this manually or remember what i selected on every machine?)
I mean its free and all, but reads like a product, which needs a developer who cares about a few industry standards, or just needs more time (first code commit was on Nov 27, 2022
Sounds like it fits their needs, but ansible sounds like a much better choice and also sounds like they have the "not invented here" problem
Not exactly putting key information front and centre.
shellhardenand your shebang line should be `#!/usr/bin/env bash`, not `#!/bin/bash`
the current state of your project does not inspire confidence
everything i've said here is objectively true
From https://news.ycombinator.com/newsguidelines.html:
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
I can see someone interpreting your argument as "shallow," at least in the sense that the project overall may still be useful. Or it might be a good start, or they need your help to improve.
Also:
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
(And I say this as someone who, just this week, forgot to change #!/bin/sh to #!/bin/bash when I started adding Bash-specifics to a script.)
so IMHO barking the wrong tree.
And anyway I've been writing shell scripts for over two decades and can't remember the last time I've seen foo.bash, if I've ever seen it at all.
Try to say it in a nice manner. Please consider making a PR or GitHub issue instead. Being civil makes people thrive, and easier accepting your feedback.
Don't get me wrong: I often make the same mistake you made. Its a continuing learning process, and being on the spectrum doesn't help (at least, in my case not).
I agree that the shebang should be #!/usr/bin/env bash though.
That's not at all a given.
This will use the first "bash" that it comes across, which has its good and bad points, while `#!/bin/bash` will use that specific one (if it exists). If J. Random User has been manipulated into installing a fake bash (or if the package installer or whatever has installed a fake bash) somewhere in his path, the env method can be very bad indeed. In general, that's going to be a far easier thing to do than installing a fake bash in /bin.
In general, /bin/bash is gonna work fine, either because that's where it actually is (the overwhelming majority of *nix systems in use today, including most or all Linuxes and macOS), or the system and/or system administrator has created a link from /bin/bash to where it's actually located.
It doesn't really gain you a whole lot anyway. If there's no guarantee that bash is located at /bin/bash, there's even less of a guarantee that env is located at /usr/bin/env.
/bin/bash is not reliably present -- there is no guarantee that bash exists on a system at all, really!
It doesn't have to be in /usr/bin.
some ancient rhel systems put it in /bin/env, i believe, but in that case they usually symlink /usr/bin/env to it, or /usr/bin to /bin at least
i've seen way more systems that don't have a global /bin/bash than systems that don't have a /usr/bin/env
as an example, /bin/bash on macos is forever stuck at version 3.2.something, if i run across a bash script that uses crazy features like associative arrays, i definitely want it to use the modern version of bash i've installed to my $HOME/bin/bash