Where/how to install user scripts and tools

[jonct]

In principle, the standard location for user-installed scripts should be in ~/.local/bin. But that breaks down when the tool sometimes needs to be launched under sudo.

Has anyone else solved this well? Well enough to document for other users, such that it covers general cases?

[Lockszmith-GH]

The way I see it, there are 2 problems:

1. Privileged invocation from $PATH when in need of sudo - which breaks the PATH.
2. Persistence that is not tied to the user invoking the script, but to the system.

Issue 1: Privileged invocation

We either need (a) a sudo invocation script, (b) a shell alias/function, or (c) have the script to invoke sudo for us.

• (a) Create an additional script in the user's $PATH, it will invoke main script with the proper sudo arguments.
  Pros: main script does not contain any privilege escalation code.
  The main issue the needs to solve is the deployment of this script.
  A possible solution would be to have the main script generate this simple shell script in any location we choose (and it's the user's responsiblity to make sure it's in the $PATH)
• (b) shell alias/function:
  Similar to what we have today in the README.
  Users will need to edit their .bashrc files for this
• (c) escalate privileges from the script
  In order for this not happening automatically, we can require a --with-sudo argument that will invoke the script with the same arguments under sudo.

I like the user-side simplicity of (a), for the dev side, (c) seems rather simple.

Issue 2: Persistence

I'll just add that ther requirement is specifically in TrueNAS SCALE - which gives us OS access (including root), but only an immutable read-only OS root file-system.
While this is a problem, we also benefit from knowing the OS is TrueNAS SCALE which comes with some 'perks', like ZFS.

I say, let's have the script do a double-take autodetection and installation - similar to what it does today, utilizing ZFS User Properties.

We can still use environment or cli arguments, but use a similar approach to iX, by storing metadata in a location we designate, and then rely on that data exclusively.

As long as we set the properties at the root of the pool, I believe we shouldn't hit any performance snags.
The path in the props should be relative to the root of the pool its set on.

Example:

• path of jails root is: /mnt/tank/mydata/myjails
• prop should be: mydata/myjails

So, order of detection:

1. a cli parameter
2. env variable
3. auto detect via ZFS props

As long as there is only 1 such pool, we should be good to go.
If you think multiple pools might exist, you can choose to add an active-on-hostname or just active prop, but that's a design descision I'm not sure we need to make now.

Example on setting the prop:

# zfs set "com.github.jip-hop.jailmaker:jails_path=mydata/myjails" tank

reading the props (d0 here makes sure we're only querying the root of all the attached pools):

# zfs get -Hd0 -s local "com.github.jip-hop.jailmaker:jails_path"
tank       com.github.jip-hop.jailmaker:jails_path       mydata/myjails  local

Followed by:

# sudo zfs get -Hd0 "mountpoint" tank/mydata/myjails
tank/mydata/myjails mountpoint      /mnt/tank/mydata/myjails    default

[Lockszmith-GH]

Actually, what I look for in these 'one-line installers' is automation, not hand-holding.
I'm interested in having the ability to script a system into existance.
That's my drive. It's not about hand-holding.
I don't want the script to do anything other than place it in an exceptable location, and if some tying in to the system is required, to state clearly what that is, and I'll do it.

What I see in the scope of an installation script:

• Placing the necessary exceutables in a the correct location (/root/bin for example) or a pool location with good configuration options to point at (like the zfs props, or env variable).

• Being able to fix any missing component in case iX reverts the boot-pool

• Allowing for an easy update detection and automate the upgrade process to make is as simple as possible

• Elevation, only when explicitly asked for.

[jonct]

I like it! I suppose an interactive wizard isn't the right tool for this job, either. 🧞

In effect…

• README.md
• supplemental wiki or Advanced-Detail.md
• install-jlmkr.sh

… are all just equivalent means/media to document the steps needed to install. All three encourage responsible usage; none leads users into any black boxes or scary roadblocks.

I think any (or all? some?) beats code-golfing an ornate wrapped one-liner block to be copied/pasted wrong if not quietly munged by a CMS or browser first.

Being able to fix any missing component in case iX reverts the boot-pool

This is the only point for which I'd say my interactive installer transcript would be more effective. (I implied but didn't state that it's really a "doctor" transcript: checking and offering to fix any piece that needs help.)

But we can make up the difference with clear, meaningful error messages at runtime.

Elevation, only when explicitly asked for.

Ideally: only when explicitly granted at launch. Don't just leave the chainsaw on the table; don't be handed a chainsaw. 🌋

We still haven't figured that out yet, unless we're comfortable with /home/.shared/bin or similar. (/root/bin isn't user-accessible; user and root would end up with different versions installed. As would other users.) Even keeping the tool at the root of its own fiefdom doesn't solve this; that's only worked due to promoting reflexive sudo.

I don't yet quite follow why you'd want automated updates if you don't want automated installation, but I'll go along. Some helpful precedent for that might be the k9scli project: it tells you when there's a new version, but doesn't embed any magic code to go get and install it. You simply [re-] download the tool, and put it where you want it.

[Lockszmith-GH]

unless we're comfortable with /home/.shared/bin or similar. (/root/bin isn't user-accessible;

I'm not sure /home/.shared is viable, but /mnt/tank/<somewhere> is, and we can create symlinks from ~root/bin as well as ~<our_user>/bin

[Lockszmith-GH]

I don't yet quite follow why you'd want automated updates if you don't want automated installation

I want automated everything, as long as I can take a part that process and make it my own.
Every update process has the following steps:

1. check if an update exists
2. download the necessary files
3. perform the update

As long as all of these steps can be achieved by a single tool, and I can perform them to my liking, I want it.
We don't have a package manager to rely on, so I say we roll our own, overly-simplified process into the script.

My main gripe of not having that handy is context switching.

You ask: "How hard is it to open the web browser, copy the URL from the release page, download the file with curl, extract it, and let's not forget to remove any flufh from the previous version?"

(Please read everything in a friendly, jokingly voice, NOT to be read in a passive-agressiv tone)
It's not hard, but if it can be automated, I want that option.

I mean, "How hard is it to actually use systemd-nspawnd without jailmaker?"
Well, we're here - aren't we?

[jonct]

Ah — sorry; I caught your edit late.

Yeah, I'm totally cool with your opening a web browser, copying an install script's URL or a magic shell incantation, and proceeding from a downloaded script rather than from a downloaded archive. For the record I have no qualms if you choose to pipe the script directly to bash. (I do hope that this last part is never seen as an official recommendation.)

Overall I think we're on the same page on posting a clean, simple, sing-along installer script. Putting all installation steps in a well-documented script frees up the readme to instead focus on requirements and basic operation. What's left would read more like it's intended for human consumption.

I currently have a slight preference that any installer/updater script not be buried inside the tool itself but alongside. Self-modifying root-privileged code has its own reputation.

But a nice readable shell script, easily found and summoned from the top of the repo, would be great. And I'm sure some user somewhere would even feed it to cron, for silent updates.

I see this as entirely compatible with a downloadable release archive, containing a tool and a readme. I see the script pulling from the archive, and I see checksums being based on the archive. (Call me a refugee of DOS-to-Mac-to-Unix text file exchange: I suppose I see software as needing differentiated, pure binary handling.)

Prioritizing scriptability seems to only prefer .tar.gz over .zip. And that makes me happy.

[jonct]

Has anyone else solved this well? Well enough to document for other users, such that it covers general cases?

OK… I've pored through the latest sudo(1), sudoers(5), sudo.conf(5), and visudo(8) to refresh my memory.

Recommendation

1. Create a /root/bin directory.
2. Edit sudoers to tack on /root/bin to the end of the secure_path default.
3. Symlink individual authorized tools into /root/bin.

How to

sudo mkdir /root/bin

Always edit sudoers using the supplied guard rails.

sudo visudo

The relevant line to edit is fairly clear.

Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin

Extend the path with :/root/bin at the end, so that built-in/protected tools always still take precedence over user-added tools, particularly when called by other scripts.

Then, for example, if you install ~/.local/bin/jlmkr for yourself, you can create a symlink. Your shell will expand the tilde before upgrading to sudo and creating the link.

sudo ln -s ~/.local/bin/jlmkr /root/bin/

Done and done. 🥳

Also considered

Trying to chart a decision tree through all the permutations of /root/.bashrc and /root/.zshenv and such could be a mess.

/root/bin on its own is not visible to users outside of sudo.

I don't think there's a good/responsible way to explain how to use visudo to whitelist a particular user to a particular script. Nor do I see a way (through the above components) to alias a tool name to an absolute path, so it's a moot point.

The default secure_path setting is there for good reason and should not be bypassed.

Having secure_path point to a regular user-managed directory is calling for trouble. (Though not too bad, provided you ensure the appropriate precedence.)

But Debian's choice of /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin intends for us to add items to /usr/local, and iX has that walled off from us. So IMHO we should append /root/bin (or /root/.local/bin) to the end of sudo's built-in paths, and we'll stay in line with Debian's security posture. Then the user can curate individual authorized tools through symlinks to wherever they live.

Hit me

Have I missed anything?

[Jip-Hop]

I'd say create a PR for iX with this change: Defaults secure_path = /sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin and see what happens. 😜

[jonct]

Is it possible that you're working a different problem than I am?

[Jip-Hop]

I don't think so. I'm just saying that your suggestion will be wiped, more often than you realize. Open a shell. Run sudo visudo. Make some changes. Then go to https://truenas.scale/ui/credentials/users and edit a user. Toggle Allow all sudo commands and hit Save. Check again with sudo visudo, your edits will be gone.

[jonct]

I don't imagine I'll have made such administrative changes by accident. Nor on a lark. I'm confident I'd face symptoms soon enough to recognize their connection. And in general I'd venture that one's frequency of restarts would tend to scale with the intensity of one's poking around under the hood.

Maybe the terrible horrible worst likely case would be upon creating a new administrative user? I could see that one. Especially when paired with one of my blindspots: I'm not really thinking in terms of mission-critical TrueNAS SCALE deployments with more than one administrator (let alone floating administrators). I tend to think the target audience is mostly in homelabbing territory.

I could offer you a technical response, in case we are truly working the title investigation at face value. Or I can offer you a social/diplomatic response if there's more to it than that. I'm honestly not sure which way to go here.

The technical matter

IMHO this tweak is not nearly as elegant, but is pretty clever in its own right. The Redditor's details don't fit SCALE but his core idea does.

/etc/sudo.conf does exist — as a fully commented-out placeholder — and does survive a restart. (Yes, yes, not an upgrade.)

So through sudo.conf you can tell sudo to use a bypass policy file. That file would have two lines: 1) import the official managed sudoers file and 2) reactivate Debian's /etc/sudoers.d directory. Then put your customizations in the directory.

The diplomatic matter

I seem to be walking into a number of rakes, and… well, I'll stand by my earlier guess: making this to some degree less fun for you.

I'm not looking for a fight on any of it. Certainly not on this topic, which is ultimately not even about Jailmaker. It just emerged from Jailmaker discussions, and showed promise for generalization to a longstanding problem that a number of us have identified.

I don't know how to offer you some space without risk of it coming across as a petulant threat to walk away from the project. (That is, unless my going away would allow you to stay, in which case we unanimously prefer that you do!) But I do happen to have quite a bit to catch up on after this week, so it's sincere: I'm not disengaging but I'll go attend to some other priorities for a bit.

Much affection, my friend. ✌️

[Jip-Hop]

Good job on the research! You now have all the ingredients to make a solution which will survive reboot, upgrade and sudo related edits made through the GUI. 😀 And great to see you've opened a feature request about this on the forum. Perhaps post your idea there too? There's a better chance iX will chime in there.

All the best and wish you luck with the catching-up.

[Jip-Hop]

What do you think of this as a general solution?

Post Init Command:

mkdir -p /root/usr-local-bin && mount -o remount,rw /usr && mount -t overlay overlay -o lowerdir=/root/usr-local-bin:/usr/local/bin /usr/local/bin; mount -o remount,ro /usr

This will temporarily remount /usr as read-write, then overlay mount /root/usr-local-bin underneath /usr/local/bin and remount /usr back as readonly as if nothing happend. Put your executables inside /root/usr-local-bin and they shall be available globally for any user, including for use with sudo.

Since /usr/local/bin is the last dir in the default secure_path it can't override any of the commands in directories that come before it. Since /root/usr-local-bin is the lowest lowerdir, it can't override anything already in /usr/local/bin (only augment it). So looks secure to me and free of conflicts. And of course only root can put files in /root/usr-local-bin.

This will survive reboots, updates and upgrades.

I find this a more direct way to make executables globally available then by changing sudo.conf and related files. Of course neither way is supported by iX. But I expect the overlay mount workaround to break in less unexpected ways in the future.

It's quite elegant if you ask me. 🙂 But I agree there needs to be an officially documented (in the TrueNAS docs) way to do these kinds of things as you suggest.

[Jip-Hop]

Turns out the Post Init Command even works this way (without first remounting /usr as read-write):

mount -t overlay overlay -o lowerdir=/root/usr-local-bin:/usr/local/bin /usr/local/bin

[jonct]

Sweet! That removes the one known element of danger, and makes it a clean readable one-liner. 🙌

I haven't been able to test this, yet. Does it not require -o remount?

For anyone experimenting: if this were applied for more than …bin then it would look like the following. And then build systems like cmake would correctly handle any needed dylibs and manfiles and such — you'd just tell them to use a prefix of /root/.local. (System libs will take precedence at runtime, so do link with the system's libs at build time. That's typically the default.)

mount -t overlay overlay -o lowerdir=/root/.local:/usr/local /usr/local

Is this note anything of concern? My off-the-cuff guess says that's primarily about open files in a read-write top directory. But it could possibly suggest a need for some sort of flush or remount after making changes on the lower deck.

[Jip-Hop]

/usr/local/bin is not a mount by default so I that's why I think it doesn't need the remount options. The flush you mention is something to try indeed.

[Lockszmith-GH]

that's the cleanest solution, I like it very much.

This is exactly what jlmkr satrtup should do.

[jonct]

I may have steered you wrong on dropping mkdir. 😔 The worst case mistake wouldn't be trying to mount a directory that doesn't yet exist, but rather trying to mount one with the wrong permissions.

Casual sudo mkdir for me created the directory as 0700, causing iX's tools to lose visibility after restart. I'm not sure everyone would recognize what happened or what to do about it. So now I'm here:

mkdir -pm 755 /root/.local && mount -t overlay overlay -o lowerdir=/root/.local:/usr/local /usr/local