About cepro00 - here is what happened. When we moved outside the
College firewall and changed domain name we kept cepro00 around to mop
up the bits and installed fresh machines outside the firewall. Then
the machine was renamed (ceprod00old) and turned off after we were
sure that the new machines were working OK. Recently we had a couple
of power blips and after the last one, some helpful soul turned on
every last machine in the machine room, so that cepro00old which still
had a barely valid cert for cepro00 on it said 'hello world'.
While I agree that I should have probably removed the cert, it wasn't
an issue as the machine was off (and is off again until we actually
need it for something else).
My objection to the whole procedure is that
a) nothing dteam does is time critical
b) the person most likely suffering from an out of date dteam setup is
the site admin.
Other VOs have updated their VOMS server without all the drama. The
procedure goes as follows:
1) Send out an email: VOMS server has change, old server will be
turned off at [date].
2) 7 days before, send out a reminder: We meant it folks !!
3) Turn off voms server. Then (and only then) when dteam member A
can't access dteam member's B machine, they can file a ticket.
Who care if there is some UI out there which queries both CERN and the
Greek servers as long as it's working ???
I cannot "just run yaim" on a live production service for something as
minor as the dteam VOMS change, I'd be out of a job and rightly so.
Daniela
On 12 January 2011 19:22, Steve Traylen <[log in to unmask]> wrote:
> On Wed, Jan 12, 2011 at 5:54 PM, Daniela Bauer
> <[log in to unmask]> wrote:
>> I am sorry, but I still can't take this seriously.
>> For Imperial in the update from today they list ceprod00.hep.ph.ic.ac.uk
>
> From today:
>
> INFO 2011-01-12 14:28:09,976 [http-8443-Processor89]
> operations.BaseVomsOperation - Operation: ListMemberNamesOperation([])
> - ([log in to unmask],/C=UK/O=eScienceCA/OU=Authority/CN=UK
> e-Science CA) -
>
> you have a phantom...... Of course it could be another host/thing with
> the wrong certificate.
>
>
>> This machine was decommissioned months ago, it hasn't been in the
>> bdii/GOCDB for months and most importantly it's off. How can they
>> claim they tested it ?
>>
>> Daniela
>>
>> On 12 January 2011 16:50, Stuart Purdie <[log in to unmask]> wrote:
>>>
>>> On 12 Jan 2011, at 16:22, Govind Songara wrote:
>>>
>>>> Hi Jermy,
>>>>
>>>> RHUL installed new VOMS on Dec 15 and there are also old cern dteam voms.
>>>> I think that could be reason, we or other sites still query cern voms.
>>>>
>>>> Here also says that
>>>> "Note that CERN VOMS servers are to remain in the site configuration during this transitional phase"
>>>> https://wiki.egi.eu/wiki/Dteam_vo
>>>>
>>>> Could you please check if we need to remove the old cern voms.
>>>
>>>
>>> I raised this in the EGI Operations meeting, and the answer is: Yes; from places, and no from others.
>>>
>>> The VO_DTEAM_VOMS_SERVERS attribute in site-info.def must contain only: vomss://voms.hellasgrid.gr:8443/voms/dteam?/dteam/
>>>
>>> The VO_DTEAM_VOMSES atribute may contain the CERN ones as well.
>>>
>>> VOMS_SERVERS is used to build the gridmap, whilst VOMSES is used for generation of the voms attributes.
>>>
>>>
>>> It's horrible, but that's the desired behaviour.
>>
>>
>>
>> --
>> -----------------------------------------------------------
>> [log in to unmask]
>> HEP Group/Physics Dep
>> Imperial College
>> Tel: +44-(0)20-75947810
>> http://www.hep.ph.ic.ac.uk/~dbauer/
>>
>
>
>
> --
> Steve Traylen
>
--
-----------------------------------------------------------
[log in to unmask]
HEP Group/Physics Dep
Imperial College
Tel: +44-(0)20-75947810
http://www.hep.ph.ic.ac.uk/~dbauer/
|