OCS Inventory is an excelent piece of GPL Software for getting info from hardware components, and software installed on computers running Windows or UNIX-like operating systems (there are also some unofficial clients for running on other platforms).

Since New Generation (OCS-NG), a new architecture was implemented: server were contacted using standard TCP/IP connection (Previous versions, used an MDB file to store information, and required a SMB share to inventory computers ), allowing remote computers to connect as well as providing a new web interface for computer administration, and inventory query.

Within new features, a new small client (about 64kb), was able to contact inventory server, and download from it the full set of required files (OcsAgent.exe) which was expanded to %SYSTEMDRIVE%ocs-ng, then executed, an inventory sent to server.

This approach had a little problem, if you had a small outgoing connection, serving a 700 Kb file was painful… but at least, despite some minor revision changes, machines were able to upgrade automatically (In many other times, you had to manually redeploy or force with the /DEPLOY:#VERNUMBER# the new deployment) when new version was deployed on the server.

With RC3, agent for installation uses near double that size, about 1.5 Mb, but the ability for after first installed, use external servers with a bigger upload bandwidth, eases installation of new versions in computers.

I’ll assume that you’ve running Apache, PHP, and were able to setup OCS using the bundled instructions, so you only have to enable new features for using package deployment.

First of all, we need SSL support in Apache.

Package deployment infrastructure, is too much powerfull, so it requiress SSL access to validate server before trying to download from it, so… we’ll need some SSL certificates for use with our server.

I like http://www.cacert.org services: they sign your certificates, and provide one certificate aiming to be used with many FOSS projects, because it’s free instead of paid certificates like the ones from Thawte or Verisign.

First of all, we need to create a private key and a CSR (Certificate Signing Request) which we will send to CACERT for signing (please, note that if you don’t have a domain name, will make it impossible to use OCS Package Deployment if your IP is also dynamic, so if that is your case (as was mine too), open an account at No-IP and create a URL-Redirector to your machine, you’ll have to install an update client, but this will allow you to use certificates) it.

Having openssl installed, we will execute (please, double check that questions, specially CN exactly matches ServerName and “hostname”, for it to work properly after) the following commands:

For being able to use http://www.cacert.org services, we’ll have to create an account and add a domain to it, this is verified sending an email to an account like webmaster, root or so, clicking on the supplied link, will entitle to work in representation of that domain.

After that, Cacert.org will show you a certificate for your server that you’ll have to copy to a file called “server.crt”.

Each of them has different behaviour, one runs a command, the other downloads a file and stores it on a folder, and the other does a combined thing: downloads a file, unzips it, and then runs a command.

For Package creating, we must have write access to Apache’s DocumentRoot/download folder, and after creation, copy contents of “/download” to “/”, or as I did, gave write access to “/var/www”, and create (ln -s . download) a symbolic link for download.

So… let’s create a first package:

We must login into OCS Web interface, and select (first menu option on first yellow icon) package creation

We must assign a name for the package, Platform, Protocol and Priority (priority will allow us to decide package execution order in the client, the lower number, the higher priority)

If we’re going to upload files, we must ZIP it BEFORE, so OCS will unzip on client machine, and then run commands

We choose an action, and then, a path (we can use system variables like %SYSTEMDRIVE%, %TEMP%, %USERPROFILE%,%PROGRAMFILES%, etc) to store the file, or command to run

We can choose if we want the user to be warned about package execution, and even to allow user to delay execution (useful for service pack deployments, etc)

Next step, will allow us to specify fragments (pieces in wich the package will be splitted for allowing better deployment, making use of redownloading for only failed fragments, etc), as well as checksum for data validity

Once a package has been defined, we have an “info” file, describing package actions, and package fragments, we can have them together or split it between different servers, and we will have to specify where is located each piece, before using it on our machines. That process is called “Activation”.

When we select that option, we have to specify the pkgid, so we use the second menu entry in the package deployment icon, and we’ll get a list of packages ready for activation, and then, we select “Activate” from the one we’re interested in.

On package activation, we will be asked for two SERVERS (thanks to the development team, specially to Pascal who helped in determining that we require to specify server name, not URL) one with https (for downloading info file) and one with http for downloading fragments (if any).

After sending server names, OCS will check availability of “info” and fragment files (if any (On RUN packages, there is nothing to download prior to running the commands) and then, package will be activated and ready for next step.

Packages from client side, are as easy to setup, as having a working OCS Agent Service installed and a file called cacert.pem, which we got from the SSL Creation step… having them in the OCS Agent folder, and a package affected to a computer, will make computer to download, and do the actions specified. ¿What are the pro’s and con’s of this method?

When installing OCSAgent, using: OCSAgentSetup.exe /S /SERVER:yourserver.no-ip.org, we have no cacert.pem file copied, so we must copy it by hand, or, as I did, use a scriptable install system whicho does this in one step.