1. Peter Chochula ALICE DCS Workshop, October 6,2005 DCS Computing policies and rules

2.  Proposal for the ALICE implementation of CNIC recommendations was circulated  This talk should trigger the discussion during this workshop  Collected feedback will be implemented in the new version of the document which will be then sent to detector teams for approval

3. DCS Computer Categories  Servers (SE) – provide back-end service and are not directly accessible by the users (the Terminal Server (TS) is the only exception)  Worker Nodes (WN) – perform the DCS tasks.  Operator Nodes (ON) – run the user interface and all software needed to operate the detector DCS. There is one ON per detector  Consoles (CO) – computers used by the operator to interact with the system

4. Adding and removing devices to/from the DCS network  Each detector is responsible for adding and removing their devices (other than PCs) to/from the network (mainframes, PLCs, etc.)  The connection request must be made by a responsible person named by the detector (DR)  The request will be authorized by the DCS responsible  Needed web-based tools are released  No wireless connections are expected on the DCS network (wireless connectivity is available on the General Purpose Network)

5.  The detector responsible person must provide following information about each device prior to the connection:  Device name, type, model, MAC address  This data is mandatory for the web-based connection request form  Expected data volumes to be transferred to/from this device and other networked devices which will be accessed  In case of the network abuse (due to wrong configuration, unexpected connections etc.) the DCS responsible is authorized to disconnect the device until the anomaly is solved

6. Purchasing and installation of DCS computers  All DCS computers are purchased, tested and installed (including the network connection and OS configuration) by the DCS team  Windows system is mandatory for all computers running the PVSSII and will be installed using the NICEFC tools  Linux system will be installed on some servers using the LinuxFC tools  Embedded computers and computers part of the FERO might require Linux operating system  Use and installation of such computers requires an approval of the DCS responsible  These computers are under responsibility of the detector team and are considered as part of their FERO sub-system

7. Installation of the applications and drivers  All applications and drivers are installed by the DCS system administrator and detector expert  Standard applications will be deployed using the NiceFC tools  Non standard applications will be installed on detector request  Rules described in the draft document must be followed (long term maintenance, licensing issues, documentation…)

8. Installation of Detector Projects  Detector projects must be first tested in the DCS Lab  Basic tests will include virus scanning, conformity with naming and numbering conventions for critical components (system number, service names, installation paths, software version)  Verified projects will be transferred to the production network via the application gateway  No direct installation fro example from USB sticks or CD-ROMs will be allowed  No application development will be allowed on the production network  Small hot-fixes can be performed, however the project must be backed-up before it is modified

9. Access to the DCS  DCS control actions can be performed only from the ACR  Remote operation is restricted to monitoring  Access to the DCS will be restricted according to user privileges  At operating system level  At PVSSII level – using the framework access mechanisms  The DCS administrator has administrative rights on all devices connected to the DCS network

10. External Internal Remote Access Scheme HTTP, RDP PVSS RDP X11  Authentication against the Terminal Server  Access to an instance of the UI (no Desktop)  Genuine UI controls navigation  JCOP FW handles privileges on the UI  Authentication against the Terminal Server  Access to an instance of the UI (no Desktop)  Separate Desktop access for experts for e.g. PC maintenance  Operator UI never disturbed PVSS, RDP, X11