Experiments views on IT services

1. Experiments views on IT services An opinion based on experience from Aleph and wishes from LHCb (and a brief discussion with CMS) http://alnts1.cern.ch/~cattanem/LHCb/IT-forum.ppt

2. Scope of the talk • Communication between IT and experiments • contact persons • help lines • Some comments about some general services • User registrations • Network • WWW • PC hardware and software support • No mention of Unix services (Helge) • Software documentation and training

3. Communication • Our experience with our contact person is excellent • Single point of contact with IT services • Understands our requirements and discusses them in IT • Ensures our requests are followed up • Informs us and guides us in our decision making • Ultimate customers are the physicists • They will rarely give requirements at the right time • “You should have told us a year ago” is not an acceptable reply • They will not read specialised web pages, newsgroups etc. • Avoid: “This announcement has been on the web for two months” • Contact person should be used by all IT groups and should exist for all experiments • Requests for information • Discussion of future directions (e.g. mobile computing) • Announcements of service changes • Contact person knows experiment well enough to recognise problems

4. Help lines • Xxx.support mailing not ideal • Automatic response is useless - of course mail has been received! • Too impersonal - no idea who is following the problem • Too slow - physicists want their problem fixed by yesterday • Too specialised - often problems span more than one list • Who do I contact if I can’t print from my PC? • Who do I contact if my home page fails to load? • Exceptions are experiment.support lists • Can be used for a wide range of problems, read by real experts • Fast response (contact person ensures this) • Follow-up via regular IT-experiment meetings • Suggestions: • One single user.support list, dispatching done by UCO • Reply to mail with name of person looking at the problem • Prompt and personal contact is very important to physicists • Use newsgroups instead of specialised lists (e.g. cern.Linux, cern.heplib) • Read by experts also outside CERN - reduces support load at CERN?

5. User administration • User registration • Delegation to group administrators works well • Initial step by internal mail is slow. G.A. could verify form is signed • Users need accounts in several groups (but single username) • Space administration • Unix: space is administered by groups with (almost) complete freedom (300MB AFS limit?) • NICE: not enough freedom, defaults and increments are too small • Password policies • Synchronisation of passwords on NT and Novell is a lottery • If Novell password expires, it is often too late! • AFS: • Passwords do not expire (why OK on AFS and not on PC?), • Daily expiry of AFS token is a pain, why is it needed? • There should be a single policy at CERN across all platforms • What is a valid password? • How often should it be changed? • Why can’t group administrators reset passwords?

6. Internal network • Significant fraction of CPU power is on desktops • Cannot be used for data processing due to network limitations • Video Conferencing will come to the desktop • Star points should have 100-BaseT connectivity to Gigabit backbone • Experiments could contribute to average cost of individual connections • Reports of excessive traffic are useful. • Need more help in fixing faulty systems • Publish statistics of traffic by star point service

7. Internet abuse • No CERN policy on acceptable Internet use • Any policing of Internet use is an invasion of privacy • Blocking of certain sites is censorship • CERN management MUST issue a policy statement • Is it legal to look into private .netscape cashes (or mail)? • Who is responsible? What are the sanctions? • I refuse to follow up reports of abuse without such a policy. • Software to block dubious sites would be most effective solution • Enhance filtering of spam • Mailing lists could accept postings only from members of the list • How do we report/complain about spam? • A CERN newsgroup should: • Have a person responsible who can/will delete spam • Be removed if it has become obsolete • Accept postings only from the HEP world

8. WWW support • Many experiments have their own web server • Easier to organise content • e.g. support for tools such as FrontPage • Easier to manage protections • e.g. Aleph uses Unix file system protection • Faster and more reliable access • Access to wwwinfo is often slow, downtime not co-ordinated with experiments • Local user support and bug fixing • Space administration completely under experiment control • (Large) experiments make little use of Web Office • Guidelines and styles are unworkable • Divisional Webmasters inappropriate for large experiments • Duplication of home page servers • home.cern.ch, nicewww.cern.ch, alephwww.cern.ch….. • Some scope for rationalisation?

9. PC shop • Major improvement in PC purchasing in last year • BUT: delays can still be too long • Inform of delays at time of order (and pay on delivery…) • Keep a small stock (alternative is stock in experiments) • For desktop use, last season’s PC is good enough • Some greater flexibility in configuration is desirable: • Memory options, internal disk size • Pre-installed dual boot WNT/Linux • Plus CERN standard environment (NICE-NT, AFS client etc.)

10. Support for WNT • NICE model is suited to the administration sector • Standard configuration • Limited set of standard tools used in a standard way • PC is a “black box”, software updates should be transparent • Some info on what will be updated, ask if update “now” or later • Physicists have different requirements • Need different kind of tools • Compilers, code repository, development environment, design tools, web authoring and management tools, software libraries • Tools need local configurations • e.g. LHCb configuration of VisualStudio, Rational Rose, FrontPage, even Exceed • Stability is essential • Results must be reproducible • Changes to software versions (even bug fixes) have to be controlled by experiment • Scheduling of server maintenance is an issue

11. Requirements for NICE-NT • NICE-NT could be a service entirely decoupled from NICE, addressing physics requirements • Local servers with SELECTIVE mirroring of central software • c.f. ASIS • Bugs in current mirroring software (open files not mirrored) • Possibility of SELECTIVE updates of individual applications • On the local server, driven by the group • On the individual PC, driven by a developer • Configuration of selected tools on local server • No update of registry entries by NICE • I want to keep MY Netscape settings (Ghostview vs. PSVIEW) • I want to use MY set of Netscape plugins

12. WNT home directories • General agreement that Novell inadequate • Home directories can be centrally managed if: • All users from a group can be in one folder • Sufficient space is allocated • > 100 MB /user, allocations under group control • Service interruptions are agreed with group • Network bandwidth is sufficient Alternative is home directories on local server

13. AFS vs. NTFS • AFS has many nice features • Accessible worldwide and across platforms • ACLs allow great flexibility in security policies (c.f. NTFS) • Excellent availability, failover (also possible in NTFS) • Quotas (eventually in NTFS?) • BUT: • Full functionality of WNT applications not guaranteed • e.g. Developer Studio file synchronisation doesn’t work. FrontPage? • Future PC applications may need in-house workarounds • c.f. Netscape 4 user configuration parameters on NICE • Password synch. for the two authentication schemes is difficult • c.f. current mess of Novell and WNT synchronisation • AFS not cheaper than NTFS • Aleph NT server: 480 CHF/GB, AFS: 692 CHF/GB • We believe AFS would be an unnatural choice • AFS should be used where sharing with Unix is needed • e.g. source code repository

14. Printer support • Hardware support • Purchasing and installation service is excellent • Regular maintenance should be organised centrally • Printing service • Does a central printing service make sense with PCs? • Any given group only uses a handful of printers • Why go through a single remote server? • Relevant printers can be installed on local NT group servers • Local management • Need to limit access and/or monitor usage • Important to limit abuse of e.g. transparency printers • Need printer access from portables without NICE

15. Software support • IT should support software development on both Unix AND WNT • Design Tools (e.g. Rose) • Development environment (e.g. Visual Studio, (emacs?) ) • Compilers (e.g. Visual C++, gcc) • etc. • What does support mean? • Standard CERN environment (c.f. SUE, HepiX) • Licences • Configuration and integration of tools • Examples, short user guides • Integration of CERN software packages: • Standard installation of LHC++ • makefiles and code examples that work with e.g. Visual Studio • Fully functional, working, installed data analysis example • Using all the ingredients of the LHC++ strategy • Training and assistance: coordinating role

16. Software documentation • IT search and view on WWW • Powerful tool, much more selective than CERN-wide search • Difficult to find in CERN web: CERN > Computing > IT • Only as good as the indexing: • Search string: “Bessel Function” • C309 CCLBES • C312 BESJO • etc. (9 CERNLIB entries in total, all relevant) Where are the C++ equivalents? • Search string: “Histogram package” • HBOOK manual • HIGZ manual Where are HistOOgrams? • Search string: “Hep3Vector” • Not Found • Search string “HEPODBMS” • Not Found • We need XFIND for (LH)C++ !!

17. Training • Physicists need to be convinced about formal training • They will never go to a seminar about the mailserver • They MAY go to a Visual Studio seminar if they know they will use it tomorrow • They WILL try to learn from examples • IT should provide tools, documents, code-examples for self-teaching • easily usable also outside CERN • Roadshows and Workshops are also useful • To be effective, formal training should be: • Just in time • Focused on physics needs • Hands on • Our approach: • Organise for LHCb courses from the Education Services catalogue • when we think the time is right • IT could complement these courses with CERN specific examples • e.g. LHC++ examples inside Visual Studio • Integrated in the course, or as a correctly timed seminar • Tutorials focused on physics needs could be well attended

18. Conclusions • System of contact persons works well and should be developed • Operating system and software support for WNT should be put on same footing as current Unix support • Much work is needed to provide documentation and examples to make CERN software environment usable by the average physicist • Treat physicists like children: listen to them, understand their needs, and try to steer them in the right direction without them realising

19. And realise you will never succeed…