Changes

Jump to: navigation, search

How WPKG works?

3,361 bytes added, 22:00, 6 November 2009
no edit summary
=Overview=WPKG keeps its configuration in three XML files, is a script-driven installation engine for applications. Its main logic is contained within the wpkg.js file which can is to be changed easily run on each client in an editor like ''vi'' or ''mcedit''a priveleged user context. It can run a number of checks (i.e. check against file versions, file existence, uninstall entries, registry entries or even automaticallythe return value of an arbitrary command) and trigger arbitrary installation commands depending on the result.
These It allows you to build dependency trees of applications and keeps an own package database for each client in order to be able to be smart about changed package definitions and package removals. Evaluating this information will allow you to stay informed about the installation progress for your clients. =Configuration=WPKG configuration is kept in four separate files or are included from subdirectories. The files define configuration options in XML syntax and can be changed easily in any text editor. You may even choose to generate some of them automatically. These configuration files are:
* [[hosts.xml]] - defines the hosts and associated profiles, which these hosts will use,
* [[profiles.xml]] - defines the software packages or scripts, which will be installed/executed on hosts,
* [[packages.xml]] - defines how to install and uninstall software packages. In other words, it is a list of all applications and scripts that can be deployed or executed on workstations.
* [[config.xml]] - global WPKG configuration options
There is also one more file, [[The main configuration files and the JScript "engine" (wpkg.js]]) need to be located in the same directory. In order to keep definitions for hosts, which we can call a "WPKG engine"profiles and packages better organised in larger environments, they may be distributed among several *. It is written xml files in JScriptsubdirectories named "hosts", "profiles" and is executed by the workstations"packages".
All these XML files == Server software (hosts.xml, profiles.xml and packages.xmlSamba or Windows file server) and the JScript "engine" (wpkg.js) should be located in one directory.==
 === Server side (Samba or Active Directory) === You don't have to run any additional software The only thing you really need on your Samba or Active Directory the server to use side when using WPKGis the file service.<br>You only need Basically, a share, is needed which is accessible by the all workstations, with the files used by WPKG: [[and accomodates wpkg.js]] ("WPKG engine"), [[hostsand the configuration files.xml]] (host namesFurthermore, which will use WPKG), [[profiles.xml]] you probably would want to have some share for your program installation sources (profiles available to hostscopies of the installation media for your software) and [[packages.xml]] (applications might consider having some network-accessible directory to store copies of the client-local package databases and scripts that can be deployed or executed on workstations)WPKG log files to facilitate later evaluation of installation progress and the collection of errorsOf courseActually, you also need a folder where you will store your applicationssince Windows natively supports WebDAV on from Windows XP, scripts etc. - in other words - everything that you need are not limited to install or run on your workstationsSMB, but can use WebDAV servers as well.
'''Note:''' Make sure that your server is not providing any SMB-based services (eg, DC, shared printer or shared folder other
CNAME or IP address to refer to the server in the WPKG Client.
=== Client side software (Windows workstations) ===
Your Windows workstations will not be aware of WPKG on the client side is just because you created an additional share on executed JScript file - it needs no further software to run as such, although your Samba serversoftware installers might require additional components (like Windows Installer 3They need to be told to use WPKG first0)All There are plenty of ways how you need to use might run WPKG on - take a Windows workstation look at [[Installation instructions - advanced]] for some ideas of how it can be done. However, the [[WPKG Client]], a client-based service, should be appropriate for most basic needs. The basic idea behind all approaches is to run a command like belowthis is executed on the client machine at some convinient point in time (typically at startup):
<code>cscript \\server\wpkg\wpkg.js /synchronize /quiet</code>
 
All this is done with [[WPKG Client]].
 
When WPKG is called on a Windows workstation with these options, it will do the following:
Of course, WPKG has many more options. See [[WPKG flags]] for details.
 
You will likely run it manually as a local or domain Administrator when you would be still testing WPKG<br>
When WPKG is installed, it runs and installs software automatically in the background, whenever the workstation boots up, even when no one has logged on to that PC.
=Missing functions=
WPKG cannot do everything (yet). Among the things it does not do are the following:
 
=== Installation of the Operating System ===
WPKG comes into play after the O/S is installed and running. For everything before that use approaches like [http://technet.microsoft.com/en-us/library/cc766320(WS.10).aspx RIS/WDS] or [http://unattended.sf.net Unattended] for automated network-based installation of the O/S)
=== "Software push" functionality ===
WPKG is a client-centred approach to software installation, so it does not support "pushing" software. However, you are free to issue Remote Procedure Calls to clients in order to trigger the start of the WPKG service or even directly the start of the WPKG command
===Software repackaging===
WPKG is about scripted, unattended installations. In our experience, repackaged software while running fine most of the time, might cause obscure problems in rare cases and leaves the admin standing without any reasonable support from the software companies creating the packages. [http://unattended.sourceforge.net/installers.php#repackaging This article at unattended.com] elaborates some more on this matter.
===Integrity or signature checking of installation packages===
This is a security feature and while surely a valuable gain, nobody has yet been found to implement it.
===Multicast deployments===
Multicast transfers would be very valuable in narrow-bandwidth environments with shared media and a large number of clients - typically large wireless networks or networks connected through a narrow link (e.g. a 10 Mbps laser link). WPKG uses file services and installs software packages synchronously, using multicast would necessarily mean a different approach to file transfers and asynchronous installations. Anyway, a lot can be done using a local caching directory, a multicast transfer daemon like [http://www.tcnj.edu/~bush/uftp.html uftp] and some intelligent scripting combined with WPKG.
[[category:Documentation]]
Anonymous user

Navigation menu