Page MenuHomePhabricator

Requesting access to analytics-privatedata-users for Michael Raish (Design Strategy)
Closed, ResolvedPublic

Description

  • Wikitech username: @MRaishWMF
  • Perferred shell username: mraishwmf
  • email address: mraish@wikimedia.org
  • Ssh public key: AAAAC3NzaC1lZDI1NTE5AAAAIPGHf38YCudGpCo+M+j6y+CDMOztRcd3Tv/Ze8KkrZg+ mraish@wmf2838
  • Requested group membership: analytics-privatedata-users
  • Reason for access: I'd like to view Superset dashboards showing metrics of interest to an ongoing Growth team investigation into IP editing.
  • Name of approving party: @AChang_WMF
  • I have signed the L3 Wikimedia Server Access Responsibilities document.

Event Timeline

@odimitrijevic @Ottomata are you happy for this request to be approved?

Also observe this note on wikitech: "Note to SREs granting this access: This can be done by declaring the user in Puppet as usual, but with an empty array of ssh_keys. ". If this request is for a dashboard only should we follow that advice, and not include any SSH public key?

@MRaishWMF Hi. We have noticed that there are two LDAP accounts in your name currently.

Your original account was set up in Sept 2020 - username "mraish".

Seems that when you had the access to Superset granted in April 2021 a new account was set up (when we rather should have added this access to your existing one). Username for the newer account is "mikeraish".

I think the best way forward is to remove your original account - "mraish" - which is registered against your gmail email. And then add this new access to the more recent one (mikeraish). Should clear up the confusion for any future requests. Does that sound ok?

Hi @cmooney , thatnks for noticing that. Yes, the 'mraish' account was set up when I was still contracting, and I set up the 'Mikeraish' when I converted and linked to my wmf email. It would be great to remove the original 'mraish' account and add access to 'Mikeraish' as you suggested. I just signed in to the old account looking for a way to delete it, but I wasn't able to find one, however. Should this deletion ideally come from your end or from mine?

Thanks for your help with this!

@cmooney yes, I think an account in analytics-privatedata-users with no ssh keys makes sense here.

Approved.

Hi @cmooney , thatnks for noticing that. Yes, the 'mraish' account was set up when I was still contracting, and I set up the 'Mikeraish' when I converted and linked to my wmf email. It would be great to remove the original 'mraish' account and add access to 'Mikeraish' as you suggested. I just signed in to the old account looking for a way to delete it, but I wasn't able to find one, however. Should this deletion ideally come from your end or from mine?

We don't to remove the old account, we can simply strip the NDA-relevant group memberships from it.

Change 721339 had a related patch set uploaded (by Cathal Mooney; author: Cathal Mooney):

[operations/puppet@production] Grant access to anlytics-privatedata-users for Michael Raish

https://gerrit.wikimedia.org/r/721339

Change 721339 merged by Cathal Mooney:

[operations/puppet@production] Grant access to anlytics-privatedata-users for Michael Raish

https://gerrit.wikimedia.org/r/721339

Ok @MRaishWMF the additional access should now be set up for account 'mikeraish' if you can try and let me know if it's working as you need?

thanks.

Hi @cmooney , I'm still getting the following error message when logged in and attempting to access a particular dataset that I'm interested in:

Permission denied: user=mikeraish, access=EXECUTE, inode="/user/hive/warehouse":hive:analytics-privatedata-users:drwxr-x--- at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.check(FSPermissionChecker.java:351) at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkTraverse(FSPermissionChecker.java:311) at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:238) at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkPermission(FSPermissionChecker.java:189) at org.apache.hadoop.hdfs.server.namenode.FSPermissionChecker.checkTraverse(FSPermissionChecker.java:541) at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkTraverse(FSDirectory.java:1705) at org.apache.hadoop.hdfs.server.namenode.FSDirectory.checkTraverse(FSDirectory.java:1723) at org.apache.hadoop.hdfs.server.namenode.FSDirectory.resolvePath(FSDirectory.java:642) at org.apache.hadoop.hdfs.server.namenode.FSDirStatAndListingOp.getListingInt(FSDirStatAndListingOp.java:55) at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getListing(FSNamesystem.java:3660) at org.apache.hadoop.hdfs.server.namenode.NameNodeRpcServer.getListing(NameNodeRpcServer.java:1147) at org.apache.hadoop.hdfs.protocolPB.ClientNamenodeProtocolServerSideTranslatorPB.getListing(ClientNamenodeProtocolServerSideTranslatorPB.java:671) at org.apache.hadoop.hdfs.protocol.proto.ClientNamenodeProtocolProtos$ClientNamenodeProtocol$2.callBlockingMethod(ClientNamenodeProtocolProtos.java) at org.apache.hadoop.ipc.ProtobufRpcEngine$Server$ProtoBufRpcInvoker.call(ProtobufRpcEngine.java:507) at org.apache.hadoop.ipc.RPC$Server.call(RPC.java:1034) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:1003) at org.apache.hadoop.ipc.Server$RpcCall.run(Server.java:931) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1926) at org.apache.hadoop.ipc.Server$Handler.run(Server.java:2854)

Ok thanks for the quick feedback. Not 100% why that might be I will double check with those more experienced than I and try to get it sorted.

Hi @cmooney , actually I just checked again (80 minutes later) and I actually do have the access I need now. Maybe it took a while for everything to fall into place? Thanks a lot for your help with this!

Hi @cmooney , actually I just checked again (80 minutes later) and I actually do have the access I need now. Maybe it took a while for everything to fall into place?

That's expected yes :-) The change gets applied by Puppet gradually on each server of our Hadoop cluster and since Puppet runs every 30 mins (but at a different time for each server), it takes half an hour to be fully applied.

Ok @MRaishWMF thanks for confirming!

And @MoritzMuehlenhoff that indeed makes sense, I'll delay a little before responding after processing any similar requests in future. Thanks.

cmooney triaged this task as Medium priority.