Secure Delivery Center Installation Guide

1. Installation Overview

This guide provides steps to installing the various SDC components, which are defined below:

• Server (Delivery Hub) Software: The SDC delivery hub software controls all aspects of software delivery and software pack installation. The delivery hub software must be running to install the following software packs.
• Database: A database stores server, or hub, history information. A database is included in the SDC installation, or you can connect to an existing external database.
• Admin Console: The Admin Console software is installed on administrators’ desktops for managing software distribution. The Admin Console installer is generated when you install the SDC server software.
• Software Packs: Software packs contain components necessary for delivering software. The packs required depend on the software you are delivering.
• Signing Agent: If any end users are running either OS X Mountain Lion or Windows 8, you must digitally sign installers that will run on those systems. SDC includes a signing agent that automatically signs installers with your digital signature. Signing agent installation is not required if no end users are running either of these operating systems or if the operating systems are configured to allow running unsigned installers.

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. The Admin Console is available for installation from the Admin page of a portal web page. Through the Admin Console, you install software packs, e.g. Eclipse Discovery and MyEclipse, 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.

1.1 System Requirements

Delivery Hub Hardware

• Linux server with GTK and 1.5 GB memory (Linux is preferred, but Windows and Mac are also supported)
• Java 1.7-compliant operating system (http://www.oracle.com/technetwork/java/javase/config-417990.html)
• 20-40 GB free disk space for common installation
• Intranet DNS hostname assigned for server(s)

Client Hardware

• Windows, Linux, or Mac OS X
• No minimum requirements – dependent on tool stack being delivered

Software

• No additional software required
• Compatible with SMS systems
• Optional: external database, either Oracle or MySQL; a database is included with installation, so no additional database is required.

1.2 Operating Systems Supported

2. Install the Delivery Hub Software

1. Double-click the SDC installer file.
   
   Note: If on Linux, you might need to make the .run file executable via chmod u+x server-installer.run (Replace server-installer.run with the name you have downloaded the SDC software install to.)
2. Click Next to view the license agreement.
3. Select the I Accept… checkbox, and click Next.
4. Choose server options. First, you can install SDC as a system service, which requires admin rights, or you can install as software into your user account.
   
   Note: When installing on a Mac, the system service option is not supported; therefore, the option is unavailable. See Adding the SDC Hub as a Login Item on Mac Systems for an alternative option.
   
   Second, select the database you want to use, either the database embedded within SDC or an existing external database. If you are using an external database, select it from the Use External Database drop-down. You can choose from either Oracle or MySQL.
   
   
   Selecting server options
5. Click Next. If you are using an external database, enter your database information. Otherwise, skip to the following step.
   
   Note: In MySQL, the user name and password you enter must have permissions to create tables in the given schema.
6. Specify the installation and data folders. The default paths place the SDC installation folder at the same level as the data files folder. Click Next.
   
   
   Setting installation and data folders
7. Enter the username, name, and password of the initial administrator, and click Next.
   
   
8. Enter the hostname or IP address and port at which you want to receive incoming requests. Click Next.
   Note: If you have a non-static IP address, you should use the computer’s hostname rather than the IP address. This hostname will be part of the SDC web portal URL, so it will be visible to your users. We strongly recommend using a fully qualified domain name so users roaming onto a VPN can still connect to the server.
   
   
   Entering hostname information
9. Click Next to install the server. When installation is complete, click Finish. The SDC software starts automatically.
   
   
   Successful installation

By default, the Display the Secure Delivery Center First Steps Help Page checkbox is selected. This opens the login page to the portal. Log in using the administrator login specified during server installation. Once logged in, the Welcome section includes a link to the Admin Console installer. You should bookmark this help page for future reference. For those installing silently, the link to the help page is http://<hostname>:<port>/#/dashboard/setup.

2.1 Starting the Delivery Hub Software

When you first install the delivery hub software, it starts automatically. Your platform and how you chose to install the software determines how you start and stop the delivery hub software thereafter. To see system progress and to verify the hub software started properly, you can view the log by navigating to the installation folder for Secure Delivery Center, and then Data Fileslogsserver-details-0.log.

Windows
If you installed on Windows as a system service, you start and stop the hub software through the Services control panel.

If you installed into a user account, start the hub software by running deliverycenterserver.exe in the C:Users[username]AppDataLocalSecure Delivery CenterServerserver folder. To stop running the hub software on Windows when installed into a user account, end the process on the Processes tab of the Task Manager.

Linux
If you installed as a service, start/stop the hub software using the following command:

service genuitec-sdc <start/stop>

If your Linux version does not support services, use the following command:

/etc/init.d/genuitec-sdc <start/stop/status>

You can also use your desktop’s activity monitor to stop the server process.

If you installed into a user account, start the hub software by running deliverycenterserver in the [installation folder]Serverserver folder. Use your desktop’s activity monitor to stop the server process.

Mac
Installing as a service on Mac is not supported. To start the hub software, double-click the deliveryCenterServer file in the applications list. Stop running the hub software by right-clicking the icon on the Dock to quit the process. See See Adding the SDC Hub as a Login Item on Mac Systems for an alternative option.

2.2 Adding the SDC Hub as a Login Item on Mac Systems

Mac systems do not support running an application as a service. To have the SDC server start automatically when a user is logged on, add the SDC server to the login items.

1. Open the System Preferences by clicking its Dock icon or by clicking the Apple icon in top left of the screen and selecting System Preferences.
   
   
   Opening System Preferences
2. Open Users & Groups Preferences.
   
   
   Opening Users & Groups
3. Select Login Items, and click the Plus icon to add an item.
   
   
   Adding an item to the list
4. Search for the deliveryCenterServer file on your system.
   
   
   Searching for the SDC Delivery Hub application file
5. Select the file, and click the Add button to add it to the list.
   
   
   Adding the application file

3. Install the Admin Console

The initial administrator must install and run the Admin Console. From there, all software packs can be installed onto the SDC delivery hub machine. After all installation is complete, the admin can add all admin usernames and passwords to the system so other admins can access the Admin Console installer. The Admin Console installers are available on the portal web page.

To install the Admin Console, you must have the SDC delivery hub software running.

1. From the admin desktop, access the portal web page at http://<your hostname>:<port>/. The port number in the URL needs to match the port number you entered when installing the SDC delivery hub software.
2. Log in with the username and password you specified during SDC delivery hub installation, and click the Setup tab.
3. In the Welcome section, click the icon next to Admin Console that corresponds to your operating system. This downloads the Admin Console installer file.
   
   
   Selecting the Admin Console installer
4. Double-click the installer file.
5. Click Next view the license agreement.
6. Select the I Accept… checkbox, and click Next.
7. Either accept the default installation folder, or change the folder, and click Next.
   
   
   Specifying the installation folder for Admin Console
8. Click Finish to complete installation.
9. Log into the Admin Console.

When ready to add other administrators, click Users under Administration in the Admin Console navigation. Enter all admin usernames and passwords. For more information, see Managing User Accounts. After adding administrator accounts, each admin can access the web portal page and install Admin Console following the steps in this section.

4. Install Software Packs

To use SDC for on-demand delivery to Eclipse installations, you are not required to install software packs. However, to simplify marketplace catalog creation, you can install a certified poplular software pack, which installs onto the delivery hub machine many popular software add ons. If you are installing a certified software pack, continue to the next section. Otherwise, you can skip to Installing Signing Agents for Digital Signatures.

To use SDC to distribute secure IDEs to your end users, you must install software packs. The software packs contain the components necessary for creating installers based on packages you create in the Admin Console. The packs required depend on the software you are delivering.

Packs are installed via the Admin Console. The following pack descriptions indicate which packs are required for the software you are delivering:

• Eclipse Discovery Software Pack: The Eclipse Discovery software pack installer includes all Eclipse-based components needed to create end-user installers for both MyEclipse and Eclipse IDE software.
• Java Software Pack: Includes Java run-times necessary for creating end-user installers for MyEclipse software. This pack is required for MyEclipse IDE delivery. It is optional for Eclipse IDE delivery and On-Demand delivery to Eclipse-based installations.
• MyEclipse Software Pack: The MyEclipse software version you want to distribute to your end users. This is not the same as an installer used when running software outside the context of SDC. Instead, this pack installs the components necessary for creating end-user installers for the software.
• Certified Software Pack: A collection of some of the most popular Eclipse plugins available. Genuitec certifies the integrity of the downloads and makes them all available for use in SDC in a single pack. Useful for all delivery types.

To install software packs click the installing packs link in Step 1 on the dashboard.

Accessing pack installation

The Get Packs window opens, listing packs available for installation. Packs already installed appear with a disabled Installed button. To view all packs, click the Browse tab.

Get Packs window

Click the Install button beside each of the required packs. The Admin Console downloads and installs the new pack behind the scenes, directly into the SDC delivery hub. The Notifications area displays the progress.

Note: The Get Packs capability is not available when logged in as a Group Admin.

5. Install Signing Agents for Digital Signatures

OS X Mountain Lion and Windows 8 operating systems require applications downloaded from the Internet to be signed. Therefore, the SDC installers generated for users on those systems must be signed. A Signing Agent is included with SDC to automatically sign package installers on Windows and OS X as required.

Note: Digital signatures on installers are required only for OS X Mountain Lion and Windows 8. If end users are not running on either of these operating systems or if the operating systems are configured to allow running unsigned installers, you are not required to install signing agents.

The following elements must be in place for digital signing to occur using SDC:

• If you’re signing both OS X and Windows installers, a machine running each operating system must be available as a signing “helper”. These machines must be able to connect to the SDC delivery hub. It is not necessary for these machines to be dedicated to this task, but they must have internet access in order to contact timestamp services.
• Obtain and install a digital signing certificate for each operating system from a Certificate Authority. Install the signing certificate on the helper machine of the respective operating system.
• For Windows, you must have the Windows signing tool available, which is part of the Windows SDK (http://go.microsoft.com/fwlink/?linkid=84091). For OS X, you must have the Xcode signing tool (https://itunes.apple.com/us/app/xcode/id497799835?mt=12). These signing tools must be installed on the “helper” machine of the respective operating system.
• Install the SDC signing agent on the helper machine(s).
• Configure the certificate in the Admin Console.

5.1 Installing Signing Certificates

Signing certificates obtained from a Certificate Authority must be installed on the helper machine of the respective operating system.

Installing a Windows Signing Certificate
To install a certificate on Windows, you are required to have a .pfx archive. Some registrars provide a .pfx when you purchase your certificate. If you did not receive one during your purchase you can use OpenSSL to create one.

1. Download and install OpenSSL.
2. Run the following command:

openssl pkcs12 -export -out domain.name.pfx -inkey domain.name.key -in domain.name.crt

Once the .pfx file is generated, simply double-click the file and follow the wizard to install. Make sure you mark the key as exportable and place the key in the Personal Certificate Store.

Installing an OS X Signing Certificate
On OS X, signing certificates must be loaded into the Key Chain of the user running the signing agent on the helper machine. To load the certificate, double-click the certificate file. Only the user whose Key Chain contains the certificate file can sign files.

5.2 Installing a Signing Agent

1. From a signing helper machine, access the portal web page at http://<your hostname>:<port>/.
2. Log in with an administrator username and password, and click the Setup tab.
3. In the Welcome section, click the signing agent link for the platform to which you are installing. This downloads the signing agent installer file.
   
   
   Selecting the signing agent installer
4. Double-click the installer file.
5. Click Next view the license agreement.
6. Select the I Accept… checkbox, and click Next.
7. Either accept the default installation folder, or change the folder, and click Next.
   
   
   Specifying the installation folder for the signing agent
8. Click Finish to complete installation. By default, the signing service is set to start automatically when a user logs onto the helper machine. The signing agent must be running for package installers to be signed.

Configuring the Signing Agent
When you first open the signing agent, you must specify the URL to the SDC delivery hub. After the hub locaion is specified, the agent automatically searches the SDC hub machine for installers of the same operating system as its host machine. When the agent then signs unsigned installers.

1. With the signing agent open, click Preferences.
   
   
   Opening preferences
2. Enter your SDC delivery hub machine URL in the format http://<hostname>:port, and click .
   
   
   Setting the delivery hub URL

6. Installing the Delivery Hub on a Linux Server in Unattended Mode

In some Linux installations, you are unable to click through an installer because the server isn’t running a graphical user interface. In this case, you must use the unattended installation mode to run installers. To activate the unattended mode, run the installer file from the command line with the following arguments:

--unattended <full path to your response file>

For example:

delivery-center-server-4.2.0-installer-linux.run --unattended /home/root/unattended.properties

The unattended.properties file contains responses to questions that would normally be asked in the installer. Below is a sample of a server unattended installer response file.

Note: The software pack installers only require the result.file property in the response file.

server.dir=/home/user/sdc/server
server.data.dir=/home/user/sdc/data
result.file=/home/user/sdc.result.txt
admin.fullname=Administrator 
admin.password=abc123
admin.username=admin
database.engine=BUNDLED
server.hostname=sdc.mydomain.com
server.install.as.service=false
server.port=1305

If you fail to include a property or configure a property improperly, the installer indicates what the offending property is and the value it is expecting.

Appendix A: Advanced Deployment Considerations

In many organizations, SDC is a critical part of daily business. In some situations, there are SDC deployment configurations that go above and beyond simply installing SDC on a server. Common considerations are the need for high availability and high levels of security.

As with any deployment question, we strongly suggest you talk through your deployment plan with your SDC representatives.

The Delivery Hub is designed so that it requires only a single server to manage hundreds of thousands of installations. Still, your organization may be spread across the globe and in locations where network connectivity is shoddy. SDC supports these environments by using mirrored content to optimize installations over multiple regions. Additionally, servers do fail from time to time, and SDC supports fast failover to new servers and backup strategies that are easy for you to implement.

Security can be a high priority in sensitive fields. SDC has provisions for ensuring that administration, user, and automated traffic is isolated. Additionally, you might want to run SDC over HTTPS. Both of these concerns are addressed using a reverse proxy server in front of your Delivery Hub. Some organizations do not allow services to run as root. SDC supports this configuration with a few caveats.

High Availability

SDC is designed in such a way that the critical computation for delivering a package occurs just once. This means installations, upgrades, and uninstalls are handled efficiently by both the client and the server. This is key because it means a very large organization can be supported via just one Delivery Hub. Nevertheless, there are organizations who require all internal services be supported via High Availability setups. Since not all topics apply to all deployments, we will discuss each topic separately and leave it up to you to assemble the configuration that applies to your environment.

Supporting Failover

You can put a load balancer in front of the Delivery Hub to support fast failover if your hardware dies.

Failover Support
With a load balancer in front of your Delivery Hub, you can have one or more servers waiting in the wings that can automatically start if your primary Delivery Hub server hardware dies. Each deployment is slightly different, but the general design is as follows.

Important Note: Because this requires modifying the hostname of your deployment, you should enact these changes early in your rollout. Installed packages, the Admin Console, and SDC Signing Agents all expect to be able to contact the server using the hostname and port you specify for your Delivery Hub.

Assume you have your Delivery Hubs installed on servers with hostnames sdc1.example.com, sdc2.example.com, etc., and your load balancer’s hostname is sdc.example.com. You will give sdc.example.com to the Genuitec Sales team for license generation purposes.

Each of your sdc*.example.com servers should have their own copy of the SDC [Server] directory. They all share the same [Data Files] directory through a shared network mount.

Once you have a Delivery Hub running on your sdc1.example.com, turn on your load balancer and have it start directing traffic from sdc.example.com tosdc1.example.com.

If your load balancer refuses to direct traffic to an unresponsive server, you must disable the check that the server does at startup to ensure that clients can properly communicate with the Delivery hub. To disable the startup check, add the following attribute inside the <runtime> tag in your [Data Files]system-configserver-runtime.xml file.

<runtime>
     <loop-back-disabled>
     ...
</runtime>

Once you prove that your load balancer is directing traffic to your currently running Delivery Hub, you need to set up your server to think its hostname issdc.example.com. To do so, modify the [Server]serverconfigurationconfig.ini file to point to sdc.example.com in each of your Delivery Hub installations. When you do so, delete the [Data Files]artifactsadmin-console directory and restart your Delivery Hub. After a short while, your Delivery Hub builds new installers for your Admin Console, which points to sdc.example.com instead of sdc1.example.com or sdc2.example.com. Install this Admin Console so that communication goes to your running Delivery Hub rather than to just a single Delivery Hub.

You are now in a state where you can stop one Delivery Hub, say on sdc1.example.com, and start another on sdc2.example.com, with only moments of downtime. You’ll need to set up scripts to stop the Delivery Hub on one machine and activate it on another so that no two Delivery Hubs are active at the same time.

Important Note: At no point in time should there be multiple Delivery Hubs running on the same [Data Files] directory. Doing so can corrupt your data.

Backups
Making and restoring backups of your SDC deployment is simple. Aside from metrics data, all working data is stored as plain files in your Data Files location. Because of this you can use your standard file backup system to ensure you don’t lose data.

Restoring a backup simply requires you to stop your Delivery Hub, restore the files, and then start your Delivery Hub. It recognizes data has changed and broadcasts an event to running Admin Consoles to force them to update.

Mirror Support
Although the payloads for installation directives are very small, the content to be delivered can be larger than 1 GB. If your bandwidth is limited in certain regions, you can mirror the content into that region, and set up a mapping file.

You can mirror pack update sites, third party library update sites, and update sites required to provision SDC in-product plugins. These can be found deep within the installation path of packs. We will use a pack update site as our example; see below for examples of third-party update sites and runtime sites.

Mirroring a Pack Update Site

[Data Files]/packs/myeclipse-spring-12/v12.0.0.ga/updatesite

Using whatever technology your company uses for mirroring large content, mirror the updatesite folder shown above to your remote region. The path on your remote server should end with the identical path from the root of the [Data Files] folder. For example, let’s say you have a remote server with hostname remote.example.com, which has a data directory at /var/www/html, and let’s assume you want to mirror SDC content at:

/var/www/html/mirrors/sdc

You need to mirror the above pack updatesite folder into:

/var/www/html/mirrors/sdc/packs/myeclipse-spring-12/v12.0.0.ga/updatesite

Once completed, you can set up a mapping.xml file indicating to the Delivery Hub that content is mirrored. This mapping.xml file needs to be placed at:

[Data Files]/packs/myeclipse-spring-12/v12.0.0.ga/mapping.xml

The content of the file should look like (using the above example):

<mapping enabled="true" prefix-only="true" url="http://remote.example.com/mirrors/sdc"/>

If you are unable to mimic the full directory structure or you want to map directories in a different way, you can turn the prefix-only to false and give the entire URL to the updatesite directory:

<mapping enabled="true" prefix-only="false" url="http://remote.example.com/me-spring-12"/>

After making these changes, the Delivery Hub automatically picks up the mirrored location, and your online installers and in-product updates will locate the update sites and utilize them automatically. You can repeat the process with other update sites your organization needs replicated.

Mirroring a Third-Party Library Update Site

If you were to mirror a third-party library to the above location, the full path would be similar to:

/var/www/html/mirrors/sdc/third-party/0339-DuH-9951/0.13.0.201303011221/site

The mapping file would have to be located at:

[Data Files]/third-party/0339-DuH-9951/0.13.0.201303011221/mapping.xml

And the mapping file would look like:

<mapping enabled="true" prefix-only="true" url="http://remote.example.com/mirrors/sdc"/>

Mirroring a Runtime Update Site

If you want to mirror a runtime update site to the same location as in the pack update site example above, the full path should be:

/var/www/html/mirrors/sdc/core/sites/package-runtime/updatesite

The mapping file would have to be located at:

[Data Files]/core/sites/package-runtime/mapping.xml

And the mapping file would look like:

<mapping enabled="true" prefix-only="true" url="http://remote.example.com/mirrors/sdc"/>

Security Concerns

Support for Partitioning your Network and Running Over HTTPS
SDC has powerful support for partitioning your network. You can split the requests made by different pieces of the system through different logical networks or on different ports. To aid in this effort, you put an Apache (or other) web server in front of your Delivery Hub, and set it up to reverse proxy requests. All these configurations assume the traffic from your web front end to your Delivery Hub remains on a secure subnet.

The Admin Console’s System page – Advanced tab has a section for setting up alternate web mappings. For more discussion on web mappings, see Setting Alternate Web Mappings for Reverse Proxy Servers.

The simplest configuration is to use this setup to run all traffic over HTTPS. In this case, you set up your Apache with the required certificates to support HTTPS communication. Then you reverse proxy the requests from your Apache server to your Delivery Hub using normal HTTP requests. You can use a similar setup to run the Delivery Hub as a normal (non-root) user but have SDC communications occur over normal HTTP (on port 80) on your Apache front end. In either case, ensure that your Apache server is on the same subnet as your Delivery Hub so the communications between the two servers isn’t viewable outside of the secure subnet.

More complicated partitions can be accomplished, and you can even have your end-user traffic separated from your administrative traffic by having multiple Apache front-end servers or services. Consult your SDC representative to discuss your needs further!

Running the Delivery Hub as a Normal User
Some organizations do not allow services to be run using the root user. If your organization is one of these, there are some things you need to know about deploying SDC into these environments.

First, non-root users usually cannot open ports below 1024. If you want to run SDC on port 80, set up an Apache front end, and redirect it to your Delivery Hub running on a higher port (for example, 1305, the default port).

When installing as a service, the SDC Delivery Hub installer assumes it can write to the following directories. Users have worked around this limitation by running the installation as root and then modifying the files generated by the installer to be owned or executable by their operational user.

• /etc/init.d
• /etc/rc*.d directories
• user home directory

Alternatively, you can install the Delivery Hub as a user application and write scripts to make it fit into your environment.

The genuitec-sdc script generated in /etc/init.d assumes it can write to a number of different locations on the system. If you are running as a normal user, you need to edit the script to fit your use case. Also, note that you might need to write the script in such a way that it modifies files and starts the Delivery Hub process as your user (not as root). If you start the server as the root user, it will begin taking ownership of files and you will see random errors.

If this occurs, you can run the following commands to find files that need to have the owner changed back to your operational user:

find [path to your server directory] -uid 0
find [path to your data files directory] -uid 0

When in doubt, the following commands will clean up ownerships:

chown -R [your user id]:[your group id] [path to your server directory]
chown -R [your user id]:[your group id] [path to your data files directory]

Finally, some operational users do not have home directories. If your user does not, you can specify -Duser.home=<a substitute path> on a new line at the end of your deliveryCenterServer.ini file.

Appendix B: Installing on 64-bit Linux Servers

The SDC Delivery Hub is 32-bit software. On Windows and Mac OS X, you don’t need to do anything special to run the Delivery Hub on a 64-bit machine. However, on 64-bit Linux servers, you might need to install 32-bit compatibility libraries. Otherwise, you can run into server start up errors such as:

“deliveryCenterServer: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory.”

On some 64-bit Linux distributions, it’s as easy as adding the ia32-libs package. For Redhat distributions, there are good instructions to be found at: http://unix.stackexchange.com/questions/57863/how-to-run-32-bit-programs-on-64-bit-fedora-17.

Installation instructions can vary by server. An Internet search should give you the steps for adding the libraries to other distributions.