ASDF install method premise fundamentally unworkable #893

Closed
opened 2025-03-30 20:14:39 +00:00 by shadowjonathan · 11 comments
Contributor

With the recent (security-required) release of akkoma v3.15.2, the elixir version was bumped from 1.14.0 to 1.14.1

Currently, on both debian 12 and all ubuntu versions, elixir 1.14.0 is the latest available, and so everyone needs to install via ASDF

However, the debian install guide is vague on how exactly to install asdf, just referring to the ASDF website and "figure it out", while they offer three different install methods, all have their tradeoffs.

However, that's not entirely the point of the problem, which comes when you actually install the programs, but then **you cannot access their paths anymore when running sudo -Hu akkoma commands.

This is because sudo -Hu does not read ~/.bash_profile and friends for its paths, it reads secure_paths, which overrides any paths set via rc files or profile files, which means that elixir and mix are inaccessible through those commands, unless they're installed in system directories, which ASDF does not.

Basically, this line of guidance will not work for people who try to install it this way.


Do y'all even end-to-end test your own guides from time to time, with fresh VMs?

With the recent (security-required) release of akkoma `v3.15.2`, the elixir version was bumped from 1.14.0 to 1.14.1 Currently, on both debian 12 and all ubuntu versions, elixir 1.14.0 is the latest available, and so everyone needs to install via ASDF However, the debian install guide is vague on how exactly to install asdf, just referring to the ASDF website and "figure it out", while they offer three different install methods, all have their tradeoffs. However, that's not entirely the point of the problem, which comes when you actually install the programs, but then **you cannot access their paths anymore when running `sudo -Hu akkoma` commands. This is because `sudo -Hu` does not read `~/.bash_profile` and friends for its paths, it reads [`secure_paths`](https://www.sudo.ws/posts/2024/09/why-sudo-1.9.16-enables-secure_path-by-default/), which **overrides** any paths set via `rc` files or `profile` files, which means that `elixir` and `mix` are inaccessible through those commands, unless they're installed in system directories, which ASDF does not. Basically, this line of guidance *will not work* for people who try to install it this way. --- Do y'all even end-to-end test your own guides from time to time, with fresh VMs?

everything is provided for free, on volunteer time and not insignificant financial burden, being sarcy like in that last line is not very appreciated

as the saying goes, patches welcome

everything is provided for free, on volunteer time and not insignificant financial burden, being sarcy like in that last line is not very appreciated as the saying goes, patches welcome

i just made this account to point out this is the umpteenth time akkoma is straight up a pain in the ass to deploy and yet another time you dismiss any concern about the software you decided to lead

i don't think asking for someone to test a new update before pushing it to main branch is really "sarcy" and rude, if you feel that working on akkoma is burdening you this much then why not just drop support?

and i'm not saying it out of malice but it's really upsetting that whenever someone makes an issue regarding akkoma being straight up uninstallable on a fairly popular linux distro used for hosting things, you just get defensive and fold up yelling "it's free, why are you complaining, i don't get paid for it"

i just made this account to point out this is the umpteenth time akkoma is straight up a pain in the ass to deploy and yet another time you dismiss any concern about the software you decided to lead i don't think asking for someone to test a new update before pushing it to main branch is really "sarcy" and rude, if you feel that working on akkoma is burdening you this much then why not just drop support? and i'm not saying it out of malice but it's really upsetting that whenever someone makes an issue regarding akkoma being straight up uninstallable on a fairly popular linux distro used for hosting things, you just get defensive and fold up yelling "it's free, why are you complaining, i don't get paid for it"

I personally run it on Ubuntu with asdf without issue, so it does work just fine :)

uninstallable is verifiably incorrect, this much I know for sure

I personally run it on Ubuntu with asdf without issue, so it does work just fine :) uninstallable is verifiably incorrect, this much I know for sure
Author
Contributor

@floatingghost can you then run sudo -Hu akkoma bash -c "echo \$PATH" for me, please?

and also which ubuntu version?

@floatingghost can you then run `sudo -Hu akkoma bash -c "echo \$PATH"` for me, please? and also which ubuntu version?

do you even test your code on a fresh VM before deploying it on main or are you just dense

of course it will be easier if you already have an akkoma installation, the problem comes when someone wants to set up a new instance (and they can't because the elixir version provided by debian is not new enough and ASDF shits the bed)

maybe if you actually cared and stopped dismissing any issue of similar nature as "erm it works on my machine, plus i'm doing this in my free time" people wouldn't have to resort to "rude sarcy lines" just to get feedback

do you even test your code on a fresh VM before deploying it on main or are you just dense of course it will be easier if you already have an akkoma installation, the problem comes when someone wants to set up a new instance (and they can't because the elixir version provided by debian is not new enough and ASDF shits the bed) maybe if you actually cared and stopped dismissing any issue of similar nature as "erm it works on my machine, plus i'm doing this in my free time" people wouldn't have to resort to "rude sarcy lines" just to get feedback

(ssh) > $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 22.04.5 LTS
Release: 22.04

also i can't run that exact PATH command because i still use a custom user from back before i forked, and as such my deployment location is different to the standard (i still run under weird database names and everything) - like i run in /var/www and have some weird envs

(ssh) > $ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.5 LTS Release: 22.04 also i can't run that exact PATH command because i still use a custom user from back before i forked, and as such my deployment location is different to the standard (i still run under weird database names and everything) - like i run in /var/www and have some weird envs

do you even test your code on a fresh VM

nope

🤷i'm not here as a mainline or anything, i provide the changes i made as-is mostly as a service for my friends and that's the group i target - i try to make a best-effort to help out elsewhere when i have the time but it will forever remain a best-effort

>do you even test your code on a fresh VM nope 🤷i'm not here as a mainline or anything, i provide the changes i made as-is mostly as a service for my friends and that's the group i target - i try to make a best-effort to help out elsewhere when i have the time but it will forever remain a best-effort
Author
Contributor

@floatingghost please try to set up akkoma in a fresh VM, or please mark the instructions as outdated, since currently it keeps up the impression that they work and are viable

we've run against those exact same instructions multiple times because they either were outdated or said something incorrect, and ive poked about it here a few times, but if you're using an install that is not really in the same environment as the instructions you're feeding your users, then its very likely they get very divergent, so dogfeeding may help here

asdf is not workable with the akkoma user setup as described in the debian handbook, because the sudo -Hu command bypasses ~/.profile and other such files, which means that ASDF_DATA_DIR can't be set, and the only option is to add a custom file in /etc/sudoers.d/, hardcoding the /var/lib/akkoma/.asdf/shims path to secure_path, the same path chain that all commands ran through sudo will source from.

@floatingghost please try to set up akkoma in a fresh VM, or please mark the instructions as outdated, since currently it keeps up the impression that they work and are viable we've run against those exact same instructions multiple times because they either were outdated or said something incorrect, and ive poked about it here a few times, but if you're using an install that is not really in the same environment as the instructions you're feeding your users, then its very likely they get very divergent, so dogfeeding may help here asdf is not workable with the akkoma user setup as described in the debian handbook, because the `sudo -Hu` command bypasses `~/.profile` and other such files, which means that `ASDF_DATA_DIR` can't be set, and the *only option* is to add a custom file in `/etc/sudoers.d/`, **hardcoding the `/var/lib/akkoma/.asdf/shims` path to `secure_path`, the same path chain that all commands ran through `sudo` will source from**.

for the record OTP tends to be more reliable if your distribution supports it, especially since debian love to be years behind everyone and makes them in particular a pain to keep relevent without expontially increasing the amount of overheads on release

you can absolutely just switch to the custom user and install asdf for them individually though that'd work just fine, no need to mess with sudoers

for the record OTP tends to be more reliable if your distribution supports it, especially since debian love to be years behind everyone and makes them in particular a pain to keep relevent without expontially increasing the amount of overheads on release you can absolutely just switch to the custom user and install asdf for them individually though that'd work just fine, no need to mess with sudoers
Author
Contributor

I've found a way to make the sudoers addition more secure, and still make it work;

echo 'Defaults>akkoma secure_path="/sbin:/bin:/usr/sbin:/usr/bin:/var/lib/akkoma/.asdf/shims"' > /etc/sudoers.d/custom_path

I've found a way to make the sudoers addition more secure, and still make it work; `echo 'Defaults>akkoma secure_path="/sbin:/bin:/usr/sbin:/usr/bin:/var/lib/akkoma/.asdf/shims"' > /etc/sudoers.d/custom_path`

My workaround for this was to uninstall the repo version of elixir/erlang, log in as the akkoma user with sudo -su akkoma or whatever, install asdf to the home directory of the akkoma user (/var/lib/akkoma) use asdf to install the newer version of elixir and erlang under the akkoma user, and now just instead of doing sudo -Hu akkoma I just switch to the akkoma user directly to do mix commands.
You will have to change the systemd service file for akkoma too so that it uses the asdf versions.
I wrote a txt file as I figured stuff out when updating labyrinth.zone recently on debian 12, and you can find those notes here:
https://media.labyrinth.zone/media/fe0823a1148188ad1c59fd21dd74bb2b0edc803e6844baf6469e4d1077eedb6a.txt
I wrote these to update to 3.15.1, which I updated to about 10 minutes before 3.15.2 released and changed the documentation slightly, but this should still work I think.

My workaround for this was to uninstall the repo version of elixir/erlang, log in as the akkoma user with sudo -su akkoma or whatever, install asdf to the home directory of the akkoma user (/var/lib/akkoma) use asdf to install the newer version of elixir and erlang under the akkoma user, and now just instead of doing sudo -Hu akkoma I just switch to the akkoma user directly to do mix commands. You will have to change the systemd service file for akkoma too so that it uses the asdf versions. I wrote a txt file as I figured stuff out when updating labyrinth.zone recently on debian 12, and you can find those notes here: https://media.labyrinth.zone/media/fe0823a1148188ad1c59fd21dd74bb2b0edc803e6844baf6469e4d1077eedb6a.txt I wrote these to update to 3.15.1, which I updated to about 10 minutes before 3.15.2 released and changed the documentation slightly, but this should still work I think.
Sign in to join this conversation.
No milestone
No project
No assignees
4 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: AkkomaGang/akkoma#893
No description provided.