1. 1 DEGISCO Desktop Grids For International Scientific Collaboration Details on Roadmap (interoperation with gLite and EMI grids) Budapest, 14.07.2011 Sandor Acs, MTA SZTAKI DEGISCO is supported by the FP7 Capacities Programme under contract nr RI-261561.

2. 2 DEGISCO WP2 13/07/2011 2 Presentation outline 1.Short overview from BOINC 2.EDGI Virtual Images 3.SG->3G Bridge ->BOINC 4.Live Demo

3. 3 DEGISCO WP2 13/07/2011 3 BOINC Middleware designed for volunteer Desktop grid computing http://boinc.berkeley.eduhttp://boinc.berkeley.edu/ http://boinc.berkeley.edu Used for the largest Grid in the world: seti@home More than 4 million computers world wide have BOINC installed Many other projects use BOINC

4. 4 DEGISCO WP2 13/07/2011 4 BOINC Structure BOINC is organised around projects: a project is typically one application Resource computers (BOINC clients) can connect to one or more projects A Grid server can run more projects User interface can be integrated with the project

5. 5 DEGISCO WP2 13/07/2011 5 BOINC Server Installation Installing a BOINC Grid is not click and play Collection of C++ programs, PHP scripts and other sources, with many dependencies on operating system, the database, and other tools Easiest way: get one of the distributions. For instance the SZTAKI BOINC distribution. This installs relatively fast if you start with a Debian/Linux system

6. 6 6 BOINC Client on resource Customisable, easy-to-install Easy view and complex view with a lot of details on what is happening

7. 7 7 BOINC applications BOINC applications have to be compiled with calls to a special BOINC API. There are some wrappers for executables, like genwrapper (developed by MTA SZTAKI) More extensive API’s exist for instance for master worker-applications: DC-API (developed by MTA SZTAKI)

8. 8 Job source WS submitter Job source WS submitter Job Handler Interface DB Queue Manager Grid Handler Interface DC-API plugin Job submission from gLite to BOINC via 3G-Bridge

9. 9 VOMS LBWMSBDII LBWMSBDII AR* Local BOINC DG LB WMS BDII UI CE Figure of the virtualized infrastructure CA*

10. 10 Purpose of virtual infrastructure The purpose of these VMs is to provide a base to easily set up local test or development infrastructure to be used for:  getting to know these services or  devel  developing and testing applications and  new middleware components in a local usage scenario.

11. 11 Overview Virtual machine (VM) images are set up as a test infrastructure for EDGI project. Available “http://www.edgi-grid.eu/downloads/vmimages/” Virtual machines are configured to function as:  a minimal,  self contained, test infrastructure of the SG ⇒ DG (service grid to desktop grid) infrastructure.

12. 12 Warning! The components are similar to those used in the EDGeS/EDGI production infrastructure however, these VMs are not meant to be used for setting up a public production infrastructure. The focus while creating these VMs were on: easy installation and simple local usage as opposed to :  performance and  security which in this setup do not meet the requirements of production usage.

13. 13 Overview of Virtual machines  testui.edgitest UI, BDII_top SL5 (x86_64, gLite 3.2)  testvoms.edgitest VOMS, BDII_site, CA (SL5 x86_64, gLite 3.2)  testwms.edgitest WMS, LB (SL4 i386, gLite 3.1)  testce.edgitest lcg-CE, bridge-CE BOINC, 3gbridge (SL4 i386, gLite 3.1)  testboinc.edgitest SZDG 6.11 (Debian 6)

14. 14 Virtualization technology and starting the VMs  Images come in the qcow2 format:  native format of QEMU,  Compressed.  Qemu-img tool can covert these files to all widely used virtual machine monitor formats.  Images are compatible with XEN, KVM and QEMU out of the box.  Some VMs need x86_64 capable CPU.  VM instances should be started in the order indicated by their IP addresses (testui first).

15. 15 Network Configuration The VMs have their networking preconfigured to use IP addresses in the 192.168.143.0/24 network because:  Grid Security Infrastructure used by gLite requires fixed host names for host certificates,  to avoid the need for DHCP and DNS service configuration simple static IP assignment is used (and the name mapping is done in /etc/hosts).  If the network configuration is changed /etc/hosts has to be synchronized on all VMs.

16. 16 Security  The VMs are intended for local use and not configured with security in mind and should be protected by a firewall controlling access to the subnet they live in.  Trusted Certification Authority a simple local CA was created on testvoms to serve only this infrastructure. The CA certificates are installed on testui and also shared by all VMs.  This local CA is not in any way secure because its private key comes with the VM images and thus accessible to anyone so it should only be used for these VMs where access to the VM instances are secured by other means (e.g. using a firewall to control access to the instances).

17. 17 TestVO and test user  A local VO named “test” was created and it is hosted on the testvoms VM.  This setup makes it simple to use the infrastructure in a local setting and allows independent management of users and hosts (and allowed us to ship the VMs with pre-installed host certificates so you don’t have to care about them).  In the following, the procedure is described needed to create a new user and add it to the VO. This has already been done for the testuser so you can use this account for testing.

18. 18 Create user 1. First create the user account on testui as root: [root@testui ~]# useradd testuser [root@testui ~]# passwd testuser 2. Change to the new user and create a certificate request for this user (enter the user name and a password when prompted): [root@testui ~]# su - testuser [testuser@testui ~]$ grid-cert-request 3. Now disregard the instructions printed about mailing the certificate request and instead just copy the certificate request to root@testvoms: [testuser@testui ~]# scp ~/.globus/usercert_request.pem root@testvoms:

19. 19 Create user (2) 4. Leave testuser@testui and log in to root@testvoms. On testvoms sign the request: [root@testvoms ~]# /opt/globus/bin/grid-ca-sign -dir simpleCA \ -in usercert_request.pem -out usercert.pem -days 913 5. This will put the new certificate in usercert.pem (check that CN part in the Subject: line matches the user name), copy this certificate back to testuser@testui and then remove the files from testvoms: [root@testvoms ~]# grep Subject: usercert.pem Subject: O=Grid, OU=simpleCA, OU=EDGI, OU=edgitest, CN=testuser [root@testvoms ~]# scp usercert.pem testuser@testui:.globus [root@testvoms ~]# rm usercert.pem usercert_request.pem

20. 20 Create user (3) 6. Register the user in the test VO (use the Subject printed above replacing commas with slashes for the user DN): [root@testvoms ~]# voms-admin --nousercert --vo test create-user \ "/O=Grid/OU=simpleCA/OU=EDGI/OU=edgitest/CN=testuser" \ "/O=Grid/OU=simpleCA/OU=EDGI/CN=EDGI Test CA" \ "testuser" "testuser@testui.edgitest" You can check the new user in the list of users: [root@testvoms ~]# voms-admin --vo test list-users 7. VOMS requires new users to accept an AUP via a web form for their registration to remain valid. To do this go back to testuser@testui where you can use a text mode browser to do this. First get an old style grid proxy from your certificate and use that to authenticate to VOMS: [testuser@testui ~]$ grid-proxy-init -old Your identity: /O=Grid/OU=simpleCA/OU=EDGI/OU=edgitest/CN=testuser Enter GRID pass phrase for this identity: Creating proxy................................... Done

21. 21 Create user (4) 8. Then start the text mode browser telling it to use your proxy for authentication: [testuser@testui ~]$ X509_CLIENT_CERT=/tmp/x509up_u$(id -u) elinks In elinks go to the URL below, scroll down to the bottom of the page with arrow keys, check the box using the X key and then press Enter on the submit button. After that you can leave elinks with the Q key. https://testvoms.edgitest:8443/voms/test/aup/sign!input.action?aupId=1 [X] I declare I have read and agree with the AUP terms displayed above [ Submit ] 9. This concludes the user creation and registering in the VO. You can destroy the proxy created above: [testuser@testui ~]$ grid-proxy-destroy

22. 22 Testing the infrastructure 1. Create a voms proxy: [testuser@testui ~]$ voms-proxy-init --voms test 2. Submit a job: [testuser@testui ~]$ cd DSP_Test [testuser@testui DSP_Test]$ glite-wms-job-submit -a -o id dsp.jdl 3. You can check the status of the job with the following command: [testuser@testui DSP_Test]$ glite-wms-job-status -i id 4. You can get more detailed information about the state changes of the job with the following command: [testuser@testui DSP_Test]$ glite-wms-job-logging-info -v 2 -i id

23. 23 Testing the infrastructure (2) 5. When the job reached the Done(Success) state you can download the output of the job: [testuser@testui DSP_Test]$ glite-wms-job-status -i id 6. Finally, check the output, remove the files created and destroy proxy when finished using the infrastructure: [testuser@testui DSP_Test]$ cat testuser_XXXXXXXX/cost.txt [testuser@testui DSP_Test]$ rm -rf id testuser_XXXXXXXX [testuser@testui ~]$ voms-proxy-destroy

24. 24 Configuration of the VMs The gLite VMs are configured with YAIM.  On each machine the configuration is stored in the /root/glite directory.  The main configuration file is called site-info.def.  This file is not exactly the same on every component.  Additionally to the main config file the /root/glite/vo.d directory contains the VO configuration and other files or a services subdirectory may have other configuration files for some node types. The correct YAIM command can be found in the file /root/glite/confcmd on each VM.  For example (on testui): [root@testui glite]# cat confcmd /opt/glite/yaim/bin/yaim -c -s site-info.def -n glite-UI -n BDII_top

25. 25 Configuration of the VMs (2) The BOINC project called edgitest was installed from the SZDG BOINC distribution to “testboinc” VM.  It contains 3G-Bridge and  the DSP application for testing. (3G-Bridge related configuration files can be found at /var/lib/boinc/edgitest/master/3g-bridge/.) The EDGeS SG ⇒ DG bridging requires an Application Repository  but for brevity this is not included in this set of VMs.  Instead a local, static ARCache pre-loaded with the necessary values was created on testce in the /srv/www/lighttpd/Repository directory and the CE is configured to use this local ARCache.  This means that the infrastructure is independent of any other infrastructures and does not require connection to an ARCache (as is the case for normal CEs).  Also note that the local ARCache is not updated from the AR as the regular ARCache thus, adding new applications requires editing of this local ARCache instance by hand.

26. 26 Troubleshooting If something goes wrong then the logs can be checked for errors.  Generally the log files are kept in the /var/log/ directory on Linux systems but some services do not follow this and put their logs elsewhere.  Some gLite services (including the gLite part of the EDGeS bridge) are logging to /opt/*/var/log/ under their installation root (the bridge logs are on testce in /opt/edges/var/log/). On testboinc log files of the BOINC project are located at /var/lib/boinc/edgitest/project/log_testboinc/. The logs of the BOINC client is at /var/lib/boinc- client/stdoutdae.txt.

27. 27 http://degisco.euhttp://desktopgridfederation.eu Globe adapted from http://upload.wikimedia.org/ wikipedia/commons/f/fa/ Globe.svg DEGISCO Desktop Grids For International Scientific Collaboration