[wpkg-users] Extended hosts matches

[Daniel Dehennin]

Rainer Meier <r.meier at wpkg.org> writes:

> 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

[...]

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

My version specific stuffs are mainly windows configurations (services,
network settings, firewalls, …) some of them which works on winXP does
not on win7.

> 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.  

I'm not sure to understand everything but GetObject("WinNT://") does not
use LDAP (that what tcpdump told me), so no need to configure base-dn,
bind credential, I think that what ever backend you have
(samba/openLDAP, AD, NT4) it should work.

> 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.

I define tow functions getDomainName() and getHostGroups() in wpkg.js, I
call getHostGroups just after main:saveEnv().

The attached JS script define the tow functions and permit to test
without running the whole wpkg.js, I saw that:

- getHostGroups works only if:

  * we have a SMB/CIFS connection to a server

  * the computer is defined on the server: no need to join the
    workstation to the domain ("smbldap-useradd -W <computername>$" is
    sufficient)

- getDomainName returns:

  * The domain name of a domain member with WMI

  * The configured domain (TODO: use config.xml to define it) if the
    workstation is not a domain member

Again, it needs some tests against AD.

Does it look more acceptable to you?

Regards.

-- 
Daniel Dehennin
RAIP de l'Orne

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: getHostGroups.txt
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20100331/35a99b24/attachment-0002.txt>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.wpkg.org/pipermail/wpkg-users/attachments/20100331/35a99b24/attachment-0001.sig>