[wpkg-users] [wpkg-announce] WPKG 1.1.1-M3, lots of new features

Rainer Meier r.meier at wpkg.org
Mon Apr 7 16:00:56 CEST 2008


Hi Tomasz,

Tomasz Chmielewski wrote:
> My spam filter catches loads of mails which advertise pills - should I
> forward some of them to you for your sleeplessness problems? ;)

But viagra probably just helps to stay awake for even longer :-)


> I wonder how could it help in a situation described below (or, perhaps, 
> a "reversed" type of such check; "conditional profile").

In fact for this purpose I don't like the idea too much due to several 
reasons:
- Script to be executed is machine-local/untrusted
- Such scripts are prone to errors
- Due to the fact that the script is typically stored on the client 
machine it is easy to "lose" the machine within the package management 
if something happens to that script.


> A classroom of workstations - logically, they should go into one profile.
 > Workstations are different hardware models.

OK, so they belong to the same profile, except the hardware driver packages.



> WPKG could be used to deploy drivers on these machines - but some driver 
> installers will just bail out and go to interactive, GUI mode if they 
> are being installed on different hardware (a.k.a "No compatible hardware 
> found, click OK to exit silent mode").

Yes, I know similar problems.


> How do we get around this problem? Creating additional profiles is a 
> no-go - hosts have either similar IP addresses or hostnames.

OK, this is a problem which could be solved at setup - I leave it up to 
Windows to generate a hostname with specified prefix at setup usually. 
However it's too late for you probably to change this.


> To get an idea, see http://wpkg.org/HP_drivers - it shows silent 
> installers for a HP nx6325 laptop drivers. There are several of these 
> drivers, and they should only be installed on nx6325 laptops.
> 
> 
> I put a compiled dmidecode.exe binary on http://wpkg.org/Download - it 
> can output such data which helps us identify hardware:
> 
> prompt> dmidecode.exe --string system-product-name
> HP Compaq nx6325 (EY345ET#ABD)

So there is a very easy way to check if the driver should be installed 
or not.


> Of course, it can be wrapped in a script which would exit with a 
> specified exit code.

This is exactly what I would propose here. I would simply create 
packages for _every_ driver used in _any_ of the supported hardware 
devices and apply them to _all_ clients.

Then wrap the drivers with a script as follows:

@echo off

set SP_INSTALLER=spXXXX.exe
set INSTALL_LOC=%~dp0
set EXIT_CODE=0


for /F "tokens=4" %%i IN ("dmidecode.exe --string system-product-name") 
DO set MODEL=%%i

if "%MODEL%" == "nx6325" (
   goto install
)
goto end

:install
REM RUN YOUR INSTALLER HERE
start /wait "drivers install" %INSTALL_LOC%%SP_INSTALLER% /s
set EXIT_CODE=%ERRORLEVEL%
goto end

:end
exit %EXIT_CODE%


Just call it - on machines where it applies to it will install the 
package (and even exit with appropriate installer exit code). On all 
other systems it is simply skipped. Here I suggest to use the 
execute="once" flag on package definition level. This makes sure the 
installation takes place only once. On machines where it is skipped WPKG 
still assumes that the package is installed properly (exit code 0, no 
checks defined within the package).


>  <host name=".+" profile-id="default">
>   <type="execute" path='\\path\to\script.bat'
>          condition="exitcodeequalto" value='0'
>          depends_profile="laptop_model_A" />
>  </host>

As I said - it is probably not the best idea from my point of view. And 
especially I see that it is already possible to create packages which 
will work even without modification.


> \\path\to\script.bat would be started on each wpkg.js start - if exit 
> code matches, a given profile would be applied to that host.
> 
> Does it sound sane?

Slightly insane? ;-)
No. Well, I will think about it - but no priority on it, especially 
since there are numerous ways to achieve it already with current 
implementation.


> Right now, some ugly scripting seems to be needed, which doesn't really 
> give benefits of WPKG.


Ugly? Scripting is perfectly nice. You can do scripts in a very generic 
and clean way. In fact WPKG is also nothing more than a script (Java 
Script). I love scripting very much. It is simple, flexible and very 
very transparent - everybody can see what a script is doing (usually). 
Nothing to hide.

br,
Rainer



More information about the wpkg-users mailing list