 |
 |
Hi Markus, I think the VO-BOXES details should be discuss at some length at the operations meeting at the end of the month. Is there any documentation available about it? thanks cheers alessandra On Tue, 6 Sep 2005, Markus Schulz wrote: > Dear Alessandra, > > thanks for your input. I'll answer you in more detail later, I just see > the need to comment on the VO-BOX to avoid misunderstandings there. > > I can fully understand that the VO -BOX worries you, the alternative > scares me more. > > The VO-BOX was asked for by the experiments and accepted by the Tier 1s > that participate in the Service Challenge (Ask Jamie Shiers for the > minutes of the meeting). They are not seen as a temporary fix. It is > expected that the experiments will run some VO specific services for the > foreseeable future. > > The VO-BOX as a well defined platform is the only way to handle this in > a somewhat controlled way, this is why we try to expand what is already > there on the VO-BOX. I am convinced that it is more secure to provide > some common services on these boxes and reduce the need for VO specific > components. > > markus > > On Sep 5, 2005, at 9:01 PM, Alessandra Forti // EOJ wrote: > >> Dear Markus, >> >> I like very much the idea of having a release every 3 months with minor >> updates in between, where updates are defined as those changes that do not >> affect the configuration and can be picked up by apt/yum/..... >> >> As far as the list goes from my (sys admin) point of view the priorities >> are as follows: >> >> 1) Any improvement of the robustness of the services. (i.e. 2. 5. 12. 22. >> in your list). >> >> 2) This is not in the list BUT it is important to me: anything that makes >> traceability of a job easier: a tool that for example puts together >> that mess that is in the log files on the CE and RB (god know why there >> can't be a unique JOBID that one can followed through) would be >> extremely useful both from the security point of view and purely for >> maintainance of the system. >> >> 3) I'm a bit worried about the introduction of gLite components all in one >> block. Is this the plan? I played a little bit with VOMS server and >> gLite >> UI and I have to say I find gLite configuration extremely painful. So >> I'm >> not against their introduction, however I don't want to know ANYTHING >> about >> touching those xml files by hand. In other words to me YAIM is a >> priority. >> >> 4) Cleanup of the infor providers to make full use of the new schema >> >> 5) YAIM VO managment I'm interested in having only dteam VO enabled in >> site-info.def. I go through the pain of removing the VOs I don't want >> and to add the one I want. However the latter should be the only action >> required. The WEB based tool you talk about seems eccessive to me. >> If the necessary information about a VO is available it doesn't take >> long to add the VO to YAIM. The most painful part is to find >> that information. However if you really want to create a tool please >> create >> a command line that can be scripted. If you were thinking of browsers >> forget about it. >> >> 6) Removing jobmanager-fork and gridftp on the CE. I can't say I disagree >> from the security point of view, however they are great tools to debug >> the situation other people machines without having direct access to >> them. So I think that a restricted usage policy would be preferable >> than complete elimination. >> >> 7) Security (your 17.) I'm surprised there are not more things listed. >> >> 8) Jeff Templon ETT. I don't know anything about it, hoever I think an >> algorithm (any decent algorithm?) has been waited forever now. >> >> 9) Back up mechanism for mission critical T2 DBs.... I have dcache and >> to be honest tar works perfectly. Up to one year ago it was working >> also with mysql (no need of complicated things). >> >> 10) The other thing that makes me a bit nervous is the progressive >> importance that the VO-BOX seems to be acquiring. I'm not sure if any >> of the sys admin has had any say in this but I'm sure I echo the >> thought >> of many when I say that it shouldn't have been introduced in the first >> place. And even if I accept the introduction of a box to cover for the >> hopefully temporary shortcomings of the middleware, I know by >> experience >> that temporary solutions become permanent. >> >> 11) What about dcache configuration? This also is not on the list. We need >> some sort of configuration tool (YAIM is not of much use for the >> configuration). >> >> The points that I haven't included have a lesser priority for me because I >> haven't installed those particular services and therefore am not affected. >> >> thank you >> >> cheers >> alessandra >> >> On Tue, 30 Aug 2005, Markus Schulz wrote: >> >> >>> Dear ROC, CIC, Site-mangers, and EIS link persons, >>> >>> on July 29th we released LCG-2_6_0. This release is now out since more >>> than 30 days and there are over 69 sites that have been upgraded >>> and several additional where the client libs of 2_6_0 have been provided >>> via the user level software installation mechanism. >>> >>> The release has seen 2 upgrades, mainly related to YAIM problems. >>> >>> On August 3rd we did a local post mortem of the release. A rough summary >>> can be seen here: >>> >>> https://uimon.cern.ch/twiki/bin/view/LCG/LCG-2_6_0 >>> >>> we then started collecting input for "wish list" for LCG-2_7_0, this >>> >> list is >> >>> not complete and not prioritized, just a draft. >>> The list can be seen here: >>> >>> https://uimon.cern.ch/twiki/bin/view/LCG/LCG-2_7_0 >>> >>> Assuming the regular release cycle the release date should be 1st of >>> October. >>> With the time it takes to push the release through the local and remote >>> tests we have to keep in mind that the integration and initial testing >>> phase >>> has to come to an end on Friday the 9th of September. >>> This is rather soon now and we need a better understanding on the >>> relative priorities of the different tasks and additional components >>> that we might need to add. >>> >>> >>> Please have a look at the list and sent me suggestions and describe your >>> priorities. >>> >>> >>> >>> markus >>> >>> >> >> -- >> ******************************************** >> * Dr Alessandra Forti * >> * Technical Coordinator - NorthGrid Tier2 * >> * http://www.hep.man.ac.uk/u/aforti * >> ******************************************** >> > -- ******************************************** * Dr Alessandra Forti * * Technical Coordinator - NorthGrid Tier2 * * http://www.hep.man.ac.uk/u/aforti * ********************************************