#2079 querying the list of all the aliases that a given FAS id is on
Closed: Will Not/Can Not fix 2 years ago Opened 9 years ago by mspevack.

Out of a desire to have "as much access and visibility to things as needed, but not more" I thought to myself "it would be great to be able to get a list of all the aliases that my FAS uid is part of, so that I can request to be removed from ones that I don't need to be on.

Similar to the manner in which someone can go into FAS and look at their groups, and remove themselves from ones they don't actually need, except that I don't know any way to find out all the email aliases that a given username is on, without asking you guys to figure it out for me.

So I guess there's a one-off request here, as well as a general case to prevent future one-off requests.

Some notes for thought on this (for implementation purposes):

  • Not all aliases are created from fas (Some are done by pkgdb and some are manually edited in puppet)
  • The full list of aliases currently exists on bastion

The full list of aliases created by FAS is (for each group that the person is a member of):

groupname-members@fp.o - all group members
groupname-sponsors@fp.o - all group sponsors
groupname-administrators@fp.o - all group administrators

I think pkgdb creates pkgname-owner@fp.o for all people with watchcommits (?) on a package. CCing toshio to see if that's all.

The notify list is used to generate the pkgdb aliases. Currently, they're all of the form pkgname-owner@fp.o and have all people who could potentially get email for the package for any reason. We've talked about splitting that up at some future point but no one has done any work towards that.



I don't know of any other automatically generated aliases but there are some manual entries in puppet as mmcgrath says.

We discussed this nice 7 year old ticket at todays meeting (as a effort to address old tickets).

Really the only way to get this information is by asking someone with access to bastion01 to grep the local aliases files there (created by fas and ansible both), so I fear that there's no easy automated way to show this for a authenticated user and we will just have to ask people to file tickets when they would like this information.

Thanks for filing this.


Metadata Update from @kevin:
- Issue close_status updated to: Will Not/Can Not fix
- Issue status updated to: Closed (was: Open)

2 years ago

Login to comment on this ticket.