Hi Kai,
On 21.10.2011 18:14, Kai Pastor wrote:
> Hello,
>
> I am testing WPKG 1.2.1-RC27 and have not seen any problems. Thank you very much
> for your work.
Great news.
> So far I have also used WPKG Create Report which is linked on the download page.
> This useful tool is not yet aware of the new features and the changes in the
> syntax. I guess that will take quite some effort and time for implementing an
> update to this tool.
>
> I wonder if wpkg.js should include support for those kind of tools. Wpkg.js
> already implements
> - parsing the configuration,
> - reporting packages which are installed or to be modified (/query:im),
> - accepting a hostname parameter (/host:myhostname).
>
> The next step could be to
> - have a parameter for supplying the path of a local settings file which is to
> be analysed,
> - print (or save to a file) an XML report of host attributes and of packages
> installed or to be modified.
I've just checked in an extension to WPKG (version 1.2.1-RC28) which implements
a new argument: /settings:<path>.
Using this path you can tell WPKG to use another settings XML file. Therefore
you can write a tool now which uses a copy of the local wpkg.xml (or even assist
your WPKG to write the file to a share directly, but this was already possible
using config.xml).
This way if you have the setting databases of all your clients you can query the
status of the clients using these copies and parse the output of wpkg.js.
I hope this simplifies the creation of reporting tools. Using wpkg.js to query
the raw data for reporting will make sure that future feature improvements do
not require the reporting tool to be adapted.
> Than it should be much easier to maintain a stable tool to create a summary
> report for a collection of computers.
Note that I did not yet prepare any reporting tool and I will likely not focus
on this. If you build one feel free to contribute.
Change log:
NEW: Added /settings:<path> command-line parameter. It allows to specify an
alternative path to the settings file on command-line rather than
specifying setings_file_path and settings_file_name in config.xml.
Note: /settings:<path> takes precedence over config.xml settings.
/settings:<path>
Path to the settings (local WPKG database) file to be used. The path might
be absolute or relative but including the XML file name. This parameter is
entirely OPTIONAL and should normally not be specified at all.
If not specified the settings file will be searched at:
%SystemRoot%\system32\wpkg.xml
e.g. '%SystemRoot%\system32\wpkg-custom.xml'.
e.g. '\\\\server\share\directory\\[HOSTNAME].xml'.
If you store the settings file on a share make sure the names is unique!
You can use environment variables as well as the following expressions:
[HOSTNAME] Replaced by the executing hostname.
[PROFILE] Replaced by the concatenated list of profiles applied.
This feature will potentially ease reporting as settings XML files stored
on a share can be queried against the host database using wpkg.js
directly. So no duplicated code with external tools is required to
determine whether a package is scheduled to be changed.
Thanks to Kai Pastor for the hint.
<wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/stable/1.2/>
br,
Rainer
|
|