Added the infra SOPs ported to asciidoc.
This commit is contained in:
Adam Saleh
parent
8a7f111a12
commit
a0301e30f1
148 changed files with 18575 additions and 17 deletions
294
modules/sysadmin_guide/pages/accountdeletion.adoc
Normal file
294
modules/sysadmin_guide/pages/accountdeletion.adoc
Normal file
|
|
@ -0,0 +1,294 @@
|
|||
= Account Deletion SOP
|
||||
|
||||
For the most part we do not delete accounts. In the case that a deletion
|
||||
is paramount, it will need to be coordinated with appropriate entities.
|
||||
|
||||
Disabling accounts is another story but is limited to those with the
|
||||
appropriate privileges. Reasons for accounts to be disabled can be one
|
||||
of the following:
|
||||
|
||||
____
|
||||
* Person has placed SPAM on the wiki or other sites.
|
||||
* It is seen that the account has been compromised by a third party.
|
||||
* A person wishes to leave the Fedora Project and wants the account
|
||||
disabled.
|
||||
____
|
||||
|
||||
== Contents
|
||||
|
||||
* Disabling
|
||||
** Disable Accounts
|
||||
** Disable Groups
|
||||
* User Requested disables
|
||||
* Renames
|
||||
** Rename Accounts
|
||||
** Rename Groups
|
||||
* Deletion
|
||||
** Delete Accounts
|
||||
** Delete Groups
|
||||
|
||||
=== Disable
|
||||
|
||||
Disabling accounts is the easiest to accomplish as it just blocks people
|
||||
from using their account. It does not remove the account name and
|
||||
associated UID so we don't have to worry about future, unintentional
|
||||
collisions.
|
||||
|
||||
== Disable Accounts
|
||||
|
||||
To begin with, accounts should not be disabled until there is a ticket
|
||||
in the Infrastructure ticketing system. After that the contents inside
|
||||
the ticket need to be verified (to make sure people aren't playing
|
||||
pranks or someone is in a crappy mood). This needs to be logged in the
|
||||
ticket (who looked, what they saw, etc). Then the account can be
|
||||
disabled.:
|
||||
|
||||
....
|
||||
ssh db02
|
||||
sudo -u postgres pqsql fas2
|
||||
|
||||
fas2=# begin;
|
||||
fas2=# select * from people where username = 'FOOO';
|
||||
....
|
||||
|
||||
Here you need to verify that the account looks right, that there is only
|
||||
one match, or other issues. If there are multiple matches you need to
|
||||
contact one of the main sysadmin-db's on how to proceed.:
|
||||
|
||||
....
|
||||
fas2=# update people set status = 'admin_disabled' where username = 'FOOO';
|
||||
fas2=# commit;
|
||||
fas2=# /q
|
||||
....
|
||||
|
||||
== Disable Groups
|
||||
|
||||
There is no explicit way to disable groups in FAS2. Instead, we close
|
||||
the group for adding new members and optionally remove existing members
|
||||
from it. This can be done from the web UI if you are an administrator of
|
||||
the group or you are in the accounts group. First, go to the group info
|
||||
page. Then click the (edit) link next to Group Details. Make sure that
|
||||
the Invite Only box is checked. This will prevent other users from
|
||||
requesting the group on their own.
|
||||
|
||||
If you want to remove the existing users, View the Group info, then
|
||||
click on the View Member List link. Click on All under the Results
|
||||
heading. Then go through and click on Remove for each member.
|
||||
|
||||
Doing this in the database instead can be quicker if you have a lot of
|
||||
people to remove. Once again, this requires someone in sysadmin-db to do
|
||||
the work:
|
||||
|
||||
....
|
||||
ssh db02
|
||||
sudo -u postgres pqsql fas2
|
||||
|
||||
fas2=# begin;
|
||||
fas2=# update group, set invite_only = true where name = 'FOOO';
|
||||
fas2=# commit;
|
||||
fas2=# begin;
|
||||
fas2=# select p.name, g.name, r.role_status from people as p, person_roles as r, groups as g
|
||||
where p.id = r.person_id and g.id = r.group_id
|
||||
and g.name = 'FOOO';
|
||||
fas2=# -- Make sure that the list of users in the groups looks correct
|
||||
fas2=# delete from person_roles where person_roles.group_id = (select id from groups where g.name = 'FOOO');
|
||||
fas2=# -- number of rows in both of the above should match
|
||||
fas2=# commit;
|
||||
fas2=# /q
|
||||
....
|
||||
|
||||
=== User Requested Disables
|
||||
|
||||
According to our Privacy Policy, a user may request that their personal
|
||||
information from FAS if they want to disable their account. We can do
|
||||
this but need to do some extra work over simply setting the account
|
||||
status to disabled.
|
||||
|
||||
== Record User's CLA information
|
||||
|
||||
If the user has signed the CLA/FPCA, then they may have contributed
|
||||
something to Fedora that we'll need to contact them about at a later
|
||||
date. For that, we need to keep at least the following information:
|
||||
|
||||
* Fedora username
|
||||
* human name
|
||||
* email address
|
||||
|
||||
All of this information should be on the CLA email that is sent out when
|
||||
a user signs up. We need to verify with spot (Tom Callaway) that he has
|
||||
that record. If not, we need to get it to him. Something like:
|
||||
|
||||
....
|
||||
select id, username, human_name, email, telephone, facsimile, postal_address from people where username = 'USERNAME';
|
||||
....
|
||||
|
||||
and send it to spot to keep.
|
||||
|
||||
== Remove the personal information
|
||||
|
||||
The following sequence of db commands should do it:
|
||||
|
||||
....
|
||||
fas2=# begin;
|
||||
fas2=# select * from people where username = 'USERNAME';
|
||||
....
|
||||
|
||||
Here you need to verify that the account looks right, that there is only
|
||||
one match, or other issues. If there are multiple matches you need to
|
||||
contact one of the main sysadmin-db's on how to proceed.:
|
||||
|
||||
....
|
||||
fas2=# update people set human_name = '', gpg_keyid = null, ssh_key = null, unverified_email = null, comments = null, postal_address = null, telephone = null, facsimile = null, affiliation = null, ircnick = null, status = 'inactive', locale = 'C', timezone = null, latitude = null, longitude = null, country_code = null, email = 'disabled1@fedoraproject.org' where username = 'USERNAME';
|
||||
....
|
||||
|
||||
Make sure only one record was updated:
|
||||
|
||||
....
|
||||
fas2=# select * from people where username = 'USERNAME';
|
||||
....
|
||||
|
||||
Make sure the correct record was updated:
|
||||
|
||||
....
|
||||
fas2=# commit;
|
||||
....
|
||||
|
||||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
The email address is both not null and unique in the database. Due to
|
||||
this, you need to set it to a new string for every user who requests
|
||||
deletion like this.
|
||||
====
|
||||
|
||||
=== Renames
|
||||
|
||||
In general, renames do not require as much work as deletions but they
|
||||
still require coordination. This is because renames do not change the
|
||||
UID/GID but some of our applications save information based on
|
||||
username/groupname rather than UID/GID.
|
||||
|
||||
== Rename Accounts
|
||||
|
||||
[WARNING]
|
||||
.Warning
|
||||
====
|
||||
Needs more eyes This list may not be complete.
|
||||
====
|
||||
|
||||
* Check the databases for koji, pkgdb, and bodhi for occurrences of
|
||||
the old username and update them to the new username.
|
||||
* Check fedorapeople.org for home directories and yum repositories under
|
||||
the old username that would need to be renamed
|
||||
* Check (or ask the user to check and update) mailing list subscriptions
|
||||
on fedorahosted.org and lists.fedoraproject.org under the old
|
||||
username@fedoraproject.org email alias
|
||||
* Check whether the user has a username@fedoraproject.org bugzilla
|
||||
account in python-fedora and update that. Also ask the user to update
|
||||
that in bugzilla.
|
||||
* If the user is in a sysadmin-* group, check for home directories on
|
||||
bastion and other infrastructure boxes that are owned by them and need
|
||||
to be renamed (Could also just tell the user to backup any files there
|
||||
themselves b/c they're getting a new home directory).
|
||||
* grep through ansible for occurrences of the username
|
||||
* Check for entries in trac on fedorahosted.org for the username as an
|
||||
"Assigned to" or "CC" entry.
|
||||
* Add other places to check here
|
||||
|
||||
== Rename Groups
|
||||
|
||||
[WARNING]
|
||||
.Warning
|
||||
====
|
||||
Needs more eyes This list may not be complete.
|
||||
====
|
||||
* grep through ansible for occurrences of the group name.
|
||||
* Check for group-members,group-admins,group-sponsors@fedoraproject.org
|
||||
email alias presence in any fedorahosted.org or lists.fedoraproject.org
|
||||
mailing list
|
||||
* Check for entries in trac on fedorahosted.org for the username as an
|
||||
"Assigned to" or "CC" entry.
|
||||
* Add other places to check here
|
||||
|
||||
=== Deletion
|
||||
|
||||
Deletion is the toughest one to audit because it requires that we look
|
||||
through our systems looking for the UID and GID in addition to looking
|
||||
for the username and password. The UID and GID are used on things like
|
||||
filesystem permissions so we have to look there as well. Not catching
|
||||
these places may lead to security issus should the UID/GID ever be
|
||||
reused.
|
||||
|
||||
[NOTE]
|
||||
.Note
|
||||
====
|
||||
Recommended to rename instead When not strictly necessary to purge all
|
||||
traces of an account, it's highlyrecommended to rename the user or group
|
||||
to something like DELETED_oldusername instead of deleting. This avoids
|
||||
the problems and additional checking that we have to do below.
|
||||
====
|
||||
== Delete Accounts
|
||||
|
||||
[WARNING]
|
||||
.Warning
|
||||
====
|
||||
Needs more eyes This list may be incomplete. Needs more people to look
|
||||
at this and find places that may need to be updated
|
||||
====
|
||||
* Check everything for the #Rename Accounts case.
|
||||
* Figure out what boxes a user may have had access to in the past. This
|
||||
means you need to look at all the groups a user may ever have been
|
||||
approved for (even if they are not approved for those groups now). For
|
||||
instance, any git*, svn*, bzr*, hg* groups would have granted access to
|
||||
hosted03 and hosted04. packager would have granted access to
|
||||
pkgs.fedoraproject.org. Pretty much any group grants access to
|
||||
fedorapeople.org.
|
||||
* For those boxes, run a find over the files there to see if the UID
|
||||
owns any files on the system:
|
||||
+
|
||||
....
|
||||
# find / -uid 100068 -print
|
||||
....
|
||||
+
|
||||
Any files owned by that uid must be reassigned to another user or::
|
||||
removed.
|
||||
|
||||
[WARNING]
|
||||
.Warning
|
||||
====
|
||||
What to do about backups? Backups pose a special problem as they may
|
||||
contain the uid that's being removed. Need to decide how to handle this
|
||||
====
|
||||
* Add other places to check here
|
||||
|
||||
== Delete Groups
|
||||
|
||||
[WARNING]
|
||||
.Warning
|
||||
====
|
||||
Needs more eyes This list may be incomplete. Needs more people to look
|
||||
at this and find places that may need to be updated
|
||||
====
|
||||
* Check everything for the #Rename Groups case.
|
||||
* Figure out what boxes may have had files owned by that group. This
|
||||
means that you'd need to look at the users in that group, what boxes
|
||||
they have shell accounts on, and then look at those boxes. groups used
|
||||
for hosted would also need to add hosted03 and hosted04 to that list and
|
||||
the box that serves the hosted mailing lists.
|
||||
* For those boxes, run a find over the files there to see if the GID
|
||||
owns any files on the system:
|
||||
+
|
||||
....
|
||||
# find / -gid 100068 -print
|
||||
....
|
||||
+
|
||||
Any files owned by that GID must be reassigned to another group or
|
||||
removed.
|
||||
|
||||
[WARNING]
|
||||
.Warning
|
||||
====
|
||||
What to do about backups? Backups pose a special problem as they may
|
||||
contain the gid that's being removed. Need to decide how to handle this
|
||||
====
|
||||
* Add other places to check here
|
||||
Loading…
Add table
Add a link
Reference in a new issue