OpenSAF Virtual Machine for ISAS 2008

Transcription

1 OpenSAF Virtual Machine for ISAS 2008 Users Guide Version 1.2 (April, 2008) By András Kövi, OptXware Ltd. and Gábor Urbanics, Budapest University of Technology and Economics

2 Introduction... 3 Acronyms... 3 OpenSAF... 4 Operation... 7 Starting the virtual machine... 7 Using the User Mode Linux environment... 7 Creating a multi node configuration Useful Utilities Installed software Fedora Core Net-SNMP Xerces TIPC & Tipcutils Mercurial OpenSAF: acquiring source code and creating rpms Appendices usr/share/snmp/snmpd.conf file etc/init.d/snmpd management shell script Page 2

3 Introduction This document provides information on the usage and operation of the OpenSAF Virtual Machine (OpenSAF VM) created for the 5 th International Service Availability Symposium (ISAS 2008: Since OpenSAF is a complex middleware, its usage, configuration and management is not a trivial task. The purpose of this document is to help those who are interested in OpenSAF and would like to try it out or evaluate its capabilities. The OpenSAF VM is a VMware virtual machine that is compatible to be run with ACE 2.x, ESX Server 3.x, Fusion 1.x, Server 1.x, Workstation 5.x, Workstation 6.x and Player VMware products. The OpenSAF VM contains all the required applications and utilities configured, the OpenSAF controller and payload RPM packages created and the User Mode Linux (UML) environment built. The document first describes the required applications and their roles, and the process of installation and configuration. Then the operation of the OpenSAF UML environment is introduced. Finally, the necessary steps for creating a multi-node cluster are introduced. This document contains excerpts from the INSTALL guide of OpenSAF ver and the OpenSAF documentation and was not created to substitute those materials. Acronyms BOM CLI GUI LEAP Bill of Material (the list of entities that are in a system) Command Line Interface Graphical User Interface Layered Environment for Accelerated Portability OpenSAF Open Service Availability Framework UML VM User Mode Linux Virtual Machine Page 3

4 OpenSAF OpenSAF (Open Service Availability Framework) is an open source project established to develop a base platform middleware consistent with Service Availability Forum (SA Forum ) specifications, under the LGPLv2.1 license. The OpenSAF Foundation was established by leading Communications and Enterprise Computing Companies to facilitate the OpenSAF Project and to accelerate the adoption of the OpenSAF code base in commercial products. The OpenSAF architecture Figure 1 OpenSAF service components overview The following groups of service components are available in OpenSAF: System Description This System Description is involved in the definition of a system model. It is a set of XML files which define system entities and their relation for the purpose of system configuration and management. The System Description is read in once at system startup and from that time on stored in persistent memory. OpenSAF Services o SA Forum Services OpenSAF implements the AMF, CLM, CKPT, MSG, EVT and LCK services defined by the SA Forum. o Complementary Services Since the SA Forum services can not cover all the functionality needed for a healthy ecosystem, OpenSAF implements a set of complementary services. These are the Distributed Trace Service (DTSv), the HPI Integration Service (HISv), the System Resource Monitoring Service(SRMSv), the Persistent Store Service (PSSv), the Management Access Service (MASv), the Message Based Checkpointing Service (MBCSv) and the Interface Service (IfSv). Description for Page 4

5 these can be found in the OpenSAF documentation (available at the OpenSAF download page Message Distribution Service As a basis for all services, OpenSAF uses a common Message Distribution Service for all in-cluster communication. Currently this service uses the TIPC (Transparent Inter Process Communication) protocol and the TIPC-project open source implementation. Layered Environment for Accelerated Portability (LEAP) The LEAP is an operating system abstraction that provides portability to both OpenSAF services and user applications from underlying operating system specifics and provides many value-added features. o o o o o o o IP-layer abstraction File system abstraction Dynamic library abstraction Monitored buffer and memory manager Monitored process internal queues Monitored timer services which can oversee a large number of timers at once Object locking LEAP provides its services in the form of C macros and libraries to be linked by applications. For further details on the LEAP and on how to use it, refer to the LEAP Programmer's Reference. Page 5

6 Figure 2 OpenSAF service distribution An OpenSAF cluster is a heterogeneous cluster from the perspective of node types. Two types of nodes exist: controllers and payloads. Controllers are responsible for managing the cluster, the services and the user applications, while payloads are the nodes where the user applications are hosted. Even if controllers are able to host user applications, it is preferred that they are run on payloads as resource intensive (CPU, network overload) applications may influence the behavior of system services. In OpenSAF the system services are handled as SA-aware SA Forum specs based applications. The system configuration can be found in the NCSSystemBOM.xml file. User applications have to be configured through the AppConfig.xml file. More on configuration of the platform can be found in the System Description section of the OpenSAF documentation. Page 6

7 Operation This section describes how the OpenSAF VM should be operated. The following topics will be discussed here: How to start the OpenSAF VM. Operating the User Mode Linux environment, a virtual environment inside the VM. Creation of a multi node configuration by creating copies of the OpenSAF VM. Starting the virtual machine The OpenSAF VM is provided to you as a RAR compressed archive. Simply decompress it into a directory where at least 5GB free disk space is available. Before starting the VM please consider increasing the memory allocated for the guest OS. By default it is set to 420 MB which may easily become insufficient if you want to develop and test applications too. The recommended amount of memory for a development VM is GB. For other machines where only OpenSAF is executed MB should be enough, supposed that the applications run by OpenSAF are not very memory intensive. Please keep in mind that even if it is not required for most of the operations described in the following, we suggest logging in with the root user. Later, when you become familiar with the usage of the facilities, usage of a non root user will be recommended, but before that, the security restrictions would only make things more complicated. Using the User Mode Linux environment The User Mode Linux (UML) environment allows one to simulate multiple Linux machines in the same host machine. The OpenSAF source tree contains a configured UML environment where, by default, a five node cluster will be started with two controller nodes and three payload nodes. The /root/install/opensaf/tools/cluster_sim_uml contains the preconfigured, compiled UML environment for OpenSAF. The compilation of the environment is a straight forward process if the description given in /root/install/opensaf/tools/cluseter_sim_uml/readme is followed. Page 7 Notice In some systems you may experience continuous restarting of the UML virtual nodes. The most probable cause for this is that the service heartbeat timeout values are set quite strictly by default and overloading of the processor or the non real-time operation of the system clock in the virtual machine can eventually cause timing failures.

8 To avoid this, modify the <NCSScalars> section of the NCSSystemBOM.xml located in the <uml root>/root.controller/etc/opt/opensaf/ directory by increasing the heartbeat values. An example for a modified configuration can be the following: <NCSScalars> <sndhbint>5000</sndhbint> <rcvhbint>15000</rcvhbint> <clusterinittime>40000</clusterinittime> </NCSScalars> Operation of the UML cluster After starting the cluster by issuing a./opensaf.sh start in the root of the UML environment tree, six terminals will appear: 2 controllers (SC_2_1, SC_2_2), 3 payload nodes (PL_2_3, PL_2_4, PL_2_5) and a UML network window. If all the instances started successfully, then a view, similar to Figure 3, should be visible. Figure 3 Successfully started UML cluster with 5 nodes. Page 8

9 To check out if everything is running as expected, the following tests can be carried out. Test whether the aishello application is running on the payloads by issuing a ps x grep ais in each PL_2_X terminal which should return the pid and execution path of the aishello process. To see what role has the application taken, issue a tail /var/log/messages, where the last messages should be from the aishello component, saying it has taken the active or standby role on behalf of a given CSI, similarly to the following listing. user.debug aishello: Registered as [safcomp=compt_aishello,safsu=sut_aishello,safnode=pl_2_3] user.debug aishello: csisetcallback: SA_AMF_HA_ACTIVE, CSI=safCsi=Csi_aishello,safSi=Si_aishello_1 user.debug aishello: name: CsiAttr_aishello, value: aishello_1 The configuration of the aishello application is depicted in Figure 2. Aishello Application safnode=pl_2_3 safsu=sut_aishello, safnode=pl_2_3 safsg=sg_aishello(n+m) safnode=pl_2_4 safsu=sut_aishello, safnode=pl_2_4 safnode=pl_2_5 safsu=sut_aishello, safnode=pl_2_5 safcomp=compt_aishello, safsu=sut_aishello, safnode=pl_2_3 safcomp=compt_aishello, safsu=sut_aishello, safnode=pl_2_4 safcomp=compt_aishello, safsu=sut_aishello, safnode=pl_2_5 active standby active safcsi=aishello, safsi=si_aishello_1 safcsi=aishello, safsi=si_aishello_2 safsi=si_aishello_1 safsi=si_aishello_2 Figure 4 AMF configuration of the aishello application. The possible values for CSI assignation for a particular aishello component are the following: ACTIVE for safcsi=csi_aishello,safsi=si_aishello_<1 or 2> STANDBY for both Sis To test failover of controllers and services, you should issue tail f /var/log/messages to see recent system messages continuously. Page 9

10 Test a controller switchover by issuing the following commands in the command line of the active controller node. To decide whether a controller is active, issue a cat /var/opt/opensaf/node_ha_state command in each controller s window (SC_2_1, SC_2_2). In the CLI the Ctrl+D should be used for deleting a character and Ctrl+R to recall the last command. The CLI is only accessible by the opensaf and the root users. Step 0: Step 1: Step 2: Step 3: Step 4: Step 5: Step 6: su /opt/opensaf/controller/bin/ncs_cli_maa en conf t avsv admswitch clishut If the admswitch command fails, then try issuing the same sequence on the other controller node, since you were trying on the standby node. When commands succeeded, issue the cat /var/opt/opensaf/node_ha_state command in both controllers terminals. The change should be visible in the logs. Creating a multi node configuration The UML environment for OpenSAF can be useful in many cases, however, its networking is configured to enable only the UML nodes access each other. Thus testing an application that provides services for the outside world would require reconfiguration which is not a trivial job. Also, in the current environment one node can seriously affect the performance of other nodes as they run in the same virtual machine. VMware virtual machines, however, allow for higher flexibility considering networking and deployment capabilities. To create a multi node cluster, the following high level steps have to be executed: Create copies of image Set up copies Start and test the cluster Create image copies The new nodes will be copies of the original image. The easiest way to create a new VM is to create a full clone, however, some VMware products (Workstation, Server and Player) allow the creation of linked clones, which means that only those parts of the disk are replicated that changed from the original one. As a result, the clone images will be significantly smaller than full clones. Creating full copies. To create full copies of the image, simply copy all the files in the VM s directory to a new directory. Make sure that the guest OS is completely stopped. If you are using VMware Workstation, then use the VM->Clone menu item and select the Create a full copy option when offered. Page 10

11 Creating linked copies. Linked copies require a bit more caution when created. It is recommended to make sure that the original disk image does not change any more after the linked copies are created. The best way to ensure this is making the disk image files (*.vmdk) read-only. In Workstation use the VM->Clone menu item and select the Create a linked clone option when offered. In case of VMware Server or Player please follow the instructions from (VMware Communities: Create linked clone on VMware Server) Create as many clones as many nodes you would like to have in your cluster. The default OpenSAF configuration contains five nodes, two controllers and three payload nodes. We suggest creating one controller node and one to three payload nodes. Having two controller nodes is required only if controller failover is tested, however, it requires the setup of a synchronized file system where the active controller stores its current status and which can be used by the standby controller on controller failover. The replication of data can be carried out using DRBD, nfs or any other solution. The setup process for DRBD can be found in the OpenSAF INSTALL file. Set up new images Install controller/payload packages. Depending on whether payload or controller node is being set up, the respective actions should be taken from the following steps. The opensaf_***.rpm is available in the /root/install/opensaf/rpms directory. Pick the above rpm and execute the following commands rpm -ivh --nodeps opensaf_controller***.rpm on a machine acting as a system controller, OR rpm -ivh --nodeps opensaf_payload***.rpm on a machine acting as a payload. Notice OpenSAF rpm checks if the pre-requisite opensource packages are already installed. The rpm dependency check will fail in a case if you have not installed these packages as rpm. Since in the OpenSAF VM we did not use rpms to install the packages, the --nodeps switch is necessary. Page 11

12 Configure installation. OpenSAF configuration files are located under /etc/opt/opensaf. Both for controller and payload nodes the following files have to be modified: nodeinit.conf This is the input file to the Node Initialization Daemon for serializing the opensaf services startup. This file contains a line similar to the following /opt/opensaf/controller/scripts/nid_tipc.sh:tipc:s:/opt/opensaf/controlle r/scripts/nid_tipc.sh: 4000::2:1:start eth2 2351:stop The key point is the start eth expression. Here eth2 refers to the Ethernet interface that is used for communication, and 2351 is the TIPC network ID that must be the same on all nodes in the cluster. Please check which interface is used for communication by issuing ifconfig in a terminal or start the neat utility. The interface name can change if the MAC address of the virtual network card changes, which is necessary when the copies are run at the same time. slot_id This file contains the physical slot id for the node. This is a positive integer: 1 and 2 identify controller nodes, while 3 and above are identified as payload nodes. Outside a computing blade environment, like in a PC or VM cluster, these numbers are just needed to identify a node. After modifying these files, the configuration process for payloads is complete. However, for controllers there is one more thing that has to be checked. For controller nodes it is important to have a well known IP address as it is used by the Role Distribution Entity to connect to the peering controller. For this reason, you should set a static IP address e.g. by using the neat utility. After this, the /etc/opt/opensaf/rde_rde_config_file has to be modified on the controller nodes by changing the HOSTIPADDRESS to the pre set value, SERVERIPADDRESS to another address from the same subnet, and MAX_CLIENT_RETRIES=1. The SERVERIPADDRESS does not have to be a live address only an address from the same subnet. E.g. if the node IP address is then the config file will look like as follows: HA_ROLE=0 HOSTIPADDRESS= HOSTPORTNUM=9003 SERVERIPADDRESS= SERVERPORTNUM=9005 MAX_CLIENT_RETRIES=1 Page 12

13 Setting a fix IP for the payloads is unnecessary as TIPC communication is used that is independent from IP protocol settings. However, to ensure that connectivity between the controller and the payloads is available, try to ping all the payloads. Notice Before starting the newly created nodes, please make sure that your host system has enough physical memory to run the virtual cluster. The minimum memory for each VM is 256MB but 512MB is recommended. If you still experience problems, try examining the error logs or assigning more memory to the VMs. Summary. Files that need to be modified on payloads: nodeinit.conf, slot.id Files that need to be modified on controllers: nodeinit.conf, slot.id, rde_rde_config_file Start and test functionality Start the controller by issuing /etc/init.d/nis_scxb start. The result should look like to following listing. [root@localhost opensaf]# /etc/init.d/nis_scxb start Starting Node Initialization Daemon: /opt/opensaf/controller/bin/ncs_nid Moving /var/opt/opensaf/nidlog to /var/opt/opensaf/old_nidlog...done. Moving /var/opt/opensaf/stdouts to /var/opt/opensaf/old_stdouts...done. Mon Apr 7 14:13:05 PDT 2008 Starting OpenSAF Services... Starting TIPC service... Done. Starting RDF service... Done. RDF-ROLE for this System Controller is: 0, ACTIVE Starting DTSV service... Done. Starting MASV service... Done. Starting PSSV service... Done. Starting EDSV service... Done. Starting SUBAGT service... Done. Starting IFSVDD service... Done. Starting SCAP service... Done. Node Initialization Successful. SUCCESSFULLY SPAWNED ALL SERVICES!!! Status: SUCCESS SERVICE Initialization Success Mon Apr 7 14:13:24 PDT Then start the payload(s) sequentially by issuing /etc/init.d/nis_pld start on each node. The result should be similar to the following listing. [root@localhost ~]# /etc/init.d/nis_pld start Starting Node Initialization Daemon: /opt/opensaf/payload/bin/ncs_nid Moving /var/opt/opensaf/nidlog to /var/opt/opensaf/old_nidlog...done. Moving /var/opt/opensaf/stdouts to /var/opt/opensaf/old_stdouts...done. Page 13

14 Mon Apr 7 14:14:33 PDT 2008 Starting OpenSAF Services... Starting TIPC service... Done. Starting PCAP service... Done. Node Initialization Successful. SUCCESSFULLY SPAWNED ALL SERVICES!!! Status: SUCCESS SERVICE Initialization Success Mon Apr 7 14:14:36 PDT Typical errors. TIPC does not start. RDE does not start. Ethernet interface not set properly. Correct nodeinit.conf. TIPC is already loaded. rmmod f tipc HOSTIPADDRESS and SERVERIPADDRESS are not set properly. Correct rde_rde_config_file. Running the example application If the controller was started once, it will set itself to use the created persistent store data (PSSV service) when restarted. However, to install a new application, we need to add the application s description to the configuration. To reset OpenSAF to use its XML System Descriptors, the following steps have to be executed on the controller node. In the CLI the Ctrl+D should be used for deleting a character and Ctrl+R to recall the last command. Only the opensaf and root users can access the CLI interface. Step 1: /opt/opensaf/controller/bin/ncs_cli_maa Step 2: en Step 3: configure terminal Step 4: pssv Step 5: set playback-option-from-xml-config AVD Step 6: set playback-option-from-xml-config AVM Step 7: clishut After this, stop all nodes by issuing /etc/init.d/nis_scxb stop on controllers and /etc/init.d/nis_pld stop on payloads. When all nodes stopped, the AVSV sample application needs to be installed on the payloads with slot id 3 and 4. The sources of the example application can be found in the /root/install/opensaf/samples/avsv directory and can be compiled as follows: Step 1: cd /root/install/opensaf/samples Step 2:./bootstrap.sh Step 3:./configure Step 4: make Install the sample application inventory on the target machine as follows: Page 14

15 1. Transfer the sample program executable file (avsv_demo) to the payload nodes. Place it in /etc/opt/opensaf. Transfer the sample program scripts (comp_inst.sh and comp_term.sh) to the payload nodes. Place them in /etc/opt/opensaf folder. 2. Ensure that the scripts have executable permission. Use the following command: chmod +x comp_inst.sh chmod +x comp_term.sh 3. Copy the AppConfig.xml to /etc/opt/opensaf on the controller node or to /repl_opensaf/config and create a symlink from /etc/opt/opensaf to it (ln s /repl_opensaf/config/appconfig.xml). 4. Remove the avsv_demo.log file, if any, from the /var/opt/opensaf/stdouts folder on the payload nodes. This file contains the output of the sample application After restarting the whole cluster, starting with the controller node and then the payload(s), the example application should be running on the payloads. To check this, issue a ps x grep avsv command on them which will display information about the avsv_demo process. Also check the result of tail f /var/opt/opensaf/stdouts/avsv_demo.log command on payload 3 and 4. SNMP management tests SNMP architecture. SNMP, the Simple Network Management Protocol, is used in network management systems to monitor network-attached devices for conditions that warrant administrative attention. It consists of a set of standards for network management, including an Application Layer protocol, a database schema, and a set of data objects. Figure 5 SNMP architecture Page 15

16 OpenSAF uses the Net-SNMP package as implementation. The SNMP management architecture is depicted in Figure 5. The OpenSAF subagent registers with the SNMP Master Agent and they communicate using the AgentX protocol. The OpenSAF subagent is configured through the /etc/opt/opensaf/ncssnmpsubagt.conf file. Client requests received by the master agent are forwarded to the subagent which then interacts with the different service providers and sends the reply back to the master agent. Notice The SNMP daemon in the OpenSAF VM has already been set up. No repetition of the above steps is needed. SNMP daemon setup. The SNMP daemon should be started on the controller node before any SNMP commands are issued to OpenSAF. The SNMP daemon should be started only on the controller nodes, and the setup is done in the following way: Step 1: Copy all MIB (Management Information Base) files from the OpenSAF install mib directory (/root/install/opensaf/mib) to /usr/share/snmp/mibs Step 2: Create SNMP daemon configuration. The configuration file should be placed in the /usr/share/snmp directory and named snmpd.conf. The file should contain at least the following lines: master agentx rwcommunity public agentxsocket tcp:localhost:705 Managing the SNMP daemon. The SNMP daemon should be started, stopped or restarted with the following command respectively: /etc/init.d/snmpd {start stop restart status} This starts the daemon with the following parameters: listen on TCP port 705 on all IPv4 interfaces the daemon runs without having ownership of the interfaces group of MIB-II use the system log and dump and, since not defined otherwise, use the /usr/share/snmp/snmpd.conf configuration file After executing the above command, a tail /var/log/messages should be issued to see if the daemon started properly and the above script should be called with status argument. The snmpd script is listed in the appendices section of this document. Page 16

17 Furthermore execute the following test query: snmpwalk -Onf -v 2c -c public localhost. Meaning of arguments are: -O controlls the format of output. -v tells which version of SNMP will be used. -c gives the community used in queries. localhost is the host on which snmpd is listening.. refers to the root of SNMP tree. If the query returns a lot of results then the SNMP system is working properly. SNMP with OpenSAF. The SNMP daemon has to be started before executing admin operations through OpenSAF MIBS. Do the following: Step 1: /etc/init.d/snmp start Step 2: /etc/init.d/nis_scxb start Now to test if everything works fine, issue snmpwalk -Onf -v 2c m +NCS-AVSV-MIB -c public localhost \ aise > mibcontents.txt The changed and new arguments are: -m requires a list containing the MIB names. + sign causes not to override the MIB list contained in environment variables or other configuration files, if any, but to extend it with a new item. In the example above the NCS-AVSV-MIB refers to one of the MIBs packed with OpenSAF. If client and server are not the same the client has to have the corresponding MIBs locally. aise is the root of the AIS Experimental namespace that is currently used by OpenSAF. The mibcontents.txt file will now contain the output of the command which can be further scrutinized. For example, if you are interested in getting information about the controller nodes then use cat mibcontents.txt grep SC The AvSv Demo application. As a last test, you can get the details of the AvSv Demo application that was set up in the previous section. Issue snmpwalk -Onf -v 2c m +SAF-AMF-MIB \ -c public localhost aise > amfmib.txt cat amfmib.txt grep AvSvDemo less These commands will show the rows corresponding to the demo application. Page 17

18 Useful Utilities The following utilities can be useful when using the OpenSAF VM: Midnight Commander (already installed) easy to use file manager VNC (already installed) currently configured to use the same desktop which is available. The preferences can be changed with the vino-preferences utility. The current password for connection is: opensaf. You can use any VNC client applications like VNCViewer. For connection use the <vm ip address>:5900 address. Eclipse (not installed, requires Java) for facilitating application development. Installed software In this section we describe how the OpenSAF VM was developed. The process of installing the various prerequisite packages and their role in the whole system is described in detail. All downloaded packages can be found in /root/download/opensaf_packages Notice All the steps introduced below have been executed and all mentioned software have been built, installed and configured in the OpenSAF VM. Fedora Core 8 OpenSAF was developed with high level of portability in mind and this allows it to be able to run on a variety of Linux distributions. A list of those which were verified can be found at The OpenSAF VM contains a Fedora Core 8 operating system installed. The installation contains all the software development tools and the Gnome desktop environment. VM settings: User/pass: root/opensaf, ais/opensaf, opensaf/moto123 (this user is automatically created by the opensaf rpms while installation) VNC password: opensaf Memory: 400MB (adjustable, recommended min 256) Disk: 8 GB (split in 2GB parts) Kernel version: fc8 Page 18

19 Net-SNMP OpenSAF provides SNMP interfaces for remote management and uses the Net-SNMP open source implementation as the basis. The virtual machine contains version installed. The install packages are available at Install sources are extracted to /root/install/net-snmp Installation steps: Step 1../configure --prefix=/usr --without-openssl \ --disable-embedded-perl --without-perl-modules --without-rpm Step 2. make Step 3. make install Xerces OpenSAF uses XML based configuration files. Processing of these files is carried out by the Xerces-C library. The virtual machine contains version The install packages are available at Install sources are extracted to /root/install/xerces-c-src_2_7_0 Installation steps: Step1: export XERCESCROOT= /root/install/xerces-c-src_2_7_0 Step2: cd /root/install/xerces-c-src_2_7_0/src/xercesc Step3: autoconf Step4:./runConfigure -plinux -minmem -nsocket -tnative rpthread \ -cgcc xg++ Step5: make Step6: make install TIPC & Tipcutils TIPC (Transparent Inter Process Communication) is used for intra cluster communication in OpenSAF. The installed Fedora operating system kernel contains this module, so no recompilation is needed. OpenSAF searches for the TIPC kernel module and the tipc-config utility in the /opt/tipc directory. Tipcutils sources are extracted to /root/install/tipcutils Installation steps: Step 1: mkdir /opt/tipc Step 2: cp /lib/modules/ fc8/kernel/net/tipc/tipc.ko \ /opt/tipc Page 19

20 Step 3: cd /root/install/tipcutils Step 4: make KERNELDIR=/usr/src/kernels/ fc8-i686 Step 5: cp tipc-config /opt/tipc Notice There are several security updates available for download from the Internet, but in order to keep the VM size at a minimum, we decided not to install these. If you choose to do a system update, then make sure that the kernel is not updated, because after that the original TIPC module will not be loadable due to module crypto signing problems. To solve this, TIPC needs to be recompiled which is not possible without modification of the source code downloaded from the TIPC website as it is not compatible with kernels newer than today. Mercurial The OpenSAF project uses Mercurial for source code versioning and repository. The OpenSAF repository is accessible at Installation: Step 1: yum install mercurial OpenSAF: acquiring source code and creating rpms Obtaining the source code: Step 1: cd /root/install Step 2: hg clone OpenSAF source code can be found in /root/install/opensaf Building the controller and payload rpms: Step 1: cd /root/install/opensaf Step 2:./bootstrap.sh Step 3:./configure build_type=controller Step 4: cd /root/install/opensaf Step 5: cp /usr/include/linux/tipc.h services/mds/inc Step 6: make Step 7: make rpm Step 8: make clean Step 9:./configure build_type=payload Step 10: make Step 11: make rpm The compiled rpms are located in the /root/install/opensaf/rpms directory. These rpms can be used on different target machines to install OpenSAF. Page 20

21 Appendices /usr/share/snmp/snmpd.conf file rwcommunity public master agentx agentxsocket tcp:localhost:705 /etc/init.d/snmpd management shell script #! /bin/sh # -*- OpenSAF -*- # # Copyright (c) 2007, Ericsson AB # # This program is distributed in the hope that it will be useful, # but WITHOUT ANY WARRANTY; without even the implied warranty of # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This # file and program are licensed under High-Availability Operating # Environment Software License Version 1.4. # Complete License can be accesseble from below location. # # See the Copying file included with the OpenSAF distribution for # full licensing terms. # # Author(s): # # Modified by Andras Kovi, BME & OptXware # # start/stop snmp daemon. SNMPD=/usr/sbin/snmpd SNMPDOPTS='-I -interfaces -Lsd -p /var/run/snmpd.pid' test -x /usr/sbin/snmpd exit 0 test -f /usr/share/snmp/snmpd.conf exit 0 case "$1" in start) echo -n "Starting network management services:" $SNMPD $SNMPDOPTS; echo -n " snmpd" echo ;; stop) echo -n "Stopping network management services:" killall -q $SNMPD; echo -n " snmpd" echo ;; restart) $0 stop $0 start ;; status) SERVICE='/usr/sbin/snmpd' if ps ax grep -v grep grep $SERVICE > /dev/null then echo "$SERVICE service is RUNNING " else echo "$SERVICE is NOT RUNNING" Page 21

22 fi ;; *) echo "Usage: snmpd {start stop restart status}" exit 1 esac exit 0 Page 22