The DCS Computing Networking Remote access, Security

1. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The DCS ComputingNetworkingRemote access, Security

2. Peter Chochula, DCS Workshop Geneva, February 28, 2005 • This talk combines several topics • The DCS computing architecture is based on detector feedback, taking into account many external factors • the overall ALICE online architecture • space/financial constraints • Offline requirements • External developments – CNIC • We need to be restrictive in several fields, however we make an effort to provide alternative solutions • We depend very much on your feedback and cooperation

3. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The DCS Computing • Three main phases • Prototyping • Pre-installation • Final DCS • We are entering the Phase II (pre-installation) now • A transition period is (and will be) needed in order to adopt to the new conditions • Our aim is to make this smooth and transparent as much as possible

4. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The Computing prototype • Installed in the DCS lab • Test setup consist of the • Terminal server / gateway • Domain Controller • Database server • File server • Computing infrastructure worker node

5. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Server Prototypes Primary Domain Controller Database Server Application Gateway / TS File Server Infrastructure Worker Node

6. Peter Chochula, DCS Workshop Geneva, February 28, 2005 DCS Server roles – the DC (1) • Domain Controller – the hearth of the DCS computing • The master of the active directory • Stores and manages accounts (users and computers) • Manages and deploys the group policies • Provides services to the domain (time service, authentication...) • The DCS domain is called “alidcs.cern.ch”

7. Peter Chochula, DCS Workshop Geneva, February 28, 2005 DCS Server roles – the DC (2) • The DCS DC provides additional services to the domain • The DNS , domain name service (both fixed and dynamic (assigned via DHCP) addresses are available) • TFTPD , e.g. for CAEN firmware updates • SUS ,software update services • IIS, web services for the domain • DIM DNS • MBSA – baseline security ana;yser • Note: some of the services will run on dedicated servers (computing infrastructure worker node) in the final system • Due to its vital role to the DCS redundancy is needed • the DC will consist of the primary and secondary server in the pre-installation environment

8. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The Terminal Server • The TS provides remote access to the DCS network • Users need to login to the TS in order to gain access to the DCS computers • No direct connectivity from outside • All software must be downloaded through this server • The TS acts also as gateway (SUS need access to the internet) • The ISA server (Internet Security and Acceleration) controls the communication with external networks (e.g. Web proxy for SUS) • IDS – intrusion detection system check all packets passing through the gateway • In the future we might consider to run a NLB cluster of W2k3 servers

9. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The database server(s) • Provides local configuration data • Framework configuration • FERO configuration (shared with the DAQ) • Provides RDB archiving • In the final system (or later during the pre-installation phase) the database will be distributed to several machines

10. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The File Server • Provides additional disk space for the database server (e.g. for offline archives) • Provides disk space for sub-detectors (project backups, temporary disk space for calibration data…) • Runs SFU (Services for Unix) – to integrate the Linux machines (e.g. disk space sharing, common authentication…) • The file server runs W2k3 Server, in the future we are considering the use of Windows Storage Server – stripped version of the W2k3 Server system)

11. Peter Chochula, DCS Workshop Geneva, February 28, 2005 General roles of the front-end DCS computers • Worker nodes • Interact with the hardware • Only the software necessary for the operation will be installed • No interactive login sessions are foreseen • UI nodes • Allow the operation of the system • Some interactive tools might be installed (e.g. browser for viewing the help files, scripts for fast online data analysis…) • General purpose nodes • Connected to Internet • No direct access to the DCS system • In addition we might install a set of Development nodes with compilers and other tools required for the project modifications (hotfixes etc.)

12. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The DCS Lab Fronted prototype Pre-installation Servers Backend Prototype

13. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Backend Systems Pre-installation Servers Backend Prototype

14. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Pre-installation servers Database Server Primary Domain Controller And backend services Secondary Domain Controller Application Gateway / TS Infrastructure Worker Node File Server

15. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The SUS Server • Downloads available patches from Microsoft • Deploys patches to workstations • Deployment requires approval by Administrator

16. Peter Chochula, DCS Workshop Geneva, February 28, 2005 SUS – Synchronization log

17. Peter Chochula, DCS Workshop Geneva, February 28, 2005 SUS – patches awaiting approval

18. Peter Chochula, DCS Workshop Geneva, February 28, 2005 How can we assure that patches have been applied? • There is no simple way, but we can do a system scan using security scanners • MBSA (Microsoft Baseline Security Analyser) obtains list of approved updates from the SUS server and scans domain computers for their presence • In addition to this other vulnerabilities are scanned

19. Peter Chochula, DCS Workshop Geneva, February 28, 2005 MBSA – security scan Missing patches Weak passwords

20. Peter Chochula, DCS Workshop Geneva, February 28, 2005 MBSA – Weak passwords

21. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Group policies in the DCS domain • A set of policies is assigned to computers and users via the group policy objects (GPO) • This method allows us to • Remotely control computer and user settings • Grant/revoke privileges to computers and users • Deploy/remove software components • Deploy patches • The policies are structured • Common policies, valid for all computers • UI and worker nodes policies, server policies • DCS users, experts, administrators

22. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Group Policies Management

23. Peter Chochula, DCS Workshop Geneva, February 28, 2005 MBSA – scan after applying the policy Problems cured

24. Peter Chochula, DCS Workshop Geneva, February 28, 2005 GPO example – IE settings

25. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Alidcs DNS server

26. Peter Chochula, DCS Workshop Geneva, February 28, 2005 ISA Server – Rules for SUS

27. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Services for Unix

28. Peter Chochula, DCS Workshop Geneva, February 28, 2005

29. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Status of the computing for the pre-installation • Hardware • Back-end servers delivered and are being installed • Network being installed in P2 • Software • Back-end computers with all services will be installed in P2 in April

30. Peter Chochula, DCS Workshop Geneva, February 28, 2005 DCS operation during the pre-installation • DCS will operate on its own windows domain • Connection to CERN will be possible only via the application gateway • We will provide the needed assistance in configuring the front-end machines for the operation in the pre-installation environment

31. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Computing rules for the pre-installation • The use of the DCS computers must follow the CERN rules • The DCS computing will introduce a set of additional (in general more restrictive) rules • The aim is to assure the safe operation in the experiment environment • The conditions during the pre-installation must resemble the real operation to a maximum possible extent • The first priority is to operate the detector equipment, many rules will be imposed in steps as far as the stable conditions will be achieved

32. Peter Chochula, DCS Workshop Geneva, February 28, 2005 General computing rules for the DCS • The policies are studied and defined by CNIC • The DCS will follow these rules • We expect that we will be able to test the CNIC components as of beginning of 2006 • A list of ALICE-specific requests has been compiled – this is based on the outcome of the last Q&A session • Some questions still need clarification A detailed proposal for ALICE DCS operation will be presented in Utrecht

33. Peter Chochula, DCS Workshop Geneva, February 28, 2005 What should one expect? • The back-end infrastructure and front-end installation will by provided by the DCS team • Requests for adding new software must be sent to the DCS team. We will take the necessary steps • Please note, that some software will be available only on the general-purpose network • Any software installation (including the PVSS projects or OPC/FED server updates) must be approved by the ACC responsible person who will participate in the installation • Note: assistance of the detector expert is required • All software versions will be standardized and developers are requested to comply with these definitions in order to avoid incompatibilities (e.g. wrong library versions etc.) • This affects the version of the operating system, PVSSII version, framework, DB clients, compilers, OPC servers etc.) • Please consult the ACC team before any major developments

34. Peter Chochula, DCS Workshop Geneva, February 28, 2005 What will be tested in the lab? • The software must undergo tests in the lab before it can be copied to the production system • It is clear that most of the software requires also the DCS hardware for its operation, but there are still points which require careful tests • Is the software clean (e.g. no viruses)? • Is the software following the rules (e.g. does it expect standard directories, does it follow the naming convention, will it clash with other projects?) • Are the external dependencies correctly resolved (libraries, configuration for external servers) ?

35. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Rules for the production (final) systems • The operation of the production system will be strictly controlled • All modifications must be approved, software must pass through the lab and affected systems must be backed-up (in addition to regular backups) before the upgrade • Patches must be provided as a set of libraries, scripts, panels which will be loaded to the production machines • If the whole project needs to be replaced, this must undergo again the full test procedure in the lab

36. Peter Chochula, DCS Workshop Geneva, February 28, 2005 The DCS Network • Provided centrally • Installation is happening now • Layout is based on your requests • The DCS network is separated from other networks via an application gateway • Only a limited set of services with strictly defined rules is allowed to cross the boundaries • (ECS, connection to the database, switch management, online time service…)

37. Peter Chochula, DCS Workshop Geneva, February 28, 2005 ? port ? port 24 port 24 port 24 port 24 port ~8 port 72 port 12 port 24 port CR3 ACR 1Gbps 1Gbps 8x One of these will be 1Gbps 1Gbps DCS operator consoles DSS gateway computer (1) 100Mbps 100Mbps 100Mbps 1Gbps DCS computers (~90) “portable” ports (~4) 100Mbps Appl. Serv. CR4 SG DCS equipment (HV, VME) (~25) Services (PLC [TS/EL]) (1-2) “portable” ports (~8) 1Gbps Services (PLC&PC [gas]) (~10) “portable” ports (~2) 1Gbps 100Mbps 100Mbps DCS network CERN network Plug Services (PLC [gas]) (~5) “portable” ports (~3) 1Gbps 100Mbps On-detector 1Gbps UX 1Gbps ?x DCS equipment (HV, VME) (~20) Services (PLC [TC/CV,TS/EL]) (~15) “portable” ports (~20) 1Gbps 100Mbps 100Mbps 100Mbps • This does not include the trigger VME crates (RB26 side); these are not necessarily on the DCS network. • Need to cross-check with TS/CV if there is no double counting for the cooling plant PLC’s • A total of ~800 ports are distributed over switches close to the detector (40 m cable limitation). Drawing provided by André Augustinus 07/01/2005

38. Peter Chochula, DCS Workshop Geneva, February 28, 2005 KVM IPR S1 Computing organization for the pre-installation Worker Nodes Database Server Primary DC Secondary DC System Console File Server DCS Operator Infrastructure WN Application GW CERN Network DSS DCS Network Control Room

39. Peter Chochula, DCS Workshop Geneva, February 28, 2005 Design of the ALICE control room • Work started together with the DAQ • Due to limited space we have to restrict the total number of top-level computers in the control room • The physical layout is ready • 1 computer / detector with connections both to the DCS and DAQ via application gateways • General purpose nodes • Tests with DCS and DAQ prototypes scheduled