Hi Olivier, Some ideas are pretty interesting. Let's have a very quick look at them:
On 14.06.2011 23:32, Olivier LARRIGAUDIERE wrote: > I'm currently thinking about a new deployment tool software for Microsoft > systems (XP/Vista/7) like WPKG but with the following functions: > - Installed directly as a Windows service (no cscript) Well, there is actually not a big difference. Any service is at the end just a program. If you hard-code the whole functionality into a service or use "csript.exe" (or any wrapper of it) as a service does not matter much for Windows. A big drawback of a monolithic service is the update. Currently the client side installation is quite "dumb" and static in terms of functionality. WPKG allows extension of functionality by just replacing wpkg.js on server side with another version. No upgrade on client side required to add functionality for new concepts like LDAP support or similar. In case of a monolithic service you would have to update the service itself much more often. Updating a program itself is always a special task which is prone to errors - often just limited by the fact that you cannot simply replace a binary which is currently running. Sure update mechanisms can be put in place but if it fails you might lose the "connection" to the client which requires you to manually fix clients. And manually is exactly what you don't want to have when using a system like WPKG. Moreover such a service would have to be compatible with all supported OS. So you might have to compile it using multiple technologies (.NET 2.0/3.5/4.0? C/C++?) and make it work on all Windows editions. This can be pretty tough job to maintain regarding all the "messy" machines out there running broken runtime libraries etc. Moreover it would require some "bootstrapping". So all systems would require a certain level of software stack before applying such a system. Sure you can include all these dependencies in your installer but it makes it harder to maintain it. With WPKG you can start from an clean XP system (even without any SP) and run WPKG which will upgrade all components in one shot. Such things might get easier if you limit the support to "more modern" systems. Like limiting from the beginning that you will support Vista and Windows 7 (and their server counterparts) only. In such case you can even rely on .NET, PowerShell etc. > - Retrieve the list of the packages to be installed on the computer from an > HTTP > server (a PHP script that queries an LDAP directory to choose a database or > xml > file like Profiles.xml). The description of the packages could be an XML file > whose format is identical to WPKG. WPKG already supports reading profiles.xml, packages.xml and hosts.xml from HTTP server. > - Retrieving of files (installation programs) from an HTTP server 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. > - Signing packages and files to ensure they have not been altered and nobody > use > this tool to install other software. This is a very valid point. I already spent a couple of hours thinking about this. Unfortunately it's very inefficient to implement checksum/signatures in pure WSH scripting. Verifying the signatures of installers requires to download all files and verify the signature while some modern installers will not download all files if the custom setup does not require these files to be read. So signatures could slow down deployment. However it's true that currently a WPKG-enabled system can be cheated quite easily to just connect to a "fake server" making it download and install software updates from some intruder system. To prevent this it would require: - WPKG client to verify wpkg.js signature (and/or verify identity of WPKG server) - wpkg.js to verify signatures of each installer and related files -> The only way I know to do this efficiently is to use external hashing tools > - Sends the installation state through the HTTP server (a PHP script that > stores > information in a DB) WPKG writes the current state of installation into local wpkg.xml and also into the logs. Logs shall be written to some writable share anyway and can be analyzed. Alternatively a simple WPKG package which uploads wpkg.xml to the server for server-side analysis is also described in the wiki. I think WPKGExpress also supports showing client status on a web interface already. > The tool is divided into two parts. The service running on the computer and > the > script in PHP. Sounds like WPKGExpress (or the former WPKG-WEB). > The advantages I see in that new tools would include: > - Securing the installation packages As I said this might be difficult to achieve using pure WSH. > - Access to the installation status of packages in real time on computers -> WPKGExpress > - Ability to work with LDAP Since quite a while there is a modded wpkg.js with some LDAP support. It seems to be well-supported recently by Daniel Dehennin. However LDAP is still used by a minor user base of WPKG. Supporting features used by minorities always brings the risk of breaking something for the majority. Anyway, you might be interested in: <http://bugzilla.wpkg.org/show_bug.cgi?id=118> > Thank you for your feedback and sorry for my bad english. Nobody is perfect ;) I am not a native English speaker either but I always hope the community will understand most of my words... br, Rainer ------------------------------------------------------------------------- wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/ _______________________________________________ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
