Secure Delivery Center Concepts

Distribution Manager

Genuitec’s Secure Delivery Center (SDC) is a software distribution manager that assists administrators in providing software to various groups in their organization with little to no intervention by end users. Not only do administrators oversee providing users with software, they also must manage licenses, software updates, rollouts, and standardization. Using SDC, these tasks can be handled efficiently from a central location.

You can also use SDC to manage security and Secure Marketplace catalogs for Eclipse-based software installations that are not delivered using SDC. This on-demand delivery scenario allows you to enforce security policies and deliver add-on software catalogs of approved software to existing Eclipse-based software users in your organization.

Delivery Hub

The SDC distribution manager, or delivery hub, hosts the software packs and third-party software add-ons you want to deliver to end users. This delivery hub, which is behind your firewall, is where users receive all software updates rather than updating from a Genuitec site or other software site. However, you can explicitly choose to allow end users to make changes to their development environment from outside sources.

When you install SDC, you first install the delivery hub software onto the delivery hub machine. Next, administrators install the Admin Console onto their desktops to control and manage software delivery. Through the Admin Console, you install software packs, e.g. Eclipse Discovery and MyEclipse Pro, which are automatically installed on the delivery hub machine. Software packs are not stand-alone installable versions, rather they contains the pieces required to build end-user installers based on packages you create using the Admin Console.

Note: The SDC manager software, software packs, and Admin Console are installed in a Secure Delivery Center folder, which contains a Data Filesfolder. The Data Files folder is one that is important to include in your system backup.

SDC uses a database for storing alerts, metrics and errors. You can use either the embedded database included with the SDC software, or your own external database. The data stored is essentially a history of distribution. When you install SDC, you can either connect to an existing database, or SDC can install and configure one for you.

Packages & Libraries

A package is the software, including add-ons, you want to deliver to your users. Packages are created in the Admin Console by an SDC administrator. Two types of packages can be managed using SDC.

First, you can tailor and deliver complete Eclipse or MyEclipse IDEs, including security policy enforcement add-on software, and other customizations. An admin installs MyEclipse or Eclipse IDE software obtained from Genuitec, as well as add-on software, onto the secure hub. From there, complete custom IDEs and secure catalogs are created, maintained, and delivered to end users.

A second package type is On-Demand Delivery, which delivers Secure Marketplace catalogs and/or security policy enforcement to existing Eclipse-based IDE installations, i.e. Eclipse or IBM RAD. The Eclipse-based IDE is obtained from an outside source and installed apart from using SDC. An admin installs add-on software onto the secure hub and delivers Secure Marketplace catalogs of tested and approved software, as well as security policies, to Eclipse users.

As shown above, software received from Genuitec can be either MyEclipse, Eclipse, or add-on software. An administrator loads this software on the SDC server, which is no more than a delivery hub for managing distribution. From there, you can deliver a managed, secure marketplace catalog and security policies to Eclipse-based installations obtained from other sources. Or, you can deliver complete secure catalogs and custom IDEs to end users.

A third option is Eclipse RCP packages. You can deliver RCP applications through SDC by specifying an RCP product within an Eclipse IDE package. There are two modes of RCP deployment. The “Based on Package” method applies your Eclipse application/product on top of a standard Eclipse package defined in SDC. You add your software as third-party software, and then add it to the Eclipse package on the Software tab. The “Product Line-up” method involves exporting a product from the Eclipse IDE and then adding that product into the third-party library in SDC.

SDC allows administrators to delegate package administration to team leads using Advanced Team Delegation features. When using this administration method, packages take on special properties. To learn more about advanced team delegation, see Advanced Team Delegation.

Libraries
Libraries are the additional add-on software you can include in the package. A library can be from standard libraries such as Eclipse Discovery or Java, or it can be from a third-party update site. When you add third-party software, you specify a URL where the software can be accessed. You also choose which available software to expose, or make available, to packages. A mirror image of the selected software from the update site is placed on the hub machine; therefore, when you add the software to a package or you allow end users to install from a Secure Marketplace catalog, the software is installed from the delivery hub machine rather than from a site outside your firewall. You also have control over the third-party software versions exposed to your users.

The Admin Console

The Admin Console is where SDC administrators manage all aspects of the software delivery lifecycle. SDC administrators maintain the high level packages, updates, policies, and licenses. They perform the initial configuration of packages. Some SDC administration tasks include:

• Setting security and access policies
• Creating packages with base configurations
• Adding external libraries for use in packages or Secure Marketplace catalogs
• Testing software configurations
• Distributing software packages to end users
• Reviewing system usage metrics and monitoring system health

Each step of the delivery lifecycle is addressed in the Admin Console and listed on the Admin Console Dashboard. The flow includes creating installation packages, testing, and finally distributing software when you are ready.

The Delivery Center Jump Start gives you access to each of the steps for distributing software. From this Dashboard, you can manage staging, testing, and rolling out of one or more software packages. A package is the software, including add-ons and configurations, you want to deliver to your users.

The links below each step of the lifecycle on the Dashboard give you access to the associated pages. For example, your installed software packs for which you can create packages are listed below the Create a New Package step. These are also listed in the Secure Packages list in the Admin Console navigation.

Admin Console Dashboard

As you configure packages, the Notifications area indicates that you have outgoing local changes to commit. Learn more about committing and promoting packages in Rollout and Update Process.

The Admin Console also includes usage metrics such as the number of installations by package, the highest use packages, and promotion dates. This information is helpful for seeing trends in the usage of of your software packages and helps you project the number of licenses your organization requires.

Installers

After you configure a package, you can test the package and installer locally before committing changes to the delivery hub. SDC generates a local network-based installer when you are in the testing phase. When you make the package available to users, SDC generates the installer from which your users install the package. This can be a network-based installer, a bundled installer, web install, or all types, depending on your package configuration. The package’s Timeline tab, Live page displays a link to the web flow installer on the delivery portal and also allows you to copy the path to the network-based and bundled installers.

• Network-based Installer – Network-based installers contain the software for the installer and the metadata for the profile. The installer downloads the software via the SDC delivery hub. Requires all software to be available on the delivery hub machine, and an update site to be created by the installer. Requires network connection to the delivery hub.
• Bundled Installer – Bundled installers contain the software for the profile as well as the metadata. Can be used without a network connection because all artifacts are bundled.
• Web-Install Flow – If the package’s access policy enables the web-install flow, SDC generates a special web installer for this purpose.

Portal Web Page

SDC is equipped with a portal web page that presents to your users the packages you make available. You can use this page as part of your delivery system, although it is not required. When you make a package available by promoting, it is added to the portal page automatically if you configure the package to appear on the portal page.

When you promote your package, you receive installer build feedback on the package’s Timeline tab, Live page. With a successful build, a link to the portal page is provided so you can see the promoted package is included on the portal. You can then supply this link to your developers for downloading software, or download the installer for distribution via your SMS system.

Optional portal page displaying groups, which contain promoted software

What is Required of the End User?

The purpose of SDC is to relieve administrators some of the burden of software distribution, license maintenance, and standardization. SDC is also meant to keep end users from spending valuable development time on updating their environment. Therefore, little action is required on the part of the end user to keep their software up-to-date.

When you roll out a new software package, you provide a link to either a bundled or network-based installer, or you make the package available via the portal web page included with SDC. The end user runs the simple installer to install the software. The administrator who created the package has already made choices as to which software add-ons are included; the end user does not have to make this choice during installation.

When the user’s package is installed, in-product service is included. This means that as administrators make software or workspace updates available, users are notified and able to accept the updates. No other action is required by users. Depending on the security policy selected for the package, users could be required to update immediately, or they might be allowed to update when they are ready. See Configuring a Security Policy for more information.

Group Administrators

In your organization, you might want to designate some end users as group administrators. These users are given access to the Admin Console, which provides them rights to make package changes for their team. The group administrator can change and promote add-on libraries and the packages only in their assigned delivery group. SDC administrators set up users in the system and specify which are admins, group admins, or users. See Managing User Accounts for setting up system users, and Configuring Delivery Groups for designating a user as a group administrator.

Group administrators can take on even more responsibility for their packages by using Advanced Team Delegation features of SDC discussed in the following section.

Delegating Package Administration to Team Leads

With the Advanced Team Delegation features of SDC, administrators can split package administration responsibilities with team leads. This method of administration takes package admin to another level, giving team leads control over team-specific settings and configurations while continuing to centrally enforce critical package details across the board.

Note: Advanced Team Delegation features are optional to use. If you are just starting out with SDC, learn the basics of package delivery before delving into advanced team delegation.

By using advanced team delegation, central administrators are only concerned with over-arching package considerations – security settings, testing and adding 3rd-party software to the library, setting up software catalogs, version control, etc. Team leads can take a basic package created by central administrators and customize a child version of that package to meet the specific needs of their team. But, the critical aspect of this feature is that the central administrator can make all-encompassing changes to the basic package that roll down to all child packages without jeopardizing team customizations.

Package flow when using advanced team delegation features

Standalone, Principal, and Secondary Packages

When using the advanced team delivery method, packages take on special properties. There are three types of packages – Standalone, Principal and Secondary packages.

Standalone Packages
A standalone package is not used for team delegation purposes. Team leads designated as group admins can make changes to the package, but there is no connection between the package and packages of other teams. It is simply a package created and maintained specifically for one team.

Standalone package flow

Principal Packages
A principal package is a basic package created for team delegation purposes. The central administrator creates a package with critical security policies, common software, and other over-arching settings and designates it as a principal package. A principal package is the basis of secondary packages.

Principal package is the parent of a secondary package

Secondary Packages
Secondary packages are based on and linked to a principal package. They are customized and managed by team leads or admins. Think of a principal package as a master template. Secondary packages are created based on the principal package, with their own customizations. However, when a central admin makes a change to the master template, the principal package, those changes flow down to the associated secondary packages without causing loss of team customizations.

Principal package flows to secondary to end users

Delegation Policy

When you create a principal package, you assign a delegation policy that indicates the level of control allowed to team leads when customizing their secondary package. Simple toggle switches allow you to specify which aspects of package configuration team leads are allowed to change. The policy dictates if team leads can manage the following:

• Secondary package branding
• Additional software
• Additional workspace tasks
• Additional notifications
• Group membership
• Package promotion

Delegation policies

Advanced Team Packages

The Team Packages page is accessed from the main Admin Console navigation and is the location where you manage principal and secondary packages. Create principal packages, and then base secondary packages on principal packages. Principal packages include a delegation policy that dictates the permissions given to team leads who manage related secondary packages.

Team packages

See the Advanced Administration Learning Center for documents on using these optional features.