[Error] Not able to change hostname in init_hooks

[briandipalma]

Having a fake hostname causes weird failures when running Java/Hibernate code. I guess Hibernate tries to connect to a DB file using the hostname. The errors that are raised are ClassNotFound ones so it was painful to debug what was going on. Setting the hostname to my local machine one, the correct one, fixes the issue. I've been trying to add it to my init_hooks with no success so far.

init-hooks=hostname "$(uname -n)";

Causes this

brian@brian-pop-os-pc-specialist:~/dev/iac/images$ distrobox assemble create 
/usr/bin/distrobox-assemble: 4: /tmp/tmp.tzoNM46AWF: init-hooks=hostname brian-pop-os-pc-specialist;: not found

While

"$(uname -n)" > /etc/hostname

Causes

brian@brian-pop-os-pc-specialist:~/dev/iac/images$ distrobox assemble create 
/usr/bin/distrobox-assemble: 4: /tmp/tmp.7ILlQSqxEf: cannot create /etc/hostname: Permission denied

While

sudo "$(uname -n)" > /etc/hostname

Causes

Setting up groups...                    	 [ OK ]
Setting up users...                     	 [ OK ]
Setting up skel...                      	 [ OK ]
Executing init hooks...                 	 Error: An error occurred

It would be nice if we could create containers that used their host's hostname as the way I imagine most people use distrobox containers is as local host like environments. I doubt people are deploying them as server host environments.

Something like

change_hostname=false

in a distrobox.ini file would be fantastic.

I see the code in generate_command, would a PR be accepted?

[michaelhaaf]

I think this is partially a typo/error in the init-hook provided in the documentation: https://github.com/89luca89/distrobox/blob/main/docs/useful_tips.md#enable-ssh-x-forwarding-when-ssh-ing-in-a-distrobox

I think command substitution here is misplaced, uname -n already prints to stdout and can be redirected directly. Or you can use echo on the provided command. I.e.

uname -n > /etc/hostname
echo "$(uname -n)" > /etc/hostname

Tested on Fedora 39 below:

# Also tested the 'echo "$(uname -n)" > /etc/hostname' with the same result

user@hostname $ distrobox create --image ghcr.io/username/sample-image:latest -n box-name \ 
    --init-hooks 'uname -n > /etc/hostname' && distrobox enter box-name

...

Setting up groups...                    	 [ OK ]
Setting up users...                     	 [ OK ]
Setting up skel...                      	 [ OK ]
Executing init hooks...                 	 [ OK ]

Container Setup Complete!

[email protected] $ cat /etc/hostname 
box-name.hostname

[email protected] $ hostname
box-name.hostname  

It works! Sort of? For reasons that may make sense but are beyond me at the moment, the resulting hostname is a FQDN (the container name as a subdomain of the hostname).

What I mean is, I would rather expect the outcome of uname -n > /etc/hostname to be:

[email protected] $ cat /etc/hostname 
hostname

[michaelhaaf]

In the time since making that comment I've come to thinking/realizing a few things:

(1) It's probably fine that the result of this init-hook method creates a new FQDN for the intents and purposes of both resolving to the host name and being unique/individually identifiable on a local network (i.e. there's nothing wrong with boxname.hostname).

It turns out there's already been quite a lot of discussion about this in this repo and in toolbox which I only skimmed, but the important parts seem to work (e.g. ssh -x forwarding) in this scheme.

(2) The documentation has a typo, which is a separate issue that I also had run into when trying this out (which is why I knew the fix). I've made a pull request to address this here.

(3) OP floated the idea of having a --hostname parameter rather thatn using init-hook which seems like a reasonable feature, e.g. docker-compose has this. There may already be a feature request tracking this if you look.

[briandipalma]

1. boxname.hostname is the hostname that is set in the container by default. I saw the other issues that talked about hostname setting, that's where I got some of my attempted solutions.

2. The --hostname flag is what distrobox uses to tell podman/docker what hostname to set in the container (boxname.hostname by default).

In fact I ended up solving the issue using that flag. I replaced the distrobox.ini file I was using during the creating of my container with a script that overrides the --hostname flag distrobox passes into the container runner.

distrobox rm env --force;

distrobox create --image docker.io/briandipalma/env:latest \
	--name env \
	--pull \
	--additional-flags "--hostname ${HOSTNAME}" \
	--pre-init-hooks "SHELL=/usr/bin/fish";

distrobox enter env;

I'll close the issue as I've a solution that I'm happy with.

[redbeardymcgee]

In fact I ended up solving the issue using that flag. I replaced the distrobox.ini file I was using during the creating of my container with a script that overrides the --hostname flag distrobox passes into the container runner.

I have additional_flags="--hostname <sub.domain>"

I ended up in this issue because I was looking for a way to use command substitution in init_hooks. To bootstrap my devbox, I use sh -c "$(curl -fsLS get.chezmoi.io)" -- -b $HOME/.local/bin. This fails with the error tmpdir: parameter not set.

This is probably the culprit, sort of. I'm not sure how tmpdir is unset because the variable does get set.

I thought perhaps it's because mktemp might be missing. Try adding additional_packages=coreutils or init_hooks="sudo dnf install -y coreutils" (or pre_init_hooks). Still breaks.

Take the command substitution out.

init_hooks="curl -sSLf get.chezmoi.io -o chezmoi-installer;"
init_hooks="chmod +x ./chezmoi-installer;"
init_hooks='./chezmoi-installer -b "/home/redbeardymcgee/devbox/.local/bin" init redbeardymcgee --ssh --apply --promptDefaults --force;'

Creating './chezmoi-installer -b " ${init_hooks}' using image registry.fedoraproject.org/fedora-toolbox:latest /home/josh/.local/bin/distrobox-create: 1: eval: init_hooks: parameter not set

Huh?