Skip to content

Technical Description

The Framework Concept

The Framework is based on a hierarchical concept of delegation between a master and sub-domains. A domain is called a Named System Set (NSS) in the Framework concept. The idea is that each NSS can control well defined sets of computer or user groups. The role for each NSS is defined by the permissions it gets granted from the master NSS. In our model, the NICE group (IT/IS) acts as master NSS. The master NSS has full control over the whole domain and can create other NSSs and grant permissions to it.

More details about what can be controlled are described in the Users Guide.

The concept of the framework, which is mostly visible through the Frontend layer, is illustrated in the following picture:

https://cmf-dev.web.cern.ch/cmf-dev/Help/Contents/Images/Technical%20Description/image004.png 

The Framework Implementation and Building Blocks

This chapter will summarize the various implementation technologies of the layers of the Framework.

The Framework Layers

The Framework consists of a top to bottom 3 layers model, which are completely separated. Any layer can be replaced by another technology at any time without interference with the other layers.

https://cmf-dev.web.cern.ch/cmf-dev/Help/Contents/Images/Technical%20Description/image001.gif https://cmf-dev.web.cern.ch/cmf-dev/Help/Contents/Images/Technical%20Description/image002.gif https://cmf-dev.web.cern.ch/cmf-dev/Help/Contents/Images/Technical%20Description/image003.gif

The top layer, called the Frontend layer, defines the user interface. This part includes everything what interacts directly with the administrators and users. It is a set of tools to manage, control and return reports from the system. All the tools are web-based which makes the Frontend layer platform independent.

The bottom layer, called the Backend layer, is the software running on a central server system and on all participating clients. This software performs all actions which are defined by the Frontend layer.

The middle layer, called the Database layer, acts as the connection between the Frontend and Backend. It holds all configuration data submitted by the Frontend tools and all reporting generated by the Backend software.

The Frontend Layer

The Frontend layer is completely web-based and has been developed in C# under Visual Studio .Net. It will consist of 3 types of graphical user interface tools:

  • Management Tools: Interfaces to create, manage and delete NSSs, NSCs and PKGs. It includes an information flow mechanism for adding computers to NSCs as well as for informing Locally Managed NSC Admins when new packages are created.

  • User Tools: Wizards replacing the actual Add/Remove Programs applet. These interfaces provide a global view on all allowed, applied and denied PKGs. These tools are also directlt accessible from the CMF system tray icon.

  • Status Pages and Reports: Web based interfaces reflect the status of a single desktop (used by normal user) or the status of a complete NSC (used by NSC Admins). It is possible to detect incoherencies between the configuration data stored in the Framework database and the real desktop configurations. It provides a single view to check whether the members of a NSC are up to date.

All changes are logged in the database.

The Database Layer

We use a Microsoft SQL server as central database for all configuration and reporting data, except for the NSC memberships which are directly stored in the CERN Active Directory as security groups. These groups are automatically updated when a computer is removed from the CERN domain. Another advantage is that these security groups can be directly applied on Group Policy Objects. All databasew access must be done via the Frontend layer, which runs with elevated privileges and taking into account the logged on user permissions.

The Backend layer

The implementation of the back-end layer is done by 2 programs running on each client PC. The CMFAgent service running under the SYSTEM account is responsible for all actions. The CMFAgentUI application running in the user context acts as the interface between the user and the service.

The communication between the database and the client PC is performed by 3 file servers, called distribution points. Various scheduled jobs running on a dedicated server are acting as interface between the distribution points and the database to transfer the data between these 2 systems.

The CMF backend software is also based on the Microsoft .NET technology and is completely written in C#.

The CMF database

The 2 CMF SQL databases are located on CERNCMF01:

  • CMF administration database: This database holds all client configuration data which is populated by the CMF web site. The following picture shows the relationships between the tables.

https://cmf-dev.web.cern.ch/cmf-dev/Help/Contents/Images/Technical%20Description/dbcmf.jpg

A dedicated server job is triggered by every database update. Taking into account the changes, this job re-generates the required flat files (eg. CMFPKGs.TXT, CMFNSCs.TXT,.. ) which are on their turn used by the CMF client agent.

  • CMF reporting database: This database holds all client reporting data and is populated by a dedicated server job taking information from all individual PC reporting data files located on the distribution points. Data from all clients is uploaded on a daily basis during the night. That means that data will be uploaded to the database even if the desktops are offline.

The CMF Server jobs

The following server jobs are running on CERNCMF01:

  • CMFSRV: This job is triggered by every database update from the web site. Every update made from the web site, creates a record in Front End User Action Log table. These new records are analyzed by the CMFSRV task which re-generates the corresponding flat files and acknowledges the request by setting a timestamp in the ServerAck field of the record. This job runs continuously.

  • CMFGPO: This job is triggered when saving a package of the type Group Policy. It creates or deletes the GPO is needed and sets the required permissions. The communication with the web site is done via an IPC file. This job runs continuously.

  • CMFReportSrv: This job scans all report files from the distribution points, looks for eventual critical client errors and application deployment problems; and populates the database with these results. The job runs on a regular base.

  • CMFReportingCMD2: This program is the core program updating at least once per day all inventory and applications data of all machines. For metering you can control for how long metering information can be kept in the CMF database. By default for private policy reasons, it is deleted after 4 months.

    Logs can be found on CERNCMF01 in the 'CMF\SrvLogs\Reporting' folder

The distribution points

The distribution points are simple file servers which in charge to distribute configuration data to the CMF clients and to receive the reporting data. At present, the client load is spread over are 3 distribution points. Each client is checking the configuration data on a distribution point and sending reporting data on a regular base.

The CMF Web Site

The administration part of the CMF web site is mostly acting on the administration database, except for NSC memberships, which are directly stored in Active Directory. Each NSC holds 2 security groups, one for computers (CMF_NSC_[id]) and one for users (CMF_NSC_[id]_NSU). All groups are located in OU=NSC,OU=CMF,DC=cern,DC=ch.

The package editing page is also acting on Active Directory for the creation and update of Group Policy Objects. Since not all GPO related actions can be carried within the web pages, some of them are performed by a permanently running job which is talking with the web page via an IPC file.

The CMF Client software

The CMF software running on the client PC consists of 3 programs:

  • CMFAgent: This program, running as a service, is responsible for all actions carried out on the client. It checks the distribution point on a regular base, downloads the necessarily files and verifies the installation of all CMF packages. The program has no user interface and communicates with the user via another program CMFAgentUI running in the user's context.

  • CMFAgentUI: This application, running in the user's context, is accessible via the CMF system tray icon. The application does not perform any action on the PC, but is more an interface between the user and the CMFAgent service.

  • CMFAgentUpdate: As both CMFAgent and CMFAgentUI program have an automated version update feature built-in, they cannot be replaced during run-time. When CMFAgent or CMFAgentUI detect a new version on the server, they make a local temporarily copy and launch CMFAgentUpdate just before killing themselves. CMFAgentUpdate on its turn, copies the file and restarts the program (CMFAgent or CMFAgentUI following what specified as command line option).