Participants:
Vincenzo Ciaschini (on the telephone), Maria Dimou, Joni Hahkala, Tanya
Levshina (on the telephone), Karoly Lorentey, Ian Neilson, John Weigand
(on the telephone).
Apologies: David Kelsey.
Agenda:
1. Comments on the previous meeting's notes
http://cern.ch/dimou/lcg/registrar/TF/meetings/2005-01-18 - All
2. Discussion on versions with the participation of Gabriele Carcassi
BNL-USATLAS.
I haven't invited Gabriele, yet, for this item in the agenda, so, if you
disagree, please say so, a.s.a.p. I would hate to end-up with more than
one VODBs for the Atlas VO due to incompatibility with other packages (see
attachment). But, as we have a full agenda, I can organise a separate
meeting on this, if you prefer.
3. ORGDB link progress and testing plan. - Karoly and Tanya
4. Re-review the plan for ORGDB information linking and LHC VOs'
transition to VOMS/VOMRS. - Ian, Karoly and Tanya
5. Action list review - All
6. A.O.B.
7. Select date for next meeting (how about 22/3 @ 16hrs?)
The notes were accepted.
The Atlas VO managers was not invited because the TF didn't comment on this suggestion. The discussion on CERN VOMS server usage by USATLAS was left probably for a separate meeting. Maria explained the motives for suggesting this item in the first place:
Atlas is configured and populated on the CERN VOMS servers https://voms.cern.ch:8443/edg-voms-admin/atlas and https://lcg-voms.cern.ch:8443/edg-voms-admin/atlas. At this moment, this is the set of software versions we are running on these hosts:
- edg-voms-admin v0.7.6-1, server side is v0.7.6 by K.Lorentey from Budapest
- edg-voms Version: 1.3.7, Compiled: Feb 4 2005 14:41:46
- edg-mkgri
- Globus as packaged in VDT1.2.0rh9 (Globus 2.4.3 + patches).
- edg-voms-admin v0.7.3, server side is v0.7.6 by K.Lorentey
- edg-voms Version: 1.3.1, Compiled: Feb 4 2005 14:41:46
- edg-mkgri
Gabriele Carcassi (USATLAS VO Manager) at BNL, runs a very recent version of VDT (1.3.2?), with something like Globus 3.2.1. due to OSG and GUMS requirements, which at present doesn't work with voms Version 1.3.7 (version number on LCG CVS). VDT 1.3.1. is promising to have no inter-working problems with this voms server or client.
As Karoly explained "it is of utmost importance that the VOMS servers for LCG VOs remain compatible with the VDT version used currently by the entire LCG infrastructure. If Globus 3 (GT3) is not compatible with 2.4.x, and this causes problems for LCG VOMS clients, then we can not use it on our servers until the whole LCG project migrates to it."
Karoly is testing, at the moment whether GT3 is indeed the cause of our interoperability problems. John will check and inform us on the exact VDT release that works with voms 1.3.7. Before writing this notes, this was announced at the Middleware Security Group Meeting. The version is VDT 1.3.1. Vincenzo said that, if there is any inter-operability problem, then, this is a bug and should be entered in savannah (see ACTION 2005-02-22--1 in the action list).
Tanya and John can't test VOMRS due to lack of persmission from the ORGDB responsibles to access the data. This is a show stopper. Maria had sent the following message to Ian Bird:
Date: Fri, 18 Feb 2005 09:32:46 +0100 (CET)
From: Maria Dimou-Zacharova <dimou@mail.cern.ch>
To: Ian.Bird@cern.ch
Cc: karoly.lorentey@cern.ch, ian.neilson@cern.ch, tlevshin@hppc.fnal.gov,
d.p.kelsey@rl.ac.uk, joni.hahkala@cern.ch,
vincenzo.ciaschini@cnaf.infn.it,
weigand@fnal.gov,
valerio.venturi@cnaf.infn.it
Subject: Re: Access policy clarification on foundation database (fwd)
Dear Ian,
We have a problem to get Tanya and John (FNAL) accessing ORGDB for VOMRS
integration testing. Their status in the database is EXTernal. On the
other hand Karoly is not 'Staff' either. Maybe this is why we are waiting
for 6 months for the permission to access Date_of_Birth.
We need a legal solution to discuss at the coming TF meeting on 22/2.
But maybe asking for permission from the HR dept. Head is the cleanest.
At the end of the day, there will be a service and not an individual
accessing the ORGDB data (Foundation is the name of a view in CERN HR db)
but we can't do what the GDB mandated us without access to the data.
Please advise.
Thanks and regards
- maria
and asked him to give some priority to this. Ian forwarded the request to Les Robertson. By the time these notes are written the following mail was sent by Maria, in response to Les' suggestions for testing:
Les: Am I right in thinking that the operational use needs the date of birth to match the people (name+affiliation+date_of_birth) - so the matching algorithm would receive a date of birth from the user/administrator and query the database to check the match? Maria: The actual matching will only be done on the email address value, which is public information, one can see it in http://consult.cern.ch/xwho from all over the world. The person's name and experiment affiliation are also there, so, no problem to access this type of information. Our proposal to the GDB section 4b requires the user to enter on the registration form: " The CERN_ID appearing on the CERN badge , if he/she knows it. Alternatively the birthdate." This information will not be stored in the VODB or in the logs. Just the indication that a successful match was achieved.The reason why we suggested this is to strengthen the hope:-) of the VO manager that the person is the one (s)he claims to be. Les:The HR person proposes that an extract of the data is created with fake dates. Can the testers give the same fake dates for initial testing? Maria: You are, probably, right. I copy the developers and we'll discuss it amongst us. I promised to send them a file with Experiment/FamilyName/GivenName/Email to start with.
Remaining problems in summary:
The VOMRS developers received indeed the ORGDB link modules written by Karoly but can't do any testing because of the permission problems explained above. This new obstacle from the ORGDB responsibles makes it impossible to finish the project within the deadlines. It seems that despite the numerous meetings and emails we exchanged with them starting with http://cern.ch/dimou/lcg/registrar/TF/InitialQuestions.txt on 21-Apr-2004 the message of what we are trying to do didn't get across. Important dates in the near future:
Tanya will be on holiday for about 10 days and testing will resume around March 9th, initially based on the file that Karoly/Maria will provide with Experiment/FamilyName/GivenName/Email data in text columns.
After this test the VOMRS developers will put the VOMRS rpms in the LCG operations CVS (see action). Maria will install it on a SL3 host with appropriate connectivity, e.g. our present RH7 VOMS server after doing the following:
At that point the VO managers will be called to get experience with VOMRS (with or without ORGDB support). Maria will be away 25/3-4/4 Easter. Karoly leaves mid-April.
(*** ACTION 2004-09-17--1***) On Ian's suggestion Maria will create 3 savannah tickets containing all the existing VOMS/VOMRS-related tickets across groups per category (Major, Normal, Enhancements). PARTIALLY DONE: The VOMS/VOMRS savannah summary page is now cleaner but present savannah search doesn't allow to select the 'severity' attribute value (even for display) across groups (lcgoperation OR jra1 OR jra3). Maria investigating with the savannah expert.
(*** ACTION 2004-09-17--2 ***) Ticket
860: Maria closed this ticket with Karoly's anwer. She opened ticket
1185 to describe the task of defining what to store on user's CA information.
Please
read the tickets for details. Tanya: VOMRS
should also store the user certificate serial number and his/her CA's contact
URL.
Details by Tanya:
In
VOMRS DN, SN and CA of the user certificate are stored in log file (when the
level
is set INFO),it is recorded every time a user contacts VOMRS. SN is also collected
and stored in database during user initial registration. A member can add certificate's
SN when requesting addition of a new certificate into VOMRS. VO administrator
can put user's SN during initial registration and certificate addition. This
information
is optional. We decide to have a placeholder in case the requirements changes.
DONE. To be removed after the next meeting.
Ticket
1132: (*** ACTION 2004-09-17--3 ***) Tanya will
make the necessary changes so that newly registered VOMRS users don't receive
2 almost
identical emails when they pass from status "New" to "Approved" in
the VO. By
this date, Maria
completed her action on making sure VOMRS notification emails will never fall
into spam again. She informed the TF by email on the reasons and the solution
(whitelisted the string "VOMRS" at the CERN central email
gateway level).
DONE. To be removed after the next meeting.
(*** ACTION 2004-09-17--4 ***) Tanya should
re-open the savannah
ticket
1141 if a more user friendly error message can be envisaged by the VOMRS
developers in case of expired user certificate.
Details by Tanya:
I have no clue how to do for now. It is interesting that VOMS admin
(0.7.5 ) behaves absolutely identical on our host (edg trust manager version
is
1.5.6). Any help is welcome.
Comments by Maria:
I had submitted
that ticket originally because VOMRS was telling me "Cannot find Server" which
didn't help me at all to guess that my certificate might have expired. If voms-admin
and vomrs can find a way to present a text listing possible reasons of failure,
including possible certificate expiration, it would be great.
PENDING
(*** ACTION 2004-09-17--6***) Tanya will enter in the savannah
group lcgoperation the bugs she has observed. Example: Simultaneous "commit"
of changes via the User Interface and the VOMS db API causes the db tables
to go out of
sync. This is, most probably not a database problem but an application
problem of voms-admin.
This problem may have gone away with the latest release. Maybe
close this action after the next meeting?
PENDING
(*** ACTION 2004-09-17--7 ***) Recommend to CERN IT Management
on information quality improvement for CERN HR db. (*** ACTION
***) Maria. (Maria feels this can only be done
when the ORGDB content quality is fully understood but Ian in the 2205-01-18
meeting recommended that we move ahead with this action already now).
PENDING
(*** ACTION 2004-09-17--8 ***) The ORGDB view with the necessary
and sufficient Personal User data, according to the Requirements' definitions
may need to be tailored according to experiments'
rules Karoly and Maria to investigate and
inform the TF.
PENDING
(*** ACTION 2004-09-17--9 ***)Maria will
test VOMRS and make available to the TF a list of features. By the time
these notes are written, Tanya announced mid-December 2004 the pre-alpha
version https://hotdog62.fnal.gov:8443/vo-LCG/vomrs for
testing.
PENDING
(*** ACTION 2004-09-17--10 ***) Tanya expressed worries that
US-CMS users won't accept to type their birthdate, even if it is only DDMM
(no year) and
even if it is not logged in clear, simply a string saying that it was provided.
She also said they might be reluctant to register in CERN HR db,
even
if this is LHC experiment policy. She should give the TF feedback from discussions
on this matter with her community.
PENDING
(*** ACTION 2004-09-17--11 ***) Maria create savannah ticket for VOMS admin and VOMRS to set Return-email-address to the one of the VO manager for user notifications that can't reach the recipients. PENDING
(*** ACTION 2004-09-17--12 ***) TF to re-discuss the Usage Rules re-acceptance prompt in more detail. PENDING
(*** ACTION 2004-09-17--13 ***) LCG deployment management has to plan for VOMS admin software maintenance continuity after Karoly's departure from CERN in April 2005. LCG/EGEE management has to plan for EDG trust manager support continuity after Joni Hahkala's departure from CERN. PENDING
(*** ACTION 2004-09-17--14 ***) Ian should investigate with the LCG Deployment management whether resources could be found elsewhere in the community to assist Tanya in the VOMRS development work. CLOSE after John's assignment to VOMRS development?
(*** ACTION 2004-10-28--1***) Tanya to make a UML diagram in addition to the VOMRS Registration Process flow and to the VOMRS_new_req document they prepared with John.
(*** ACTION 2004-11-29--1***) Karoly to make available a sceleton of Classes for VOMRS developers to use when interfacing to the ORGDB.
(*** ACTION 2004-11-29--2***) John and Tanya to submit in savannah (project=lcgoperation) the problems they mentioned at the meeting related to voms-core code when using "voms-proxy-init" and anything else they want to report to the developers. Savannah is the communication medium that helps the TF check where we stand in the process. All, please close tickets when actions done.
(*** ACTION 2005-01-18--1***) John and Tanya to update their CA management paper.
(*** ACTION 2005-02-22--1***) Karoly to test whether GT3 is the cause of interoperability problems between what USATLAS uses and what the CERN VOMS server offers. John to check and inform us on the exact VDT (1.3.1.?) release that works with voms 1.3.7. Vincenzo said that, if there is any inter-operability problem, then, this is a bug and should be entered in savannah. Details in the notes of the 2005-02-22 TF meeting (section 2).
(*** ACTION 2005-02-22--2***) Action list clean-up by people actioned and savannah tickets' clean-up by ticket submitters.
(*** ACTION 2005-02-22--3***) VOMRS developers to put the
VOMRS
rpms (no binaries!) after test completion (mid-March 2005?) in the LCG operations
CVS. Maria sent their afs login id to Louis.Poncet@cern.ch.
Louis created a directory called 'vomrs' under "Auth" in
our (lcgware) CVS. To navigate via http://cern.ch/grid-deployment,
select "CVS development". Here
is the CVS documentation and the
developer's guide.
PENDING
(*** ACTION 2005-02-22--4 ***) Tanya and John to install
VOMRS on a FNAL SL3 host. Information on SL3 can be found Here.
PENDING
The next meeting will be held on 22 March 2005 at 16hrs.
Maria Dimou, IT/GD, Grid Infrastructure Services
