Create operations role without Admin privilege for operations scripts

[ericvaandering]

Original Savannah ticket 83989 reported by magini on Tue Jul 5 07:54:53 2011.

BlockDownloadVerify-injector.pl cannot inject tests with the Prod/Writer account, it needs Prod/Admin, apparently. It would be good to fix this, so Admin privilege is not needed.

[ericvaandering]

Comment by magini on Tue Jul 5 08:09:22 2011

Hi Tony,

This is incorrect - BlockDownloadVerify-injector.pl works with the Writer account using an appropriate site role like Prod/CERN e.g.

+verbatim+ : PHEDEX/Utilities/BlockDownloadVerify-injector.pl -db SITECONF/CH_CERN/PhEDEx/DBParam:Prod/CERN -block /mUED_KK1ToZZTo4L_invR-300_7TeV-herwigpp/Spring10-START3X_V26-v2/GEN-SIM-RECO#aef18c76-6c0a-4c98-b3d0-457049955f60 -test size -node T1_ES_PIC_Buffer -force 2011-07-05 13:06:21: BlockDownloadVerify-injector.pl[7152]: (re)connecting to database Preparing for 1 test-insertions Insertions remaining: 0 All done... -verbatim-

It is in fact intentional: permissions for Prod/Writer without a role are set to read-only so that we can have at least an idea of who performed a DML statement if necessary.

Some other operator scripts (e.g. FileDeleteTMDB), however, still need the Prod/Admin account because they need to update tables which are read-only for all site roles.

In this case, instead of making the tables writable for the Prod/SITE role, it would be more appropriate to create a new Prod/OPERATIONS role with write privilege on most/all tables but no admin privileges.

I have updated the ticket subject accordingly.

Cheers Nicolo'

[ericvaandering]

Comment by magini on Tue Jul 5 12:31:40 2011

Hi Tony,

actually - looking at the DB, the Prod/CERN should have full write privileges on all tables in the DB.

If this is the case, it shouldn't be necessary to create an additional role for OPS, the operators can use the CERN role.

We could still create OPS roles to distribute outside of CERN for operators who don't have access to the PhEDEx vobox at CERN.

Cheers Nicolo'

[ericvaandering]

Comment by wildish on Wed Jul 6 02:15:35 2011

OK, so a */Ops role does seem useful. It occurs to me that another option is to re-write the BlockDownloadVerify-{inject,report}.pl scripts to use the data service internally, then they have no need for a connection parameter at all.

We can restrict the injection API to the appropriate roles in the data-service, though for test injection we may not want to restrict it at all? Or we could restrict the priority range allowed to 'normal' users, so Ops and Admins can always trump them by injecting tests with higher priority? Or restrict site-roles to inject only at sites the person administers, like for transfer subscriptions?

I don't think we have an API for test-injection at the moment, but it won't be hard to provide one.

If we go this route then we should scrap the BDV-{report,inject}.pl scripts completely, and incorporate the functionality into Utilities/phedex, the data-service CLI. By providing a 'Report' method to the CLI modules for the BDV tests we can retain this same functionality, or enhance it. Then we have fewer tools to maintain.

What do you think?

[ericvaandering]

Comment by wildish on Thu Jul 21 04:45:33 2011

Reassigning to Nicolo, since he is taking care of creating the role.

If any further work is required (BDV API or tools) we should open a separate ticket for that.

[ericvaandering]

Comment by magini on Wed Nov 9 09:08:19 2011

Hi,

the OraclePrivs.sh script was updated in PHEDEX_4_0_1 to handle the creation *Ops roles. Note that the operators who requested the role have been granted the role in Dev several months ago for testing, but never came back to request the role in Prod...

Closing N.

[ericvaandering]

Closed by magini on Wed Nov 9 09:08:19 2011