[wpkg-users] New WPKG features vs. report tool

[Rainer Meier]

Hello again,

On 22.10.2011 01:37, Rainer Meier wrote:
> I've implemented /query:s and /query:l to query these tags from the (l)ocal host
> or the (s)ettings database and print it on screen. So a reporting tool could
> point it to a settings file using /settings:<path> /query:s to fetch all host
> attributes.

Actually I've discovered that the whole story is a whole lot more complex than 
I've initially expected.

I have noticed that the query on a remote host (e.g. your server) will never 
yield the same results as on the local client. The reasons for this are:

- WPKG needs to have all host attributes to be set exactly as on the client:
   - hostname
   - IP addresses
   - architecture
   - ...

- WPKG also executes package checks in order to verify whether a package needs 
to be re-installed (e.g. package installed and added to wpkg.xml but user 
removes it meanwhile, so WPKG re-installs it).
In such case WPKG would often report a package to be scheduled for installation 
on a remote node since the checks fail as long as the package is not installed 
on the remote node (server) as well.


To work around this issue I've introduced a new switch called /queryMode which 
takes the "remote" attribute: /queryMode:remote

In "remote" mode WPKG will change its behavior in some special cases:

- WPKG reads all host attributes from the settings node (wpkg.xml)
- WPKG does not perform checks whether the package is still installed
   - it just assumes the package is still installed correctly when dong the query
     on server side.

NOTE: Remote mode is only effective if some query is executed, it is ignored 
during synchronization etc.


Change notes
============

Changes 2011-10-22, v1.2.1-RC30 by Rainer Meier <r.meier (at) wpkg.org>
NEW: Added /queryMode:<local|remote> command line switch and remoteMode
      configuration parameter. This switch is used to create reliable queries
      on expected changes to a host when running WPKG on a remote node.
      For example when you copy wpkg.xml of a client to your server and use
      wpkg.js /query:im /settings:local\wpkg.xml
      just to query the impact of the next synchronization to this client.
      IN this case WPKG needs to know the host attributes like hostname, IP-
      addresses, architecture etc.
      In remote query mode WPKG will read these values from wpkg.xml (if
      available, check that settingsHostInfo parameter in config.xml is
      enabled).

      Here's a description of the new parameter as added to config.xml:
           Allows to switch to remote mode where package verification is skipped.
      remote: Disable package checks and assume that packages in settings
              database are still correctly installed. In remote mode also the
              host information is read from the local settings database.
      local:  Default setting. Query verifies package status using all checks.
      Note: Query mode can only be used with the query switch. It is ignored
      if no /query: command line parameter is used.

      Details: If you intend to copy the local wpkg.xml file to a remote system
      and execute WPKG queries based on this settings database (wpkg.xml) then
      WPKG might print some packages as "required for installation" since the
      package checks fail on the remote host as the package might not be
      installed on the remote host. If remote mode is enabled, then WPKG assumes
      that the packages are properly installed on the executing host without
      actually verifying it.
      Of course it might happen in this case that a package query on the remote
      system says that a package does not need any change but on the real system
      the user might have removed the software meanwhile which will trigger an
      installation if WPKG is run on the client.

      Also note that in remote query mode WPKG will read all host attributes
      from the settings file (wpkg.xml) if these attributes are available. This
      includes hostname, architecture, OS, IP addresses, domainname, groups,
      LCID of the executing user and LCID of the operating system.
      This is required in order to allow evaluation of all conditional
      attributes in exactly the same way as it will evaluate on the client.



Oh, it's 3:30am now, I guess I've broken a lot in the code, but we have SVN. 
Talk to you tomorrow...

br,
Rainer