Repo Layout¶
In SoftwareAssistant, a repository (repo) is a database and folder hierarchy used to manage a class of computers. This includes a catalog, packages, installers, a certificate authority, and an admin/api interface.
Each client must have a primary repo configured, and it may have additional secondary repos configured as well. The client connects to the API in the primary repo only, secondary repos are used only to add additional packages and actions. All repos must exist on the same server so the API can access their catalogs.
As an example, a department may setup a primary repo for the software it has purchased, and use a secondary repo for the software purchased by the larger organization. This way, departmental computers will have access to all departmental and organizational software, while organizational computers will only have access to the organization's software.
Catalog¶
The repo catalog is a single XML file that identifies every package and action available in the repo. Packages usually describe an application, and contain actions such as 'install' or 'uninstall'. The catalog is used by the client when the GUI is displayed, and by the server when an action is in progress.
Only one catalog is allowed per repo, but multiple repos can be added to the client and server. Catalogs from different repos are merged in the order they are configured, and package names must be unique or only the first package will be loaded.
See the catalog configuration page for all the options.
Packages¶
SoftwareAssistant uses packages in order to get things done. Usually packages are simple scripts with an 'install' and 'uninstall' parameter defined. If a package requires multiple files, a zip file can be used for the package.
It is preferred to use script based packages along with installers because they are easier to update as new versions of the software are released. Zip based packages are much more involved to update.
Each package must have a matching section in the repo catalog. This section describes the package and its requirements.
Installers¶
Installers are usually just the file you download from the internet to install some software. Keeping the installer separate from the package script means updating software is as simple as replacing the installer with a newer version.
Installers must follow a specific naming convention with the version in the filename. This allows SA to detect when new versions are available for installation.
Each installer must have a matching section in the repo catalog. This is how SA knows which installers go with which packages, and when new versions are available.
The Certificate Authority¶
Each repo uses a small Certificate Authority (CA) to identify both the server and the clients (Mutual TLS). During the repo setup, a root CA is created and used to sign the web server's certificate, and one or more client certificates.
During normal operation, the web server validates that every connection is using a certificate chain signed by the root CA. At the same time, the client also validates the web server is using a certificate chain that was signed by the root CA.
No cleartext or alternatively signed certificates are allowed.
Admin/API Interface¶
Each repo has a unique instance of the server API and admin interface. This is convenient for isolating reports and preapprovals for difference classes of computers.
To extend our example above, computers assigned at the department level may want a certain set of software installed during provisioning, while computers assigned at the organization level may want no software installed during provisioning. Since machines are usually not assigned an OU at provisioning time, this would be a convenient way to differentiate them.