chore: Add debug group (packages.sh) + more resilient rspamd setup#3578
chore: Add debug group (packages.sh) + more resilient rspamd setup#3578georglauterbach merged 10 commits intomasterfrom
packages.sh) + more resilient rspamd setup#3578Conversation
I despise `nano`, but `(neo)vi(m)` has too many dependencies which would blow up image size. Moreover, `most` has been added, and I linked it to `less` because I am not aware of many users knowing `most` so linking it to less seemed appropriate to me.
As a Rust-programmer, I expect immutability by default. Having it comes with nice properties. In Bash, you have to explicitly make a variable immutable. This comment does exactly that for the Rspamd setup.
We now also check whether the variable is unset to provide a more accurate error message.
georglauterbach
added
area/scripts
kind/improvement
polarathene
left a comment
polarathene
left a comment
There was a problem hiding this comment.
LGTM 👍
Mostly opinion below (quoting specific commits), I'm happy with the changes as-is.
add
readonlyto Rspamd setup script where appropriate
As a Rust-programmer, I expect immutability by default. Having it comes with nice properties.
In Bash, you have to explicitly make a variable immutable.
This comment does exactly that for the Rspamd setup.
You probably meant commit there in the commit message? 😛
While I agree immutability by default is nice, I'm not sure if I'd want to see readonly introduced throughout the codebase. We haven't hit any mutability issues yet right? Granted it's an easier workaround vs migrating from bash scripts to rust (or embeddable / script languages built off rust).
To clarify, readonly after / during variable declaration is just locking it from accidental future modification?
refactor
packages.shand add proper text editor
I despisenano, but(neo)vi(m)has too many dependencies which would blow up image size.
Moreover,mosthas been added, and I linked it tolessbecause I am not aware of many users knowingmostso linking it to less seemed appropriate to me.
Not sure about the symlink idea. It's with good intentions and probably harmless in the common scenario of just calling the binary by its name, but if trying to use some options to launch or navigate (eg: pattern search), this will probably be unexpected and a bit confusing initially to the user. Might result in bug report being raised too.
Personally, unless there's any notable advantage towards the UX for users with the command to troubleshoot within a container, it seems we'd be better off providing the familiar less. Alternatively a docs section that mentions the extra debugging packages we include can mention most there for discoverability and would fit right well on our debugging docs page.
I had a brief look at less vs most and I'm not entirely convinced that it's a better offering (and since the SE discussion was from 2013, not exactly "new"). Not blocking but the suggestion to switch to most gave a different impression 😅
- https://www.baeldung.com/linux/more-less-most-commands#comparison
- https://unix.stackexchange.com/questions/81129/what-are-the-differences-between-most-more-and-less/606397#606397
Indeed: $ readonly --help
readonly: readonly [-aAf] [name[=value] ...] or readonly -p
Mark shell variables as unchangeable.
Mark each NAME as read-only; the values of these NAMEs may not be
changed by subsequent assignment. If VALUE is supplied, assign VALUE
before marking as read-only.I will switch to |
polarathene
changed the title
packages.sh) + more resilient rspamd setup
georglauterbach
dismissed stale reviews from casperklein and polarathene
via
46d2ef1
3 participants
Description
This PR does 2 things (and I was too lazy to provide two different PRs for these small changes):
packages.shto installmostandnanoand removeed, adding a dedicated set up packages for debugging (first commit)Follow up of #3576
Type of change
Checklist:
docs/)