need to modify UID of a specific user so created:
#change UID of bob from 555 to 1555
user 'bob' do
action :modify
uid 1555
end
After the chef-client runs with no errors
Recipe: bob-uid-change::default
* user[bob] action modify (up to date)
The user's ID do not change on /etc/passwd
Am I missing something?
Thanks!
Modify will not work if the user (bob) is currently logged in and using the system, i.e. if there are any active processes for bob.
However, if I remember correctly, chef will bomb out if it can't modify the user due to an active process in their name... instead of silently moving on without updating the user as is with this case. It's worth a check to make sure you aren't logged in as bob anywhere first though
Related
This thread points to a webpage that no longer exists: How to change a perforce user to superuser
How do I change the Perforce Protections Table?
Run p4 protect, and add a line like:
super user joe-bob * //...
Each protection entry has five parts:
the access level (super)
whether the entry is for a user or a group
the name of the user/group (joe-bob)
the client IP range this entry applies to (usually * for "everywhere")
the depot path this entry applies to (there's no point in restricting super access to a narrow path since they have permission to edit the protection table themselves anyway, so for super entries this is almost always //...).
I am very new to maximo.
I wanted to know how to inactivate users who are not using maximo anymore. I tried googling this but I am not able to find enough material on Maximo.
I have to write a cron task to do that.
I saw this: http://www.ibm.com/support/knowledgecenter/SSZRHJ/com.ibm.mbs.doc/autoscript/t_cron_task_scripts.html
Can anyone give e a few pointers on how to write it, maybe a sample cron task?
What you're looking for is an Escalation. Escalations are instances of a special Cron Task that has been designed to use a query (a target object and a where clause) to find records and then to apply actions to and / or send emails from each record found.
You'll need to define the where clause against MAXUSER to locate the records you want to deactivate and find or define an Action to change the status of the records found. You can then hook the query and the action together via an Escalation.
The query below is for Oracle database. It looks at the logintracking table and gives you a list of users whose last interaction with Maximo is over 90 days ago:
select * from
(select max(attemptdate) lastLogout, loginid
from logintracking
where loginid <> 'MAXADMIN'
group by loginid
order by max(attemptdate) desc
)
where lastlogout < sysdate - 90
If this is a one-time change, you can manually inactivate the users using Security > Users. If you want to run this weekly, you'd have to change the query a bit to updates the status field in the maxuser table where the user status is still active but is still part of your inactivation list.
Best to experiment in a test environment to make sure your escalation is working properly.
You commented to +Sun that "Maximo is synchronized with LDAP". In that case, try this:
Update the UserMapping on the existing instance of the LDAPSYNC Cron Task to look for a flag that indicates that the user is active in LDAP. (Exactly what to look for will depend on your organization. Your LDAP administrators should be able to help you.) Then, make a second instance of the LDAPSYNC Cron Task that looks identical to the first, except that (1) the GroupMapping doesn't find any groups (use a condition like (objectName=DOES_NOT_EXIST) that won't find anything), and (2) the UserMapping looks for the flag indicating the user is not active and has {INACTIVE} mapped to the STATUS attribute of MAXUSER.
Mirror Question: https://unix.stackexchange.com/questions/217300/where-how-is-user-group-information-stored-in-ubuntu. (I'll remove one of them after I got the answer)
Two places possible: /etc/group and /etc/passwd.
If I use command: adduser [username] [groupname], then the user would be added to the group, and the file /etc/group would then be updated.
However, the file /etc/passwd is not updated. if I check which group I belongs to, via groups command, I can only see groups stated in passwd file.. therefore, the user is not added to the group base on this result.
I'm confused.
What's the meaning of storying group info into /etc/passwd, and /etc/group respectively?
Why adduser only update the group file?
How to add group to the passwd file via command?
Why does groups return group info from passwd file, but not group file?
Thanks.
In these traditional text files (there are other ways, e.g. LDAP), your primary group goes to /etc/passwd (it's e.g. used for permissions of files you create), all additional groups go to /etc/group.
see 1.
That's impossible, but you can change a primary group with usermod -g
That's a misinterpretation, groups shows all groups. But a new group is only picked up when you start a new session (new login). You can use the newgrp command, that starts a session with the given group name as your primary group (you must be member of this group) -- as a side effect, it will consult the user database and update your groups list.
I have this small problem i am using open cart v 2.0.1.1 and when the user is logged in it shows my account with the drop down. I want to display the username of that particular user instead of " my account" can anyone help me with this problem?
in case of you don't know how start
(1) you will need to read this post How to become an open cart guru
(2) steps
you will need to pass the name of the customer in some variable to the template file by adding it to $data array in catalog/controller/common/header.php # class ControllerCommonHeader # function index
in the template file, change the part that checks whether the user is logged in or not, and add the passed customer name or the old header My Account depending on the branch
We are heavily using VirtualBox on our developer workstations. Since we share the images with other developers quite often, I have tried to automate this process as much as possible (cleaning up ap-get cache, removing tmp and log files...). We are using Ubuntu 11.10 with KDE 4.7.4, by the way.
Now I have stumbled over one little annoyance. At the login screen there is a user name prefilled and I could not figure out where this is stored. The problem is, if people get a VirtualBox image and don't realise that the pre-filled user name is not their own and enter their password a couple of time, they lock the said user on our LDAP.
Any idea where is this user name is stored, so I could remove it..?
By default, the login screen (KDM) will preselect the the last logged-in user and I'm not sure where it gets this information. However, you can configure KDM to always preselect the same user in /etc/kde4/kdm/kdmrc:
# Greeter config for all displays
[X-*-Greeter]
...
# Specify, if/which user should be preselected for log in.
# "None" - do not preselect any user
# "Previous" - the user which successfully logged in last time
# "Default" - the user specified in the DefaultUser option
# Default is None
PreselectUser=Default
# The user to preselect if PreselectUser=Default.
# Default is ""
DefaultUser=johndoe
...
Of course, you can set PreselectUser=None if you don't want to select any user.
On OpenSUSE 12.2 it is the /var/lib/kdm/kdmsts
# cat /var/lib/kdm/kdmsts
[PrevUser]
:0=user1
:1=user2
:2=user1