Kindly respond anyone.
I think using BLPackage to change password of a user is not the best option. You will end up changing lot of other parameters to values which you might not want to. How are you handling attributes of the user like home directory, shell etc. These attributes will differ per user.
Instead use the "Cmd" section of the BLPackage, create local properties in BLPackage for user and passwd and then use the "passwd ??User??" command.
Thanks for your update. I have a query. I assumed
1. "Cmd" section of BLPackage means are you talking about the External Commands? If yes, I've created a BLPackage with a Single External Command as passwd ??ROOT_USER?? Here how can I pass the password property to this command. Am I doing here is correct.
If I'm doing wrong, please suggest me. I'm eagarly waiting for your valuable inputs on this.
If you don't mind can you give me step by step procedure. Thanks in advance.
Please help me out.
i used to do the following to change the root password:
- change the password on one server
- browse the server which you changed the password.
- go to /etc/shadow and right click add to depot as blpackage
- go to the package and open it then and change the action to modify.
- right click on the package and deploy gainest the unix servers.
Thanks for update, but as Saurabh said we have to consider many things while updating password. But tell me one thing, when you are assinging different password update BLPackages to different users, how are you managing them. Each time when they want to change the password, you have to create a new BLPackage and assign it to them. I thing it would be difficult.
Please let me know any other suggestions.
there is a 'unix users' object on the servers (7.5+) - you can create a blpackage from the users listed in the live browse of that section and edit the passwd in the package.
Your initial thought was ok
But i am afraid i do not know of a way to disable specific fields in a BLPackage edit mode
And i am afraid Unix Users CO does not allow limiting actions to specific users
You might be able to control this by pushing some ACL's
This way only super user in a role with root permission will be able to execute a deploy job changing the root pass
Hi Bill & Tal
Thanks for your valuable inputs. Let me explain the problem:
Actaully I need to create two different BLPackages (user password update) and assign it to two different teams, from then we (BLadmins) are not going to maintain those BLPackages unless any problems found. Our intention is to update the each team's respective user's password themself.
What I'm trying here is restricting the user to change the name&path fields of the BLPackage. So, he will be able to update password fied only. Hope i'm not confusing you.
If this feature doesn't exist, please do suggest me any other way. Any other alternative way to achieve this requirement is appreciated.
As i said
I dont think it is possible (i sent question to Dev , still waiting for respond)
So to ensure a specific user with specific role will not use this package to change root pass
Is to limit its role permissions on the agent side by pushing ACL's
instead of using the unix users object CO you may want to use a nsh script job to do this. then grant your roles access to run that script job and pass a property value to the script job - give the roles access to the property you are passing to the script.
Can you try with Component Templates and the right-click action "updatePassword" on users? If you create one Component Template for each team which contains all the users for that specific team and then givout read-only rights on that Component Template + the right to execute the "updatePassword" command. I guess you could then limit a team to only be able to update password on a sub-set of users. Could that help?
The updatePassword action on unix users:
This could work, however I believe the user could still edit the package and change the username they are deploying. maybe if they can only deploy to the component this will work?
I would really appreciate all of you. You people really helping me a lot. First I want to say thanks to each and every one.
Reply to Jrellme:
What you suggested is exactly fitting my requirement. But the problem is if the user (oracle) wants to update on more than 200+ servers (as oracle user exists on 200+ servers), then it would be very difficult to manually update for each and every server individually. To update on bulk server at a time we need to create BLPackage too. Now in my BLDeploy job contains (component + BLPackage). So, again here we are facing the same problem with BLPackage. We've to allow the user to update the password in BLPackage, where the user could change the name & path fields of BLPackage. That means again we are back to previous state.
If I'm not wrong, Bill is talking about the same problem in his trail mail.
So, still my problem persists.
If this is not possible we have to think about NSH script as Bill said.
Could anyone please post the NSH script if you have one, where we can pass the host names and password as parameters to the NSH script. Where the password is common for all the hosts in the list for a user mentioned in the script.
Please don't frustate with my queries.
Strange issue found: (below example)
1. Create Component Template to discover root user.
2. Create BLPackage for "root" user to update password. (Live Browse ->Unix Users ->root ->right click -> Add to depot as BLPackage)
3. Create BLDeploy Job with(Component (root) + BLPackage) works fine.
if i change the user in BLPackage from "root" user to "oracle" user and when I executed the BLDeply job, the job executed successfully and the password updated for "oracle" user though our discovered component is for "root" user.
Hope I'm not confusing you.