Repository navigation
Does rustup.rs support shared .multirust (or whatever) directory? #313
Description
Activity
It does not support it now, and I haven't considered exactly this scenario before.
It is related to the use case of installing rustup globally, or toolchains globally. Is it mostly the toolchains you want to share? I'm not sure if there's a use case for sharing anything else.
I'd like to install rustup.rs globally & install toolchains globally as well. The Rust installers can't install multiple targets on a host, so rustup.rs is really the only reliable way of installing and maintaining multiple Rust targets/toolchains. And it's critical to install globally on multi-user machines, because I don't want to use
n_users*n_toolchains*100MBof HD space.Reacted by Wayne Nilsen, Florian, iocast, Prabhakar Dev, Ige, userxfce, Leon Busch-George, rokit, theshank and Martin HabovštiakThanks for the feedback @alexchandel!
I'm afraid I still haven't put much thought into how global installation might work. Offhand I might expect that global rustup installation and global toolchain installation are two independent things. Maybe the
-gflag torustup-initwrites the bins to/usr/local/binand the-gflag to toolchain commands writes to somewhere globally. Lot of details to work out.There's also two types of global toolchain installation:
- A shared set of toolchains between all, or a group of users, that any user in that group can modify.
- A set of toolchains that only root can modify.
In both cases, you'd want those toolchains to be "inherited" so that a user can still have a user-specific set of toolchains, and can switch between global and local toolchains easily.
One thing we should be very careful about is permissioning: whatever we do, we should make sure never to put root-owned files in the user's home directory, and should never do what
npm install -gdoes, where the requirement to use sudo becomes contagious.One thing we should be very careful about is permissioning: whatever we do, we should make sure never to put root-owned files in the user's home directory, and should never do what npm install -g does, where the requirement to use sudo becomes contagious.
Yep, this is an easy mistake to make. Run
rustupas sudo thensettings.tomlis mysteriously owned by root.Reacted by Peter Lyons Kehl@brson Provisionally, I'd just like globally accessible toolchains. If I move rustup's folders from
~/.cargoand~/.rustupto/opt/cargoand/opt/rustupand add/opt/cargo/binto the path, will it work normally? As in, will toolchains continue to be installed to/opt/rustupand crates downloaded/cached in the user's home directory?Reacted by userxfceAny updates on this?
Reacted by userxfceHas anyone found a way to install rustup for all users so that it works?
@alexchandel This one didn't work: #1085 (comment)@brson What do you think of this strategy:
Non-windows:
- Relax anti-sudo check, so that it succeeds if
$UIDor$SUDO_UIDcorresponds to the correct home directory, but it will callseteuidandsetegidto switch to the original user before continuing - Run anti-sudo check as the first step on every invocation of rustup, except proxies
- Add
-goption to toolchain modification commands to install toolchains globally, by callingseteuidto temporarily switch back to root - Global rustup directory controlled by
$RUSTUP_GLOBAL_DIR, defaulting to/opt/rustup - This directory has the same structure as
~/.rustup, but without asettings.tomlfile - Rustup is installed globally by placing
rustup-initin/usr/local/bin - Each user can switch from a system-wide rust install to rustup by running
rustup-init - When rustup first creates
/opt/rustup, it will automatically create a global linked toolchain namedsystem, which points to the system-wide rust installation, if it exists
Windows:
- Add
-goption to toolchain modification commands to install toolchains globally. - If process needs to modify a global toolchain, and is not eleveated, use
ShellExecutewith therunasverb to self-elevate via the UAC prompt - Global rustup directory controlled by
%RUSTUP_GLOBAL_DIR%, defaulting toC:\ProgramData\rustup - Rustup is installed globally by installing
rustup-inittoC:\Program Files\rustupand creating a start-menu shortcut which runsrustup-init - When rustup first creates
C:\ProgramData\rustup, it will automatically create a global linked toolchain for each rust installation installed using the old installer, and named appropriately with asystem-prefix
Both:
- Commands which resolve toolchain names, but do not modify them, will look for user-local toolchains first, and fall back to global toolchains if the first is not present
- Use the
global:<toolchain>syntax to explicitly choose the global toolchain if there is a local toolchain with the same name
Reacted by Timothy Hobbs, ET, jyn, Ltrlg and userxfce- Relax anti-sudo check, so that it succeeds if
@vi I was focusing on global toolchains in the style of npm, where root is required to install globally.
You seem to be suggesting a different feature - the ability to have two or more users share the same
RUSTUP_HOMEdirectory - what exactly needs to change wrt permissioning for that to work?@Diggsey, Unpacking crates (tar archives) should ignore file modes except of +x. In other words, behave like in Git.
Shared group, g+rwx, sticky group bit and umask
002(instead of usual022) on rust home directory should make all files created there fully accessibly to the group, not just one user. Except of when access modes are changed explicitly, which happens when cargo unpacks crates (because of file and directory permission bits are stored in tar archives and usually it is0644/0755, corresponding to the default umask0022).@vi I'm not sure I follow: we were talking about a shared
RUSTUP_HOMEdirectory, but cargo doesn't put any files there. If there are no rustup changes to make, then I'm not sure what you meant byIs modifying un-tar-ring to respect umask deliberately omitted?
This is the rustup issue tracker 😛
I though for a moment that it is about multi-user strategy for entire Rust, not just rustup.rs.
Is there any progress on this issue? For my work we have several machines running Raspbian on ARM where the latest packaged version is 1.24, so it's very difficult to get work done without an update-to-date version of rust.
Reacted by userxfceThere has been no work on this, no. If you have ideas, I'm prepared to entertain approaches to make this sane and safe. (bear in mind rustup already has a whole host of "we don't lock stuff" problems)
I share
.rustupbetween two user accounts, but runrustuponly from one of them (it has umask0002). Also the directly has sticky bit set. Seems to work.As mentioned in #313 (comment), It looks like there are actually two separate feature requests here:
- Have globally writable rustup installations, where any user can read/write to the directory (assuming sufficient permissions)
- Have a globally readable installation.
#1085 is only for the second use case (which is my use case) but was closed as a dupe of this issue. Is is possible to try solving 2. before trying to solve 1? That seems to me like it would be a lot easier and fix the vast majority of use cases. #313 (comment) has lots of good suggestions which I don't think ever got a response.
Reacted by userxfce, Patrick Barrett and Peter Lyons KehlA read-only rustup installation is not something rustup expects to deal with. You could be careful to not run anything which could cause writes to the installation (e.g. nothing which might force a toolchain to exist, so no use of
rust-toolchainor use of, setting, removing, etc. overrides, no use ofrustup default) but so many things expect to be able to runrustupcommands to adjust the install that it'd be tough to enforce. At that point, an appropriate g+srx ought to be enough assuming by 'globally readable' you mean 'readable to a particular group' but ultimately this is not what rustup is for and we'd need to consider adjustments to the model to properly support this.@jyn514 It's not clear to me why a shared read-only install is 'your use case' - what is it about having several pi's that requires a shared installation: running rustup installed binaries on pi's doesn't seem to imply sharing those binaries between the pi's in any fashion. What is it about the regular installation path that doesn't work for your pi machines? Are they low on disk space? Is your NFS server short on disk space? Does rustup fail to unpack? (that should be fixed in the latest release now we auto-probe memory).
See #988 and #2417 for direct issues with sharing writable installs; if cargo's cache isn't shared then the cargo locking is probably avoidable from a scalability perspective, but you'll still be unable to use regular rustup workflows: vs-code integration / rls integrations / rustup update and frields, rustup default, rustup overrides, toolchain files, custom toolchains.
Note that we don't even guarantee arch-aware filepaths in ~/.rustup - sharing a rustup_home across architectures is not currently safe - settings.toml has a default-host that is arch specific, and sharing an install across heterogeneous machines over NFS would be broken by design.
@rbtcollins Sorry if I was unclear - I don't expect to share rustup across multiple machines, that's a much harder problem. I want to share rustup across multiple users.
What is it about the regular installation path that doesn't work for your pi machines?
The regular installation path is specific to each user. To expand a little more on this, we have a test suite that runs on several different machines at once, with the permissions of the user who started the test (we have automation internally to make sure each machine has each user). Currently, for it to work, each user has to have their own installation of rustup on each machine. This is not really tenable, it comes out to dozens (if not hundreds) of installations; we just haven't been running Rust tests on the Pis for now. I'm asking to be able to install rustup once on each machine and have it be accessible to each user.
See #988 and #2417 for direct issues with sharing writable installs; if cargo's cache isn't shared then the cargo locking is probably avoidable from a scalability perspective, but you'll still be unable to use regular rustup workflows: vs-code integration / rls integrations / rustup update and frields, rustup default, rustup overrides, toolchain files, custom toolchains.
Right, I'm only asking for read-only installs. See #313 (comment).
Reacted by Kyle J Strand and userxfceI wonder if Nix package manager could be of any help for a multi-user setup. Just a thought.
I want more than one UNIX user to have write access to shared multirust installation.
Is such mode supported/planned in the new rustup.rs? It should probably be like Git's
core.sharedRepositorysetting, causing Cargo and other tools to create group-writable files and directories.(I haven't actually experimented with it yet).