# Should print a rustup version, followed by a Rust toolchain version
rustup --version

rustup toolchain install nightly-2025-04-25

If you have never installed a Rust toolchain via rustup before, then you can directly install the appropriate nightly compiler release inside of your home directory using the following command:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs  \
   | sh -s -- -y --no-modify-path  \
&& . "$HOME/.cargo/env"  \
&& rustup toolchain install nightly-2025-04-25

If you read the logs carefully, you will notice that this command sets up two different toolchains:

• One based on current stable release of the Rust compiler, which will be used by default when no other constraints dictate otherwise
• One based on specific nightly compiler release that we need for this course

If this feels excessive, you may want to install only the nightly toolchain that we need, which can be done by adding a --default-toolchain=none option to the sh command above, before or after the -y option.

But bear in mind that this means that your user account will end up using an old-ish nightly Rust compiler release by default for all future Rust compilation work. Which is not desirable as nightly Rust releases are special-purpose tools that should only be used in specific circumstances. It is normally best to use an up-to-date stable release of the compiler for most of your work.

Unfortunately, the rustup tool is designed for installing Rust toolchains within an individual user’s home directory, and makes various assumptions that are only valid in this context. This means that a robust system-wide deployment can only be achieved through some inelegant workarounds.

First of all, you will want to create a system-wide installation prefix and set up some environment variables to tell rustup and other Rust tools that they should be working inside of this prefix and not inside of your home directory.

# Set up a custom prefix directory
#
# In the following, it is assumed that you are running all commands in a shell
# that has permission to write into this directory. For /opt/rustup, this would
# likely be a root shell.
PREFIX=/opt/rustup
mkdir "${PREFIX}"

# Tell rustup and other utilities that they should use this prefix
export RUSTUP_HOME="${PREFIX}"
export CARGO_HOME="${PREFIX}"

Once this is done, you can install rustup and Rust toolchains in this directory using a slightly modified version of the procedure described in the “Need to install rustup” tab:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh -s -- -y  \
&& . "${PREFIX}/env"  \
&& rustup toolchain install nightly-2025-04-25

---

So far so good. But then comes the catch: if what you are after is a true system-wide deployment, you should not to tell your users to source the ${PREFIX}/env script that was used by the above command. This can only end in suffering:

• If your users do not set up their RUSTUP_HOME and CARGO_HOME environment variables as you did above, then rustup will not see the installed toolchains in ${PREFIX}, and will proceed to do a fresh install of the required toolchain(s) in their home directory, which…
  1. Defeats the purpose of a performing a system-wide deployment.
  2. May lead your users to experience issues down the line as the first installed toolchain will become their default Rust toolchain. And they should not be using this course’s old pinned nightly compiler version as their default toolchain.
• On the other hand, if your users do set up their RUSTUP_HOME and CARGO_HOME environment variables as you did above, then they will face unexpected filesystem access permission errors as soon at they will voluntarily or involuntarily call rustup in a fashion that leads it to try writing into ${PREFIX}.
  • Pay attention to the “involuntary” part. rustup is designed to wrap Rust’s standard build system and make it automatically download missing toolchains when building a program. While convenient under normal rustup usage circumstances, this feature can make the file permission errors from this incorrect usage scenario a lot more confusing.

Instead of exposing your users to a weird system-wide installation of rustup like this, you should treat rustup as a pure toolchain management program, only meant for your own consumption as a system administrator, and refrain from exposing it to non-root system users.

To this end, users should be interacting with the rustup-installed Rust toolchains directly, without going through the usual rustup-provided wrappers to cargo, rustc and friends.

---

We can achieve this is by noticing the existence of a toolchains directory within the rustup installation prefix, which is structured in the following manner:

$ tree -L 3 "${PREFIX}/toolchains"
/opt/rustup/toolchains/
|-- nightly-2025-04-25-x86_64-unknown-linux-gnu
|   |-- bin
|   |   |-- cargo
|   |   |-- cargo-clippy
|   |   |-- cargo-fmt
|   |   |-- clippy-driver
|   |   |-- rust-gdb
|   |   |-- rust-gdbgui
|   |   |-- rust-lldb
|   |   |-- rustc
|   |   |-- rustdoc
|   |   `-- rustfmt
|   |-- etc
|   |   `-- bash_completion.d
|   |-- lib
|   |   |-- libLLVM-20-rust-1.88.0-nightly.so
|   |   |-- libLLVM.so.20.1-rust-1.88.0-nightly
|   |   |-- librustc_driver-725640084d7a171d.so
|   |   `-- rustlib
|   |-- libexec
|   |   `-- rust-analyzer-proc-macro-srv
|   `-- share
|       |-- doc
|       |-- man
|       `-- zsh
`-- stable-x86_64-unknown-linux-gnu
    [... same as above, but with different lib version numbers ...]

As you can see, each rustup-managed Rust toolchain gets installed into its own tidy dedicated prefix. And you can exploit this by writing environment modules or setup scripts that bring the appropriate parts of these prefixes into scope.

In our example, the minimal environment setup script that brings in the nightly-2025-04-25 Rust toolchain that we need for this course would be:

# Do not use ${PREFIX} variable expansions here, as they only work if the user
# has this variable defined
export PATH="/opt/rustup/toolchains/nightly-2025-04-25-x86_64-unknown-linux-gnu/bin:${PATH}"
# Notice we do NOT need to change LD_LIBRARY_PATH and friends, thanks to RPATHs.

Unfortunately, it takes more work to get modern Unix comfort like shell autocompletion and man pages working. But this is not an essential requirement for basic usage, and can be skipped if you do not have the time for this.

cargo install --git https://github.com/HadrienG2/grayscott.git data-to-pics

After bringing a Rust toolchain into your PATH, you can build and install this program into a global prefix of your choice using some variation of the following procedure:

# Adjust this target prefix to your liking
PREFIX=/usr/local/

cargo install --git https://github.com/HadrienG2/grayscott.git  \
              --root=/tmp  \
              data-to-pics  \
&& sudo mv /tmp/bin/data-to-pics "${PREFIX}/bin"

While you could directly run cargo install as root and directly point its --root argument to the prefix of your choice, this is suboptimal from a security perspective for the same reason that running make as root is frowned upon in the C world: the Cargo build scripts of the target application and its dependencies can execute arbitrary code from the Internet, and it is best not to provide root privileges to this arbitrary code when it does not need them to do its work.

If your chosen prefix is not in the default user PATH, you will then proceed to make the binary selectively available to interested users using your favorite PATH environment setup method: environment modules, bash scripts, you know the drill!