- All right, let's have a look at this lab.
Before we begin, I'm not saying that you should use command.
Using command module is still a bad idea
but I just want to show you if you need to do it,
how you can do it.
So let's work out an example.
I will try to keep it as simple
so that we get to what we really want to do.
So name is create user, user, okay.
We make it a little bit flexible.
Then vars.
And in vars I'm using user Linda.
Then hosts, ansible2 is good enough
and we use tasks.
And first I want you to realize what again
the default behavior is.
So I'm using tasks, name, install, or again
create user, user is twice the same information
that really doesn't matter too much.
And then I'm using command useradd user and that's it.
So what was happening again?
If we are using it this way
let's run it Ansible playbook on lab6.yaml.
And there we can see user at user Linda already exists
and we get an rc9 and we get a standard error
and we get so many things.
So how are we going to make this item potent?
Well, I think we need to register the value
of this user at command already exists somewhere
and we need to do something with it to make it item potent.
So how can we do that?
Well, Ansible playbook lab6.yaml let's get there again.
And let's use our editor create user
and let's use register user out, and then we can do what?
Well, we can do something like when,
when user out,
when userout.rc
equals zero, does that make sense?
Probably not.
It would be a nice chicken and egg problem.
And in this chicken and egg problem,
we cannot do the command only if the command is successful.
So we need to check it before.
Register is not a bad idea, but we need to do that before.
So how are we going to do that?
We create before check before check
and we are going to do what?
We are going to use fail, and we are going to use
fail with the message, user already exists.
And if user already exists, then we are going
to fail out of it.
And that is how we can prevent the failure where
it really shouldn't be failing but we are using the fail
when, when what?
When, we can use the fail when?
When we need to check something before.
So what are we going to do?
Check user, another command.
So command id user,
and then register id user.
Id user is going to be the variable
in which the id command results will be stored.
And that will be an id user.
And when
iduser.rc equals zero
then we are going to fail.
And if id user does not equal zero
then we are going to continue.
And how are we going to take care of continuing
if we do not create the user again?
Well, I see one option only
and that is by creating a new play.
So let's call this play continuing, and let's run it
on hosts, ansible2 with the tasks
debug
and message, we made it or whatever.
I like silly messages like that
just to figure out that we made it.
So how is this going to work?
Ansible playbook lab6.yaml.
So we can see that before check,
we have a skipping on ansible2
and we have a change on ansible2.
So what were we doing again before check
we fail if user already exists.
So we should fail when iduser.rc equals zero
and the iduser.rc equals zero.
That doesn't work out too well
because we see it failing on the user at command
and that's what we need to work around.
So how do we approach in cases like that?
Well, in cases like that, you should use debug.
And in debug, you print the variable iduser.
We wanna see what id user is all about.
So let's run it again.
And now we can see that id user has a return code zero
but Hey, the zero is not between double quotes,
it's just a zero.
So it's still doing a skipping
and it's still failing on the creation of the user.
So can we do this in another way?
Well, let's do id user dot.rc is zero
as string value instead of re again.
So let you use iduser.rc as an integer value
instead of a string value and see
if that's doing anything better.
That is always what I would recommend
if your variables are not interpreted the right way.
Might be up to you because you think it's a string
then it happens to be an integer.
You think it's an integer,
then it happens to be a bully.
And ah, there are so many reasons why that can go wrong
and look at that.
Now we are able to move on.
So before check is giving me a fatal changed user
already exist, and that is what we wanted to do.
Now if we want to make it more elegant, we are using fail.
So what do we have here?
We have our failure occurring when the user exists.
And that's about all that you can do
to make the command module item potent.
The command module isn't item potent.
Rule use real modules.
If you're using command, this is about as good
as you can make it to fake some item potency.
But if you want a real stable Ansible solution
look for dedicated modules.