Setting hostname while spawning pasta

Setting hostname while spawning pasta

[Danish Prakash]

Hello

I was having a discussion with a colleague of mine on how `pasta` when invoked
independently drops you in a new user and network namespace and how that causes
some folks to not realize what has happened especially because there's no cue
as to what transpired. This is not uncommon though, because a lot of
times, folks having
issues with pasta while running it with podman, tend to invoke pasta
directly to debug.

I interacted with Stefano regarding this and he told me that pasta
already detaches
the UTS namespace and so in order to address this issue, I propose
that we set the hostname
as part of `pasta_spawn_cmd()`.Doing this would provide users with a
clear visual indication that
they are in a new user namespace (among other ns but that won't be
indicative here) and avoid
issues similar to the aforementioned.

I'm looking to gather more opinions on how this change, if
implemented, would affect the
functionality. Looking forward to the discussion.

Thank you

danishpraka.sh
:wq

Re: Setting hostname while spawning pasta

[Stefano Brivio]

Hi Danish,

On Thu, 9 May 2024 12:30:42 +0530
Danish Prakash <danish.prakash@suse.com> wrote:

> Hello
> 
> I was having a discussion with a colleague of mine on how `pasta` when invoked
> independently drops you in a new user and network namespace and how that causes
> some folks to not realize what has happened especially because there's no cue
> as to what transpired. This is not uncommon though, because a lot of
> times, folks having
> issues with pasta while running it with podman, tend to invoke pasta
> directly to debug.
> 
> I interacted with Stefano regarding this and he told me that pasta
> already detaches
> the UTS namespace and so in order to address this issue, I propose
> that we set the hostname
> as part of `pasta_spawn_cmd()`.Doing this would provide users with a
> clear visual indication that
> they are in a new user namespace (among other ns but that won't be
> indicative here) and avoid
> issues similar to the aforementioned.
> 
> I'm looking to gather more opinions on how this change, if
> implemented, would affect the
> functionality. Looking forward to the discussion.

...I just realised one thing, probably solvable, while trying out some
stuff with pasta on two different machines: if I didn't have the
original hostname in the prompt, I would have had some issues telling
them apart.

But we could still retain the existing hostname and prefix with
something like 'pasta-on-' (sure, we would need to truncate at 63
characters, but it shouldn't be a common case). What do you think?

That would also help when you're running pasta-in-pasta-in-pasta-in...
(or at least when I am running it ;)).

Because usually I notice that I'm in a pasta-spawned terminal by
looking at the prompt: I'm "root", but colours didn't change.

What I can't tell from the prompt, though, is at what "level" I'm at
(at least pasta-in-pasta is something I try very commonly to reproduce
pasta's behaviour with particular network setups). Having
root@pasta-on-pasta-on-machine would be a nice plus.

-- 
Stefano

Re: Setting hostname while spawning pasta

[Stefano Brivio]

On Mon, 13 May 2024 13:45:51 +0530
Danish Prakash <danish.prakash@suse.com> wrote:

> > But we could still retain the existing hostname and prefix with
> > something like 'pasta-on-' (sure, we would need to truncate at 63
> > characters, but it shouldn't be a common case). What do you think?  
> 
> That sounds like a good idea. I didn't realize you'd be running
> pasta-in-pasta.. but that's reasonable. Though this will be helpful,
> I'm not entirely sure if this would override the prompts that many
> have set. At least my rudimentary shell prompt doesn't recognize the
> pasta user namespace and continues to show the same old prompt. I hope
> I'm the only one having this issue.

I currently have these behaviours with default prompts:

- Alpine:
  host:~$ pasta
  host:~# 

- Debian:

  user@host:~$ pasta
  root@host:~# 

- Fedora:

  [user@host ~]$ pasta
  [root@host ~]# 

- openSUSE:

  user@host:~> pasta
  host:~ # 

so I generally have a hint of something going on, but in any case,
changing the hostname is helpful for unfamiliar users or even just for
the pasta-in-pasta case I mentioned.

> > What I can't tell from the prompt, though, is at what "level" I'm at
> > (at least pasta-in-pasta is something I try very commonly to reproduce
> > pasta's behaviour with particular network setups). Having
> > root@pasta-on-pasta-on-machine would be a nice plus.  
> 
> But in general, this idea sounds good, I'd like to take a shot at
> this, and I can send over the patch for you to test once I'm done.
> What do you think?

Sure, thanks, looking forward to it!

-- 
Stefano

Re: Setting hostname while spawning pasta

[Danish Prakash]

> At least my rudimentary shell prompt doesn't recognize the
> pasta user namespace and continues to show the same old prompt. I hope
> I'm the only one having this issue.

Sorry for the confusion, it was just me indeed. I was missing a
particular shell sequence expansion from my prompt; fixed now[1].

[1] - https://github.com/danishprakash/dotfiles/commit/3a226744dba3189bf94f40a857c8c5fa7e848e8f

On Mon, May 13, 2024 at 4:52 PM Stefano Brivio <sbrivio@redhat.com> wrote:
>
> On Mon, 13 May 2024 13:45:51 +0530
> Danish Prakash <danish.prakash@suse.com> wrote:
>
> > > But we could still retain the existing hostname and prefix with
> > > something like 'pasta-on-' (sure, we would need to truncate at 63
> > > characters, but it shouldn't be a common case). What do you think?
> >
> > That sounds like a good idea. I didn't realize you'd be running
> > pasta-in-pasta.. but that's reasonable. Though this will be helpful,
> > I'm not entirely sure if this would override the prompts that many
> > have set. At least my rudimentary shell prompt doesn't recognize the
> > pasta user namespace and continues to show the same old prompt. I hope
> > I'm the only one having this issue.
>
> I currently have these behaviours with default prompts:
>
> - Alpine:
>   host:~$ pasta
>   host:~#
>
> - Debian:
>
>   user@host:~$ pasta
>   root@host:~#
>
> - Fedora:
>
>   [user@host ~]$ pasta
>   [root@host ~]#
>
> - openSUSE:
>
>   user@host:~> pasta
>   host:~ #
>
> so I generally have a hint of something going on, but in any case,
> changing the hostname is helpful for unfamiliar users or even just for
> the pasta-in-pasta case I mentioned.
>
> > > What I can't tell from the prompt, though, is at what "level" I'm at
> > > (at least pasta-in-pasta is something I try very commonly to reproduce
> > > pasta's behaviour with particular network setups). Having
> > > root@pasta-on-pasta-on-machine would be a nice plus.
> >
> > But in general, this idea sounds good, I'd like to take a shot at
> > this, and I can send over the patch for you to test once I'm done.
> > What do you think?
>
> Sure, thanks, looking forward to it!
>
> --
> Stefano
>

Re: Setting hostname while spawning pasta

[Paul Holzinger]

Hi,

On 09/05/2024 09:00, Danish Prakash wrote:
> Hello
>
> I was having a discussion with a colleague of mine on how `pasta` when invoked
> independently drops you in a new user and network namespace and how that causes
> some folks to not realize what has happened especially because there's no cue
> as to what transpired. This is not uncommon though, because a lot of
> times, folks having
> issues with pasta while running it with podman, tend to invoke pasta
> directly to debug.
>
> I interacted with Stefano regarding this and he told me that pasta
> already detaches
> the UTS namespace and so in order to address this issue, I propose
> that we set the hostname
> as part of `pasta_spawn_cmd()`.Doing this would provide users with a
> clear visual indication that
> they are in a new user namespace (among other ns but that won't be
> indicative here) and avoid
> issues similar to the aforementioned.
>
> I'm looking to gather more opinions on how this change, if
> implemented, would affect the
> functionality. Looking forward to the discussion.
>
> Thank you
>
> danishpraka.sh
> :wq
>
I don't have an issue with the hostname suggestion but it will not solve 
the problem of users not understanding that they are in a new user 
namespace. Maybe a more universal solution is to print a log line with a 
hint when no explicit command is given. Something like: "Spawning new 
shell in user+network namespace". That at least tells the user what 
pasta did and works even in cases where the prompt does not contain the 
hostname.

Paul

Re: Setting hostname while spawning pasta

[Danish Prakash]

> I don't have an issue with the hostname suggestion but it will not solve
> the problem of users not understanding that they are in a new user
> namespace. Maybe a more universal solution is to print a log line with a
> hint when no explicit command is given. Something like: "Spawning new
> shell in user+network namespace". That at least tells the user what
> pasta did and works even in cases where the prompt does not contain the
> hostname

That's a great suggestion but the reason I proposed modifying/setting
the hostname was because it seemed to me a more subtle way to address
this problem.

However, printing to stdout doesn't help in situations where you're
running pasta-in-pasta... as Stefano earlier pointed out. This
solution of modifying and prefixing "pasta-" to the hostname works
nicely in this case while also acting as a subtle indication that
*something* has changed, not leaving the user entirely clueless.


danishpraka.sh
:wq


On Mon, May 13, 2024 at 5:29 PM Paul Holzinger <pholzing@redhat.com> wrote:
>
> Hi,
>
> On 09/05/2024 09:00, Danish Prakash wrote:
> > Hello
> >
> > I was having a discussion with a colleague of mine on how `pasta` when invoked
> > independently drops you in a new user and network namespace and how that causes
> > some folks to not realize what has happened especially because there's no cue
> > as to what transpired. This is not uncommon though, because a lot of
> > times, folks having
> > issues with pasta while running it with podman, tend to invoke pasta
> > directly to debug.
> >
> > I interacted with Stefano regarding this and he told me that pasta
> > already detaches
> > the UTS namespace and so in order to address this issue, I propose
> > that we set the hostname
> > as part of `pasta_spawn_cmd()`.Doing this would provide users with a
> > clear visual indication that
> > they are in a new user namespace (among other ns but that won't be
> > indicative here) and avoid
> > issues similar to the aforementioned.
> >
> > I'm looking to gather more opinions on how this change, if
> > implemented, would affect the
> > functionality. Looking forward to the discussion.
> >
> > Thank you
> >
> > danishpraka.sh
> > :wq
> >
> I don't have an issue with the hostname suggestion but it will not solve
> the problem of users not understanding that they are in a new user
> namespace. Maybe a more universal solution is to print a log line with a
> hint when no explicit command is given. Something like: "Spawning new
> shell in user+network namespace". That at least tells the user what
> pasta did and works even in cases where the prompt does not contain the
> hostname.
>
> Paul
>

Re: Setting hostname while spawning pasta

[Stefano Brivio]

On Mon, 13 May 2024 13:59:22 +0200
Paul Holzinger <pholzing@redhat.com> wrote:

> [...]
>
> I don't have an issue with the hostname suggestion but it will not solve 
> the problem of users not understanding that they are in a new user 
> namespace. Maybe a more universal solution is to print a log line with a 
> hint when no explicit command is given. Something like: "Spawning new 
> shell in user+network namespace". That at least tells the user what 
> pasta did and works even in cases where the prompt does not contain the 
> hostname.

Hmm, sure, that's probably the clearest indication possible in the
general case (minus the fact that it doesn't really help for
pasta-in-pasta as Danish pointed out).

On the other hand I would find it quite noisy, and the man page already
explains what we're doing. Sure, one could run it with '-q', but then
it's more typing just to avoid that noise.

By the way, I'm (sloowly) reworking the website, and the namespacing
aspect is something I plan to show in a separate diagram as well.

Plus, I guess we wouldn't print that when a command is explicitly
given, but then 'pasta' would print that message, while 'pasta -- sh'
wouldn't, so things would quite easily look inconsistent.

All in all, I have quite a preference against an additional message, but
if more people on the list think it's a nice addition, then let's go
for it.

-- 
Stefano