[wpkg-users] Reflections on a new application deployment software.

[Rainer Meier]

Hi Olivier,

On 15.06.2011 01:18, Olivier LARRIGAUDIERE wrote:
> I agree about this point. My idea is to allow the update over internet that is
> why I am privileged operation only via HTTP. It must still be possible to use
> wpkg.js locally on the computer.

As specified WPKG also allows downloading files via HTTP (including XML
specification as well as software packages). So strictly speaking it's not
required to use any SMB share. Even wpkg.js can be either placed locally or
downloaded on each run from an HTTP server. You can even do this with the
existing WPKG client. Just run any program/script instead of wpkg.js directly
from a share. This tool shall then download wpkg.js and execute it.



>> WPKG supports download feature. However downloading installers via HTTP also
>> requires another component in the whole system (the HTTP server) and imposes
>> more issues like verifying download, when and how to cleanup downloaded files
>> etc.
>> Personally I think fetching files from SMB/CIFS/SMB2 shares which are natively
>> supported by Windows is more stable.
> 
> I want to allow update over internet so no SMB/CIFS/SMB2.

As written it is possible to use WPKG with HTTP servers only.


> Maybe it's possible do develop a tool called by wpkg.js to verify the sign ? So
> WPKG client verify the wpkg.js signature and for each package to install wpkg.js
> call the specific tool who verify if the sign is correct ?

In fact to secure a client you would need to secure the whole chain:
- Service downloading wpkg.js:
  The service would have to verify the signature of wpkg.js. For this to work
  wpkg.js would have to be signed with a secret private key and WPKG client
  would require to know the public key.

- wpkg.js downloading installers:
  wpkg.js would have to verify the signatures of each XML file. For this XML
  files would have to be signed by private key and the public key to be placed
  in wpkg.js. Verification of XML files would probably require to copy them
  first before verifying the signature. Calculating hash values and signatures
  might be too slow in WSH, so external tools might be required.

  wpkg.js would have to download each installer file. Then before executing
  anything it would have to verify the signature. The download would in some
  cases significantly increase the required traffic. In addition the same
  problem as with XML files applies: WSH is weak at hash and signature routines
  so external tools might be required to perform the verification.

All this verification requires a lot of resources and bandwidth. I personally
think it might be better to start at a lower level by verifying connection to
trusted WPKG and software shares only (enforcing encryption too). Well I am
mainly using Samba but I think with Windows Servers it would be possible to
verify server identities too (at least in domain environments where there is
some trust relationship between servers and clients).


> Not exactly in fact in my first view there is 3 parts. The windows service, the
> PHP script called by the windows service to retrieve the list of packages to
> install for the specific computer and also update the computer state (last sync,
> last boot, ...). And another tool like WPKGExpress.

Last sync can be fetched from WPKG log files. Sync errors as well. Writing this
logs to a share or even upload it via post-run script shall not be a blocker
issue. Monitoring the client operating system for reboots etc. is not core
functionality of a software deployment tool. There are many monitoring and
management tools which are dedicated to do such thing.


> With my idea of a PHP script dedicated to providing the list of packages to
> install for the specific computer it's possible to have multiple addons (one who
> read informations from LDAP, another read in a mySQL database and another in a
> profiles.xml file. With this everyone has the choice with less impact in the
> main source code.

This sounds a lot like my initial proposal for this "LDAP question" which first
popped up several years ago. I did initially propose that some web-service
gathers LDAP information and transforms them into XML files (mainly hosts.xml
and profiles.xml) and serves them to wpkg.js requests via HTTP. This way the web
service could not only be more flexible (like plug-in back-end system to support
LDAP, SQL or any other source of information) but also gets rid of some load on
the LDAP servers and simplifies wpkg.js. Stuffing more and more functionality
into wpkg.js seems not to be the best way from my point of view. The reason is
simply that the more complex wpkg.js gets the more complex code is distributed
and run on distributed clients. So errors in LDAP access and similar issues are
spread among many clients instead of centralizing it to one system (the WPKG
LDAP-"bridge" which just serves XML over HTTP).

So instead of having wpkg.js connecting to various back-end systems like LDAP,
SQL or SMB shares to get its databases it would only connect to a web service
which builds these XML files dynamically from information it fetches from any
type of back-end. It would also allow to use more modern programming
technologies in the back-end to access these databases. For example I would not
even like to imagine doing direct Oracle SQL access from wpkg.js to get profile
information. Doing this on a web back-end however is very easy.

Using such a back-end system (yes, might be written in ASP .NET, PHP, J2EE,
Perl, Python, SH or anything else) would even allow to create XML files specific
for the requesting host. For example packages which are not assigned to the host
might not even appear in packages.xml served to the client, thus saving some
bandwidth.


However at least for the LDAP story it seems that mainly Daniel enforces the way
to go for a very complex wpkg.js distributed to clients.

br,
Rainer