Please type centralized_admin.py
for a list of commands
$ centralized_admin.py
Centralized admin tool usage:
Manage units
/usr/local/bin/centralized_admin.py users | Enable, Disable, get information about users.
/usr/local/bin/centralized_admin.py admins | Manage admin users.
/usr/local/bin/centralized_admin.py servers | List servers.
Manage groups
/usr/local/bin/centralized_admin.py usergroups | Manage user groups
/usr/local/bin/centralized_admin.py servergroups | Manage server groups
Manage relationships
/usr/local/bin/centralized_admin.py user_usergroups | Manage the relationship between users and usergroups.
/usr/local/bin/centralized_admin.py server_servergroups | Manage the relationship between servers and servergroups.
Manage authorization
/usr/local/bin/centralized_admin.py roles | Manage access a usergroup has on a servergroup.
You can see a few sections are presented.
The usage presented is self explanatory.
$ centralized_admin.py users
/usr/local/bin/centralized_admin.py users list
/usr/local/bin/centralized_admin.py users groups <user id> (Lists groups the user belongs to)
/usr/local/bin/centralized_admin.py users enable <user id>
/usr/local/bin/centralized_admin.py users disable <user id>
Users list should return to you all users present in centralized database.
If an employee left your company and so has been removed from your github/bitbucket organization, the user will still be present in the list but marked as inactive.
The reason for that is linked to traceability and audits.
Lists usergroups a specific user belongs to.
Users get disabled or enabled by adding/removing them from the github/bitbucket organization.
You may however disable a user from centralized while keeping him/her as part of the guthub organization. This is where you can do so.
$ centralized_admin.py servers
/usr/local/bin/centralized_admin.py servers list
This gets you a list of servers that registered to centralized.
$ centralized_admin.py admins
Descriptions starting with a <C> describe commands requiring to be company admin.
/usr/local/bin/centralized_admin.py admins password_reset <login> | <C> Generate a password for the user and send it by email. The email must be correct.
/usr/local/bin/centralized_admin.py admins promote <login> | <C> Make the user become admin.
/usr/local/bin/centralized_admin.py admins demote <login> | <C> Remove admin rights from a user.
/usr/local/bin/centralized_admin.py admins promotetoca <login> | <C> Make the user become company admin.
/usr/local/bin/centralized_admin.py admins demotefromca <login> | <C> Remove company admin rights from a user.
/usr/local/bin/centralized_admin.py admins change_password <newpassword> | Change your password. This also will log you out.
Admins commands are self explanatory. The concept of company admin must be explained though.
A company admin is an admin with the power to grant or revoke admin privileges to users.
$ centralized_admin.py usergroups
/usr/local/bin/centralized_admin.py usergroups list
/usr/local/bin/centralized_admin.py usergroups create <parent group id> <group name>
/usr/local/bin/centralized_admin.py usergroups delete <user group id>
$ centralized_admin.py servergroups
/usr/local/bin/centralized_admin.py servergroups list
/usr/local/bin/centralized_admin.py servergroups create <parent group id> <group name>
/usr/local/bin/centralized_admin.py servergroups delete <server group id>
List gets you the id, group name and group tree for each group. If you have skipped the documentation part about trees it’s a good time to read it as trees are a critical concept in centralized.
Allows you to create a group. YOu have to specify the parent group id so your new group will fall right under it.
You can delete a group, just use the id given by list.
You cannot delete a group that has subgroups, if you really want to delete a large tree, you have to delete explicitly each group one by one.
$ centralized_admin.py user_usergroups
/usr/local/bin/centralized_admin.py user_usergroups list
/usr/local/bin/centralized_admin.py user_usergroups create <user group id> <login>
/usr/local/bin/centralized_admin.py user_usergroups delete <user usergroup id>
$ centralized_admin.py server_servergroups
/usr/local/bin/centralized_admin.py server_servergroups list
/usr/local/bin/centralized_admin.py server_servergroups create <server group id> <uuid>
/usr/local/bin/centralized_admin.py server_servergroups delete <server servergroup id>
This lets you manage relationships between users and usergroups or server and servergroups.
$ centralized_admin.py roles
/usr/local/bin/centralized_admin.py roles list
/usr/local/bin/centralized_admin.py roles create <user group id> <server group id> '<sudoline>' '<unmanaged groups>'
/usr/local/bin/centralized_admin.py roles delete <role id>
Providing a usergroup access rights to a servergroup.
By creating a role the following happens:
- Active users part of the usergroup or subgroups get created on the server with their globaly unique ID.
- The user group each user respectively belongs to gets created on the server with their globaly unique ID.
- The user SSH keys get added.
- A sudo line configuration gets added to sudoers.
- Unmanaged groups. List of comma separated groups not managed by centralized but that may or may not be present on a machine. Users in this role will be added to each of those groups. Example: “adm” or “adm,www-data”
If a user that was active and got created on a server gets disabled or if the role(s) giving this user access get revoked, the SSH key is removed from the server.
The user will never be deleted, nor it’s home directory. Options to manage this are planned.