[wpkg-users] Extended hosts matches

[Rainer Meier]

Hi Daniel,

On 29.03.2010 11:30, Daniel Dehennin wrote:
> Rainer Meier <r.meier at wpkg.org> writes:
>> - /applymultiple switch introduces complexity and breaks quite a lot
>> of existing installations if used without caution. Moreover there is
>> no scenario known to me which cannot be done without this
>> functionality using existing functionality.
> 
> The problem I see with the actual functionality is that when using
> extended host matches, I need to list all the meanfull combinations.

Not necessarily.


> I need a different profile for winXP and win7 system configurations, 
> If I want to use different profile for winXP and win7 both members of
> the appli1 group, I will need:
> 
> - <host system="xp" group="appli1">
>     <profile id='base'/>
>     <profile id='winxp'/>
>     <profile id='application1'/>
>   </host>
> - <host system="win7" group="appli1">
>     <profile id='base'/>
>     <profile id='win7'/>
>     <profile id='application1'/>
>   </host>
> 
> With /applymulti, this should become:
> - <host system="xp" profile-id="winxp"/>
> - <host system="win7" profile-id="win7"/>
> - <host group="appli1" profile-id="appli1"/>
> - <host name=".+" profile-id="base"/>

I personally don't feel this to be much less complex. On the other side I am not
fully against the "system" attribute - but I think it might be even more helpful
to specify it within the profile. This would allow to have only one single
profile with packages where some packages apply to XP only and others to win7.

However I never faced the issue where this would be really required. For example
I have a package called "internetxplorer" which currently installs IE8. This
package is assigned to all hosts. On Windows XP it just installs IE8 and on Win7
it just skips installation since IE8 is already there.

I also have a couple of other packages which simply do nothing on certain OS.
The install-script I call from WPKG does some OS checks and then terminates
gracefully or leaves some "marker" on the system which indicates WPKG that the
package installation was successful.

These kind of checks are much more flexible than WPKG ever will be. It allows me
to query registry values, files, call tools (e.g. ver | findstr) and prepare the
system accordingly.

This way it's not bloating WPKG just for a couple of exotic use cases.


However I am thinking about some basic OS version matching within the profile
(and maybe within the host database as well).



>> So feel free to create a patch for the current version of WPKG which might be
>> applied for these users who need it. I am personally OK with the delivery of
>> this patch even as part of the official shipment but I don't plan yet to
>> introduce this code in the stable release of WPKG.
> 
> I'll explain what I want to do, you will tell me if I'm crasy ;-)
> 
> We have 200 samba/LDAP servers so AD specific stuffs are out of
> question. We want to mix global and local policies, we found easier to
> manage LDAP entries than editing files or doing croned extraction.
> 
> We push generic configuration files with rsync, using only host names is
> quite complicated, for now we have a basic profile which applies to host
> name '.+'.
> 
> Using groups seems simpler than host name for policies, if we want to
> deploy a new profile, we want to:
> 
> - add a new group
> - assign computers to this group
> - send the profiles/<group>.xml
> - send the hosts/<group>.xml
> 
> In the future we plan to have pattern matching and references like:
> 
> - All groups can have associated profiles: <host group="(.*)" profile-id="$1"/>
> 
> We only need the following properties:
> - hostname
> - ipaddresses
> - hostsystem
> - hostgroups
> - username
> - usergroups
> 
> For now, I'm trying to use "WinNT://" to list group membership of my
> computer, I test the following js code:
> 
> --8<---------------cut here---------------start------------->8---
> var WshNetwork = WScript.CreateObject("WScript.Network");
> var DomainName = WshNetwork.UserDomain.toLowerCase();
> var ComputerName = WshNetwork.ComputerName.toLowerCase();
> var DomainComputerName = ComputerName + "$";
> var obj = GetObject("WinNT://"+DomainName+"/"+DomainComputerName+",user") ;
> var Groups = obj.Groups();
> for (var item =new Enumerator(Groups); !item.atEnd(); item.moveNext() ) {
>     var group = item.item();
>     WScript.Echo(group.Name);
> }
> --8<---------------cut here---------------end--------------->8---
> 
> This does not require LDAP stuffs, the only thing I wonder is if it's AD
> compatible.

And here the bad side-effects usually start. There is only a very limited number
of people out there able to read and test this code. Debugging will get harder
and changes to break something increase. More over we know that WSH is not
supported by Microsoft any more. It might happen that WSH scripts will not get
access to specific objects in the future if Microsoft changes the security settings.

As I said accessing LDAP/AD from WPKG introduces a change in the basic
architecture. Remember that wpkg.js is executed on the client. Currently in most
installation the only communication done by wpkg.js to the servers is SMB/CIFS
file system access (fetching XML, fetching data). Adding LDAP/AD support
requries WPKG to communicate from the client directly with LDAP servers. This is
pretty likely to introduce issues with firewalls and other network issues.
What is also not clear to me is the way AD is accessed. As far as I know AD does
not allow anonymous binding. So either WPKG has to read credentials from
config.xml or get it via parameters. Parameters is a bad idea since updating the
credentials would require deploying new settings to all clients. But config.xml
would also be critical since the credentials would have to be protected because
they might be abused to get access (at least read-only) to AD.

In any case this second communication channel to servers for sure introduces
quite a lot of potential problems.
If we start to support it I am sure users in larger-scale installations will
also ask for advanced features like load-balancing and fault-tolerance/fallback
on LDAP servers.



> Can someone with an AD test it and tell me if it works?

I can't - no AD operated here ;-)


>> For Version 1.2 I plan to restructure quite a lot of code where it might be
>> possible to extend the functionality - maybe by referring to eternal scripts.
> 
> Is it possible to have a look at development?

I am sorry, not at this stage. Unfortunately I am fully loaded with other duties
at the moment so this code redesign has quite low priority for me at the moment.
WPKG 1.1.x is the current stable branch and remains stable for a while.


> What do you think about the following (standard?) SVN layout:
> - trunk : development
> - branches/X.Y/fix#: X.Y bugfix development branch (copy of X.Y.Z which introduce the bug)
> - tags/X.Y.Z: stable branch

The current-development and stable branches already exist. The only difference
would be to have branches for specific "fixes"/"changes". In any case these
branches would be quite independent from the current stable branch.
At the moment Bugzilla contains some modified versions and patches to existing
versions.

Personally I would be fine to create a "branches/1.1/enh-118-ldap/" branch to
check in the modified version. Alternatively we might add a patch to the
official distribution which might be applies by whoever likes to use this
modification. The problem with patches is that specifically Windows users are
not very familiar with it. So the branching might be easier to handle. Modified
WPKG versions might be downloaded from the branches/X.Y/... tree from
sourceforge directly.

So if you finish a modified version of wpkg.js we might add it to the repository.


> I know that wpkg.js is intended to be used as-is with the blending edge
> version, but I think it's a good thing to publish non-finished
> development and actual stable, people will use what ever they want/need.

Unfortunately people will use any version they can get from any source ;-)
People are usually also lazy to upgrade. That's why I've started a poll some
time ago to discontinue version 1.0 since it's completely replaced by 1.1.

As soon as there are some branches available there will be a couple of people
asking for maintenance of these branches. Maybe you will be able to keep it
synchronized.

Personally I think it would be OK to put this branch in the repository and
letting you maintain it. If it turns out that your version is very stable and
finally more people are using the modified version with LDAP support than the
one without then we can re-discuss about a merge of both branches and official
support of the change.

So fell free to go on preparing your modifications.


br,
Rainer