On Fri, Jan 25, 2013 at 09:44:50AM -0800, Eric W. Biederman wrote: > Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> writes: > > > On Fri, Jan 25, 2013 at 04:02:10PM +0100, Karel Zak wrote: > >> On Mon, Jan 21, 2013 at 01:38:02AM -0500, Zbigniew Jędrzejewski-Szmek wrote: > >> > I guess that most of the time one will want to enter all > >> > namespaces, and then it is easier not to have to remember > >> > all the option names. > >> > >> Not sure if this is the right argument. From my point of view it's > >> better to be explicit for such things, something like --all sounds > >> like a magical blackbox where semantic depends on features implemented > >> by kernel and nsenter(1). > > Which is the reason I did not implement --all in the first place, > although it is attractive. > > > Hi, > > > > I'm was trying to document how a user should enter a namespace > > container created by systemd-nspawn. I would prefer not to have the > > user type 'nsenter -t $PID -muipn', but something simpler. > > As I see it nsenter is the raw tool for when you need to get your > hands dirty. lxc already has a more integrated version. And > it isn't hard to define a simple wrapper such as: > > cat > systemd-nsenter <<EOF > #!/bin/sh > PID=$1 > shift > exec nsenter -t $PID --mount --ipc --pid --net --uts "$@" > EOF > > If you need things to be slightly simpler and it isn't worth deriving > your own c wrapper. > > I assume you didn't include -U because systemd-nspawn doesn't create > a user namespace? Yes, systemd-nspawn so far doesn't. > Of course at the point you wrap nsenter you probably want to have > something that takes a name and looks at a pid file I expect. > > > What about an alternative patch, which implements --all which means: > > "all namespaces supported by the kernel" (i.e. iterate over /proc/$PID/ns/*' > > and enter all of them. This way the behaviour would depend only on the > > kernel options, not on util-linux version. > > If we add another namespace will it have oddball semantics to worry > about? So far the mount namespace, the user namespace, and the pid > namespace do. So judging from history you have a 50/50 chance of > needing special code in nsenter. I don't expect blinding iterarting > over /proc/[pid]/ns/* will remove the need for future changes to > nsenter if and when we add another namespace. OK, so that's not an option. > What will keep from breaking peoples scripts is to not have an option > that is ambiguous. Well, in the two patches I was careful to write "enter all of the above namespaces", to underline the fact that the kernel might know about some additional ones. OK, bear with me. What about --all meaning "enter all of the namespaces that nsenter has support for, and fail if there's a namespace diffent between target and requesting process that nsenter doesn't know about"? In scripts one could say 'nsenter -<wanted namespaces>', but for quick'n'dirty commandline use, nsenter --all would work. Zbyszek -- To unsubscribe from this list: send the line "unsubscribe util-linux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
