Silverblue - Toolbox module?
chromakey-io opened this issue · comments
Hey,
The default bash has a nice little * that shows up when you are inside their little containerization system called "toolbox".
I'm a new user to this little tool, but am LOVING the minimalism and simplicity .. compared to some of the more "powerful" tools like this out there.
Aany-who. The one module that I would LOVE to see for my current environment is one for Silverblue's "toolbox". The default shell shows just an asterisk, but with "silver" it doesn't show anything when you are operating inside a toolbox container..
The asterisk is "nice" I guess, but what would be really nice is a "silver" module that actually tells you the name of the container you are inside!
What do you guys think? Is this do-able? I might give it a shot, rust seems neat ... but I've never used it before so..
Thanks Guys!
I'm having a bit of trouble setting up toolbox on my machine, but I assume that toolbox will set an environment variable when you're in a container.
Could you run env | sort > env.1 outside of a container, then run env | sort > env.2 while in the container, and reply with the output of diff env.1 env.2? Thank you.
1,14d0
< *)
< ;;
< ;;
< ;;
< ;;
< }
< }
< }
< }
< BASH_FUNC_module%%=() { _module_raw "$@" 2>&1
< BASH_FUNC__module_raw%%=() { unset _mlshdbg;
< BASH_FUNC_scl%%=() { if [ "$1" = "load" -o "$1" = "unload" ]; then
< BASH_FUNC_switchml%%=() { typeset swfound=1;
< case "$-" in
15a2
> COLUMNS=80
19,51c6,7
< do
< done;
< echo "Cannot switch to Modules $swname version, command not found";
< echo "Switching to Modules $swname version";
< else
< else
< else
< else
< else
< esac;
< eval `eval ${_mlre}/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash '"$@"'`;
< eval "module $@";
< eval `/usr/bin/tclsh /usr/share/Modules/libexec/modulecmd.tcl bash "$@"`;
< export MODULES_USE_COMPAT_VERSION;
< fi
< fi
< fi;
< fi;
< fi;
< fi;
< fi;
< fi;
< fi;
< fi;
< fi;
< fi;
< for _mlv in ${MODULES_RUN_QUARANTINE:-};
< GDM_LANG=en_US.UTF-8
< GDMSESSION=gnome-xorg
< GJS_DEBUG_OUTPUT=stderr
< GJS_DEBUG_TOPICS=JS ERROR;JS LOG
< GNOME_TERMINAL_SCREEN=/org/gnome/Terminal/screen/09d8df42_9f58_4838_b77f_854f86bde92e
< GNOME_TERMINAL_SERVICE=:1.152
---
> DISTTAG=f31container
> FGC=f31
55,71c11,12
< HOSTNAME=rugged
< if [ "${_mlv}" = "${_mlv##*[!A-Za-z0-9_]}" -a "${_mlv}" = "${_mlv#[0-9]}" ]; then
< if [ "${MODULES_SILENT_SHELL_DEBUG:-0}" = '1' ]; then
< if [ "${MODULES_USE_COMPAT_VERSION:-0}" = '1' ]; then
< if [ $swfound -eq 0 ]; then
< if [ -e /usr/share/Modules/libexec/modulecmd-compat ]; then
< if [ -e /usr/share/Modules/libexec/modulecmd.tcl ]; then
< if [ -n "${IFS+x}" ]; then
< if [ -n "${_mlIFS+x}" ]; then
< if [ -n "${_mlre:-}" ]; then
< if [ -n "${_mlshdbg:-}" ]; then
< if [ -n "`eval 'echo ${'$_mlv'+x}'`" ]; then
< IFS=' ';
< IFS=$_mlIFS;
< INVOCATION_ID=f0f2e35f79e54c13a71d04639f265c4d
< JOURNAL_STREAM=9:30032
< LANG=en_US.UTF-8
---
> HOSTNAME=toolbox
> LANG=C.UTF-8
73c14
< LOADEDMODULES=
---
> LINES=24
77,94c18,19
< MANAGERPID=1525
< MANPATH=:
< _mlIFS=$IFS;
< _mlre="${_mlre:-}${_mlv}='`eval 'echo ${'$_mlrv':-}'`' ";
< _mlre="${_mlre:-}${_mlv}_modquar='`eval 'echo ${'$_mlv'}'`' ";
< _mlrv="MODULES_RUNENV_${_mlv}";
< _mlshdbg=''
< _mlshdbg='v'
< _mlshdbg='vx'
< _mlshdbg='x'
< _mlstatus=$?;
< MODULEPATH=/etc/scl/modulefiles:/etc/scl/modulefiles:/usr/share/Modules/modulefiles:/etc/modulefiles:/usr/share/modulefiles
< MODULEPATH_modshare=/usr/share/modulefiles:1:/usr/share/Modules/modulefiles:1:/etc/modulefiles:1
< MODULES_CMD=/usr/share/Modules/libexec/modulecmd.tcl
< MODULESHOME=/usr/share/Modules
< MODULES_RUN_QUARANTINE=LD_LIBRARY_PATH
< MODULES_USE_COMPAT_VERSION=1;
< PATH=/var/home/noah/.local/bin:/var/home/noah/bin:/usr/share/Modules/bin:/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin
---
> NAME=Fedora
> PATH=/var/home/noah/.local/bin:/var/home/noah/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
96,103d20
< QT_IM_MODULE=ibus
< return $_mlstatus
< return 1;
< SESSION_MANAGER=local/unix:@/tmp/.ICE-unix/1701,unix/unix:/tmp/.ICE-unix/1701
< set -$_mlshdbg;
< set +v;
< set +vx;
< set +x;
106,108c23
< SILVER_SHELL=bash
< source /usr/share/Modules/init/bash;
< SSH_AGENT_PID=1609
---
> SILVER_SHELL=/bin/bash
111,120c26
< typeset swfound=0;
< typeset swfound=0;
< typeset swname='compatibility';
< typeset swname='main';
< unset IFS;
< unset _mlre _mlIFS;
< unset _mlre _mlv _mlrv _mlIFS;
< unset _mlshdbg;
< unset MODULES_USE_COMPAT_VERSION;
< USERNAME=noah
---
> TOOLBOX_PATH=/usr/bin/toolbox
122,124c28
< _=/usr/bin/env
< /usr/bin/scl "$@";
< *v*)
---
> VERSION=31 (Container Image)
126,129d29
< *v*x*)
< WINDOWPATH=2
< *x*)
< XAUTHORITY=/run/user/1000/gdm/Xauthority
134d33
< XDG_SESSION_CLASS=user
137c36,37
< XMODIFIERS=@im=ibus
---
> _=/usr/bin/env
> container=oci
The useful bits... it adds a container variable and changes the hostname to "toolbox". It's a little disappointing, but it doesn't seem to include the name of the toolbox anywhere :(
FYI, this one is named "default" if I somehow missed it.
Does toolbox have a command that outputs the name?
I'm trying to figure that out at this very moment :)
I couldn't find a command, at least not with toolbox ... and podman only works outside the containers.
The good news, is it does look like there are two files that store container information that is accessible from inside the container. Both container the container name :)
.local/share/containers/storage/overlay-layers/layers.json
http://dpaste.com/0P4CJHV#wrap
.local/share/containers/storage/overlay-containers/containers.json
http://dpaste.com/06HZC4Y#wrap
Ahhhh geeze .... that just lists every container. Maybe it has an "active" mark somewhere but I don't see it.
You may be able to find a file that contains the name of the current container if you name a container something random that wouldn't occur in any other file, cd /, grep -r "<container name>" 2> /dev/null.
Yeah actually what I did ... then I grep'd and ack'd everything. Unfortunately ... I think I"m down to asking the folks over at the fedora forums and if that doesn't work I'll file a bug at podman and toolbox.
All of the other container systems seem to drop the container ID into hostname, but for toolbox they strip it off and leave it as the generic "toolbox" which isn't helpful in the slightest :(
Thanks so much for the help .. and interest :) I really appreciate it.
Well for the time being I can add a toolbox module that simply displays an asterisk or toolbox icon until we figure a solution to get the container name.
And I'm really happy to hear that you enjoy using this prompt. If you want help with anything else feel free to open an issue.
Yeah, I mean even just a simple asterisk or icon would be amazeballs ... having nothing it's really confusing whether you are in the host or in a container.
... I'll update this ticket if I make any headway on determining the name of the container. It seems like a major oversight for them to have changed the behavior from Docker (which leaves it in the hostname and as an env-var) .... so hopefully they'll get back to me on that :)
For sys-admin stuff having the container name inaccessible seems like it would be a deal-breaker for the whole platform.
Again... thanks so much :)
I just talked to the fedora guys and they gave me this. You can't run podman from within containers, but toolbox has low-level access as well... and can give you the container name with this command:
flatpak-spawn --host podman ps
the response looks like this:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
ac18ddde2157 registry.fedoraproject.org/f31/fedora-toolbox:31 toolbox --verbose... 2 minutes ago Up 2 minutes ago default
scratch that ..... this is just lists all active toolbox containers and gives no indication as to which one you are currently in.
Would it be helpful to show the container name if there's only one container running?
Yeah that would be amazing, just make sure it doesn't end up showing that once you startup another container. You can log into containers multiple times, so it may be a little confusing having one labeled and the others not ... I don't know. The output also includes container up-time if you look .... not sure if that would be helpful in sorting this out ... I can't think of a way but maybe you can.
I'll get back to trying to figure this out properly .... but at the moment I'm doing a little distro-hopping trying to sort out some issues with intel powersave and my AMD+Intel GPU setup on my laptop.
So I'm actually on Intel's Clear Linux right now. It's nice enough, but they make the package manager wayyyy too beginner friendly (you can't install individual applications, just "bundles" that more often than not include tons of stuff you don't want. I don't have a printer, but there's simply no way for me to not install the hardware-printing bundle!) .... and they made the container system wayyyy too non-beginner friendly (and it's docker based, which is well I'll hold my wrath). Compared to "toolbox" it's pure nightmare fuel. It's got some powerful features, and is faster than fast on my intel hardware. It even allows you to build and install rpm's from any distro (with some serious effort) .... but I don't think it will be my daily driver if I can sort out these power-saving issues .... yearning to get back to silverblue but the powersave issues with the intel+amd gfx cards made things completely unstable (crashing every 5 minutes if I didn't disable all intel power-save and disable the AMD gpu, and set the performance setting to the lowest possible one).
Wish me luck, and thanks so much for the effort and interest again.
FYI ... I think the key to this is that flatpak-spawn allows you to run any podman command from within a container ... well at least I hope that's the key because I'm starting to run short on ideas :)
Does the container inherit the host environment variables? If so, it should be possible to wrap the toolbox command to set a variable before entering the container.