Adduser only one or. two users

[Ishaan Mahajan]

Hi,

This is the line I have got - RUN sudo adduser --shell $USERSHELLPATH --disabled-password --gecos "" $USERNAME && \

echo "$USERNAME ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/$USERNAME && \

chmod 0440 /etc/sudoers.d/USERNAME

However, I keep getting the error, 

adduser: Only one or two names allowed.

--

How do I get around this?  

Have a great day ahead!

Best,

Ishaan Mahajan

[Cindy Sue Causey]

Does this line:

chmod 0440 /etc/sudoers.d/USERNAME

Need to continue using "$" as part of its variable?

That stood out as different. If that's not it, I'm totally out on a
very thin limb (beyond my payscale) here. :)

Cindy :)
--
Talking Rock, Pickens County, Georgia, USA
* runs with birdseed *

[Dan Ritter]

Ishaan Mahajan wrote:
> Hi,
>
> This is the line I have got - RUN sudo adduser --shell $USERSHELLPATH
> --disabled-password --gecos "" $USERNAME && \
> echo "$USERNAME ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/$USERNAME && \
> chmod 0440 /etc/sudoers.d/USERNAME
> However, I keep getting the error,
> adduser: Only one or two names allowed.--
> How do I get around this?

sudo adduser --shell $USERSHELLPATH --disabled-password --gecos "" $USERNAME

That's your first command line. --gecos expects a value. You are
literally supplying no value.

Why don't you leave the --gecos "" out entirely, if you aren't
going to populate it with a human-readable name?

-dsr-

[Greg Wooledge]

On Thu, Aug 04, 2022 at 01:24:04PM -0400, Cindy Sue Causey wrote:
> On 8/4/22, Ishaan Mahajan <ishaana...@gmail.com> wrote:
> > Hi,
> >
> > This is the line I have got - RUN sudo adduser --shell $USERSHELLPATH
> > --disabled-password --gecos "" $USERNAME && \
> > echo "$USERNAME ALL=(ALL) NOPASSWD: ALL" > /etc/sudoers.d/$USERNAME && \
> > chmod 0440 /etc/sudoers.d/USERNAME
> > However, I keep getting the error,
> > adduser: Only one or two names allowed.--
> > How do I get around this?
> > Have a great day ahead!
>
>
> Does this line:
>
> chmod 0440 /etc/sudoers.d/USERNAME
>
> Need to continue using "$" as part of its variable?
>
> That stood out as different. If that's not it, I'm totally out on a
> very thin limb (beyond my payscale) here. :)

You're correct. That's one error, but not the one causing the message.

In order to find the other errors, we would need to know the contents
of the $USERSHELLPATH and $USERNAME variables.

Also, those should be "double quoted". "$USERNAME" in every instance.

Finally, this thing is using sudo to run adduser, but afterward it's
attempting to write to /etc/sudoers.d/$USERNAME without using sudo.
So, either that write is going to fail, or the sudo wasn't needed in
the first place.

[Charles Curley]

On Thu, 4 Aug 2022 13:23:11 -0400
Dan Ritter <d...@randomstring.org> wrote:

> sudo adduser --shell $USERSHELLPATH --disabled-password --gecos ""
> $USERNAME
>
> That's your first command line. --gecos expects a value. You are
> literally supplying no value.
>
> Why don't you leave the --gecos "" out entirely, if you aren't
> going to populate it with a human-readable name?

I'll second this one, and add, you should quote variable names in order
to avoid spaces in the variables screwing things up. So: "$USERNAME",
not $USERNAME. What happens if the user name is Fred Flintstone?

Of course we don't see how, if at all, you've qualified your inputs so
this suggestion may be moot.

--
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[to...@tuxteam.de]

On Thu, Aug 04, 2022 at 12:17:54PM -0600, Charles Curley wrote:
> On Thu, 4 Aug 2022 13:23:11 -0400
> Dan Ritter <d...@randomstring.org> wrote:
>
> > sudo adduser --shell $USERSHELLPATH --disabled-password --gecos ""
> > $USERNAME
> >
> > That's your first command line. --gecos expects a value. You are
> > literally supplying no value.
> >
> > Why don't you leave the --gecos "" out entirely, if you aren't
> > going to populate it with a human-readable name?
>
> I'll second this one, and add, you should quote variable names in order
> to avoid spaces in the variables screwing things up. So: "$USERNAME",
> not $USERNAME. What happens if the user name is Fred Flintstone?

This is very good advice. The variable values get expanded in-place,
so a white space in the value will wreak havoc.

Folks, always quote your variables :-)

Same goes for $USERSHELLPATH, it should be "$USERSHELLPATH".

Cheers
--
t

[Ishaan Mahajan]

Sorry for another email but this is what it looks like now - RUN sudo adduser --shell $USERSHELLPATH --disabled-password $USERNAME && \

However, I am still running into the same problem.

Thanks,

Ishaan

--

[Greg Wooledge]

On Fri, Aug 05, 2022 at 11:05:50AM +0530, Ishaan Mahajan wrote:
> Sorry for another email but this is what it looks like now - RUN sudo
> adduser --shell $USERSHELLPATH --disabled-password $USERNAME && \
> However, I am still running into the same problem.

You need to listen to what people have already said.

We need to know what's IN THOSE VARIABLES.

You need to double-quote all variable expansions. "$USERNAME" with quotes
instead of $USERNAME without quotes.

And, as Cindy pointed out, you need to proofread for missing dollar signs
and other typos.

Finally, SHOW US the actual problem, in context. Don't just describe it
or paraphrase it. Actually COPY the text from your terminal, showing
your shell prompt, the command you typed, and the full output of the
script.

In fact, for short scripts, what I like to do is run "cat thescript"
as a shell command, and then run the script as a second shell command.
Then I copy the entire thing, from the "cat" all the way down to the
bottom of the script's output, and include all of that in the message.
That way people can see the script, and see its output, all together at
one time.

Here's an example. Let's say I have a script that's supposed to divide
a number by 2, and write the result. And suppose it's got a couple
bugs in it. I might ask for help like this:



"My script doesn't work. If I enter an odd number, I don't get the right
answer. And if I enter more than one number, it only divides the first
one. Why?"

unicorn:~$ cat foo
#!/bin/bash

half() {
echo $(( $1 / 2 ))
}

read -r -p "Enter a number: " number
half $number
unicorn:~$ ./foo
Enter a number: 15
7
unicorn:~$ ./foo
Enter a number: 6 8
3



Here, you can see the whole script, and the results of running it twice,
DEMONSTRATING the problem. So now, you can see what I'm seeing. You
know exactly what I gave as input. You know exactly what the script
wrote as output. Now you can actually try to point out the bugs in my
script.

There are at least three:

1) The / operator is integer division, not floating point. If the
expected result of the first run is 7.5 then I need to use bc or awk or
something to do the floating point division.

2) Failure to quote $number means the input gets split into multiple
words when it's passed to the function. $1 will contain the first
word, and $2 the second word, etc. Of course, there's more to it than
that. You can't rely on this to do ONLY word splitting. If the user
types * then the function will receive a bunch of filenames as its
arguments. Shells SUCK.

unicorn:~$ ./foo
Enter a number: *
./foo: line 4: 00INDEX: value too great for base (error token is "00INDEX")

3) There is no part of my script that handles multiple inputs as multiple
divisions. It just isn't WRITTEN to do it. The entire thing needs to
be redone, with proper and safe input word splitting, and a loop.

Sorry for the small tangent, but since bug number 2 in my script is also
present in yours, despite our previous warnings which you ignored, maybe
seeing it in action might help you.

[Stefan Monnier]

> Reminds me of a strategy for solving difficult debugging problems, i
> used to teach to developers. We called it "teach a monkey", meaning,
> explain it to an outside person, a spouse or kid might do, because their
> attention and willingness to understand forces YOU to slow down and more
> often than not, this leads to the discovery of the mistake in thinking,
> that lead to the bug. :-)

https://en.wikipedia.org/wiki/Rubber_duck_debugging


Stefan