Lxc-attach --uid parameter error

LXC
1

What is the deal with that --uid parameter to lxc-attach? Acc. to the man page it is supposed to exec command as a given user. However every time I try to pass that --uid parameter to lxc-attach I get lxc-attach: could not parse command line

Like:

k.nick@tumbleweed:~> lxc-attach --name centos7 --uid user1
lxc-attach: could not parse command line

However (without --uid it works):

k.nick@tumbleweed:~> lxc-attach --name centos7 
bash-4.2#

Of course I made sure that user1 exists inside the container.
Tested it with centos7 and ubuntu xenial, both times with same results.

2

Most likely the UID should be numeric. Because if it is not numeric, lxc-attach should open the image, look into /etc/passwd, find the username, and then discern the numeric UID. And that’s is not happening.

3

Thanks for your input. Indeed providing a numerical id seems to work.
However I feel that the current situation is rather unfortunate and should be considered a bug. Until this gets fixed I’d like to suggest at least one of:

  • make a hint in the man page
  • add a hint to the error message about the nature of this issue and mention numerical uid as a workaround
  • …
4

lxc-attach --help shows the following. Both UID and GID are supposed to be numeric though this may not be clear to everyone.

...
  -u, --uid=UID     Execute COMMAND with UID inside the container
  -g, --gid=GID     Execute COMMAND with GID inside the container
...

In the code there is a catch-all statement that does not distinguish between errors.
It might be more involved to add extra code for a clearer message.

Would it be helpful if the documentation looked like

...
  -u, --uid=UID     Execute COMMAND with UID (numeric value) inside the container
  -g, --gid=GID     Execute COMMAND with GID (numeric value) inside the container
...
5

Yes, absolutely! This should prevent people from getting thrown for a loop. While at it, I’d also make a similar change to the man page:

       -u, --uid uid
              Executes the command with user ID uid (use numeric value) inside the container.

       --g, --gid gid
              Executes the command with group ID gid (use numeric value) inside the container.

And a bug report might me a good idea as well…

BTW:
is -u (one dash) but --g (two dashes) correct? This is stated in the man page.

And a paragraph further down they start using the “=” sign as separator of the parameter name (long version) and its value. Is that correct? (Looks confusing and inconsistent to me.)

       -P, --lxcpath=PATH
              Use an alternate  ...
       -o, --logfile=FILE
              Output to ...

       -l, --logpriority=LEVEL
              Set  log ...

       -n, --name=NAME
              Use container ...

       --rcfile=FILE
              Specify the  ...
6

Nice catch for the typo in the documentation.
Can you do the process to request a fix in the documentation through Github?
For such a small typo, it’s quite simple to do this through the Web interface of Github.

  1. Get an account on Github.

  2. Visit the page lxc/doc/lxc-attach.sgml.in at main · lxc/lxc · GitHub, click on Edit and fix the typo.

  3. Click to save and go through the process to create a pull request. All is done through the web.

Repeat with lxc/doc/lxc-execute.sgml.in at main · lxc/lxc · GitHub (lxc-execute has the same typo).

Unix/Linux applications use a common library to perform the parameter parsing. The short parameters have a single letter, like -g. The long parameters word either like --name=NAME or --name NAME. It’s a built-in feature. If the documentation switches between the two formats, then it’s an issue of inconsistency. If one style is predominant and the other is not so much, then it makes sense to fix towards the predominant style.

7

I tried to to that, however I am not that proficient with git(hub) yet.

Hopefully that worked.