On 02/05/2012 10:00 PM, no-re...@cfengine.com wrote: > Forum: CFEngine Help > Subject: Re: CFEngine Help: Editing /etc/shadow file using variables > Author: josephvj > Link to topic: https://cfengine.com/forum/read.php?3,24725,24728#msg-24728 > > Hi Nick, > > Thank you for the reply. > But I still have a doubt, in the above scenario user's uid, gid must be given > during user creation within the script. And so we can replace/add the > corresponding line in the shadow file. If the user was created without > passing the uid & gid within the script, then the added user is configured to > the next uid & gid available by default, right? So how can we edit the shadow > file in such a scenario?
I think this is happening because of the normal ordering. Consider this, http://cfengine.com/manuals/cf3-reference.html#Normal-ordering You are using Vars, Classes, commands, files, and reports in your create users Normal ordering for agent would do vars, classes, files, commands, and reports in that order. On the first pass the class add_user is defined because the user exists function tells you there is no entry in /etc/passwd for the user. After classes, files and because add_user is defined it tries to apply the edit_line to /etc/shadow. If you look at the set_user_field bundle from the stdlib you can see it tries to edit the field when it matches on a line that starts with the username followed by a colon. bundle edit_line set_user_field(user,field,val) # Set the value of field number "field" in # a :-field formatted file like /etc/passwd { field_edits: "$(user):.*" comment => "Edit a user attribute in the password file", edit_field => col(":","$(field)","$(val)","set"); } But at this point, the useradd command has not run, and there is no entry in /etc/shadow for the user. And no edits were required on the file so the promise is considered to be kept. Moving on to commands and your useradd command is run, and now there is probably and entry in /etc/shadow for the user. Now we come to the second pass, and you still have the add_user class defined, you come to your files promise but no edit is made because on the first pass no edits on the file indicated that the promise was already kept, and we no longer need to modify the file. Your run ends .... The next execution of the policy the add_user class wont be defined because the user exists, and you have the user field edit restricted by the add_user class. So if you remove the add_user restriction on the /etc/shadow promise your password should probably get set on a subsequent execution in 5 minutes or whatever. The key thing here to realize and you may or may not want this behavior, is that now the password setting will always be enforced. Each time your policy runs that users password will be set to what you defined. I hope that makes sense. And hopefully im not wrong in my evaluation ;) Nick Anderson <n...@cmdln.org> _______________________________________________ Help-cfengine mailing list Help-cfengine@cfengine.org https://cfengine.org/mailman/listinfo/help-cfengine
