[wpkg-users] configuration and change management (ccm) with wpkg: how?

[Holger Kröber]

Hi,

often, after youÂŽve deployed a package some changes or modifications are
required for this package.
E.g. you have to (re-)configure the proxy settings for firefox etc.
I think that most of you implement change and config managment (ccm)
directly inside the package of the application itself.
But what happens, if you already deployed the package and then you have
to configure some settings for this package later?
The way wpkg works, you would have to modify the app package, add some
check conditions (e.g. with firefox: check file
exists mozilla.cfg etc), increase the revision number and....accept that
wpkg will reinstall your complete application/package
and not just only makes the desired configuration changes. Maybe itÂŽs ok
for you with a small package like firefox - but there also exists big
software.

So i am searching for a way to avoid a reinstallation of a already
installed package while deploying new settings for this package.
My first thought was to outsource the ccm into a new package
(firefox_ccm) and then chain this package to the app package (firefox-esr).
This will work if the app package is installed for the first time. If i
later update the ccm package (because i have to deploy new settings) and
increase the revision number for both packages and then call the app
package, the chained ccm package will be ignored.
I use precheck-upgrade="always" in my packages - if i remove this line
the chained package will not be ignored - but than i will have
again the problem that the complete application reinstalls. So i guess
that chained packages only work in install-mode, not in upgrade-mode
when using precheck-upgrade="always". Maybe i have to use a different
approach...

How you guys manage ccm in your environment? Got some tips for me?

Thanks,
Holger

[Marco Gaiarin]

Mandi! Holger Kröber
In chel di` si favelave...

Post by Holger Kröber
How you guys manage ccm in your environment? Got some tips for me?

Simply i define some '-settings' recipe, and if they are strictly
needed i include them in the main recipe; the settings recipe always
depends on the main one.

Eg:

<package
id="syslogagent"
name="SyslogAgent"
revision="3.6:1"
reboot="false"
priority="50">
<include package-id="syslogagent-settings" />

[...]


<package
id="syslogagent-settings"
name="SyslogAgent settings"
revision="20130207:1"
priority="5"
reboot="false">
<depends package-id="syslogagent"/>
[...]
--
dott. Marco Gaiarin GNUPG Key ID: 240A3D66
Associazione ``La Nostra Famiglia'' http://www.sv.lnf.it/
Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN)
marco.gaiarin(at)lanostrafamiglia.it t [phone] f [phone]

Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA!
http://www.lanostrafamiglia.it/25/index.php/component/k2/item/123
(cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/

[Dafydd Jones (techneg.it)]

Holger,

looking at your ccm package, the issue is how you differentiate config
versions.
You use an exists check, but the file already exists. I use a filesize
check, because when I change a configuration that often changes the file
size, and when it doesn't I add some extra comment. You could also compare
the date of a file.

On upgrade, you only increment the config package revision number, not both.

HTH,
Dafydd

Post by Holger Kröber
Hi,
often, after youÂŽve deployed a package some changes or modifications are
required for this package.
E.g. you have to (re-)configure the proxy settings for firefox etc.
I think that most of you implement change and config managment (ccm)
directly inside the package of the application itself.
But what happens, if you already deployed the package and then you have to
configure some settings for this package later?
The way wpkg works, you would have to modify the app package, add some
check conditions (e.g. with firefox: check file
exists mozilla.cfg etc), increase the revision number and....accept that
wpkg will reinstall your complete application/package
and not just only makes the desired configuration changes. Maybe itÂŽs ok
for you with a small package like firefox - but there also exists big
software.
So i am searching for a way to avoid a reinstallation of a already
installed package while deploying new settings for this package.
My first thought was to outsource the ccm into a new package (firefox_ccm)
and then chain this package to the app package (firefox-esr).
This will work if the app package is installed for the first time. If i
later update the ccm package (because i have to deploy new settings) and
increase the revision number for both packages and then call the app
package, the chained ccm package will be ignored.
I use precheck-upgrade="always" in my packages - if i remove this line the
chained package will not be ignored - but than i will have
again the problem that the complete application reinstalls. So i guess
that chained packages only work in install-mode, not in upgrade-mode
when using precheck-upgrade="always". Maybe i have to use a different
approach...
How you guys manage ccm in your environment? Got some tips for me?
Thanks,
Holger

[Dafydd Jones (techneg.it)]

Also, you don't want the 'execute=once' in there.

Dafydd

Post by Dafydd Jones (techneg.it)
Holger,
looking at your ccm package, the issue is how you differentiate config
versions.
You use an exists check, but the file already exists. I use a filesize
check, because when I change a configuration that often changes the file
size, and when it doesn't I add some extra comment. You could also compare
the date of a file.
On upgrade, you only increment the config package revision number, not both.
HTH,
Dafydd

Post by Holger Kröber
Hi,
often, after youÂŽve deployed a package some changes or modifications are
required for this package.
E.g. you have to (re-)configure the proxy settings for firefox etc.
I think that most of you implement change and config managment (ccm)
directly inside the package of the application itself.
But what happens, if you already deployed the package and then you have
to configure some settings for this package later?
The way wpkg works, you would have to modify the app package, add some
check conditions (e.g. with firefox: check file
exists mozilla.cfg etc), increase the revision number and....accept that
wpkg will reinstall your complete application/package
and not just only makes the desired configuration changes. Maybe itÂŽs ok
for you with a small package like firefox - but there also exists big
software.
So i am searching for a way to avoid a reinstallation of a already
installed package while deploying new settings for this package.
My first thought was to outsource the ccm into a new package
(firefox_ccm) and then chain this package to the app package (firefox-esr).
This will work if the app package is installed for the first time. If i
later update the ccm package (because i have to deploy new settings) and
increase the revision number for both packages and then call the app
package, the chained ccm package will be ignored.
I use precheck-upgrade="always" in my packages - if i remove this line
the chained package will not be ignored - but than i will have
again the problem that the complete application reinstalls. So i guess
that chained packages only work in install-mode, not in upgrade-mode
when using precheck-upgrade="always". Maybe i have to use a different
approach...
How you guys manage ccm in your environment? Got some tips for me?
Thanks,
Holger

[Holger Kröber]

Hi Dafydd,

Post by Dafydd Jones (techneg.it)
Holger,
looking at your ccm package, the issue is how you differentiate config
versions.
You use an exists check, but the file already exists.

I donŽt think that this causes the problem. Reason I: the second time i
executed the package, the chained package wasnŽt even processed (i
verified this with the /debug parameter)
Reason II: i deleted some of the files that have been copied the first
time - the second time they didnŽt reappear.

Post by Dafydd Jones (techneg.it)
I use a filesize check, because when I change a configuration that
often changes the file size, and when it doesn't I add some extra
comment. You could also compare the date of a file.

I guess it depends on the situation if a filesize check is preferable to
"execute=once". Having 5 big files and only one of them changes -> use
filesize check. Have 3 little txt-files and
one or all changes ->execute=once will do it.

Post by Dafydd Jones (techneg.it)
On upgrade, you only increment the config package revision number, not both.

I will try this out.
Thanks,
Holger

Post by Dafydd Jones (techneg.it)
HTH,
Dafydd
On Tuesday, 20 October 2015, Holger Kröber
Hi,
often, after youŽve deployed a package some changes or
modifications are required for this package.
E.g. you have to (re-)configure the proxy settings for firefox etc.
I think that most of you implement change and config managment
(ccm) directly inside the package of the application itself.
But what happens, if you already deployed the package and then you
have to configure some settings for this package later?
The way wpkg works, you would have to modify the app package, add
some check conditions (e.g. with firefox: check file
exists mozilla.cfg etc), increase the revision number
and....accept that wpkg will reinstall your complete
application/package
and not just only makes the desired configuration changes. Maybe
itŽs ok for you with a small package like firefox - but there also
exists big software.
So i am searching for a way to avoid a reinstallation of a already
installed package while deploying new settings for this package.
My first thought was to outsource the ccm into a new package
(firefox_ccm) and then chain this package to the app package (firefox-esr).
This will work if the app package is installed for the first time.
If i later update the ccm package (because i have to deploy new
settings) and
increase the revision number for both packages and then call the
app package, the chained ccm package will be ignored.
I use precheck-upgrade="always" in my packages - if i remove this
line the chained package will not be ignored - but than i will have
again the problem that the complete application reinstalls. So i
guess that chained packages only work in install-mode, not in
upgrade-mode
when using precheck-upgrade="always". Maybe i have to use a
different approach...
How you guys manage ccm in your environment? Got some tips for me?
Thanks,
Holger
-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
https://lists.wpkg.org/mailman/listinfo/wpkg-users

[Marco]

According to the docu: http://wpkg.org/Execute_once_/_always

all checks are ignored with execute once / always

And again according to the docu, if you use execute=once, the upgrade
command is used in case the revision is higher than last time.

Updating the revision of a chained package will always execute the
upgrade of the package.

Summary:
Put execute=once in the ccm package, without a check.
Put the chain to the ccm in the firefox package

Greetings ...
Marco

Hi,
often, after you´ve deployed a package some changes or modifications are
required for this package.
E.g. you have to (re-)configure the proxy settings for firefox etc.
I think that most of you implement change and config managment (ccm)
directly inside the package of the application itself.
But what happens, if you already deployed the package and then you have
to configure some settings for this package later?
The way wpkg works, you would have to modify the app package, add some
check conditions (e.g. with firefox: check file
exists mozilla.cfg etc), increase the revision number and....accept that
wpkg will reinstall your complete application/package
and not just only makes the desired configuration changes. Maybe it´s ok
for you with a small package like firefox - but there also exists big
software.
So i am searching for a way to avoid a reinstallation of a already
installed package while deploying new settings for this package.
My first thought was to outsource the ccm into a new package
(firefox_ccm) and then chain this package to the app package (firefox-esr).
This will work if the app package is installed for the first time. If i
later update the ccm package (because i have to deploy new settings) and
increase the revision number for both packages and then call the app
package, the chained ccm package will be ignored.
I use precheck-upgrade="always" in my packages - if i remove this line
the chained package will not be ignored - but than i will have
again the problem that the complete application reinstalls. So i guess
that chained packages only work in install-mode, not in upgrade-mode
when using precheck-upgrade="always". Maybe i have to use a different
approach...
How you guys manage ccm in your environment? Got some tips for me?
Thanks,
Holger
-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
https://lists.wpkg.org/mailman/listinfo/wpkg-users

-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/

[Holger Kröber]

Hi Marco,

Post by Marco
According to the docu: http://wpkg.org/Execute_once_/_always

all checks are ignored with execute once / always

And again according to the docu, if you use execute=once, the upgrade
command is used in case the revision is higher than last time.

I know, i read the docu before. I incremented the revision number before
but the chained package was ignored. And as you can see,
i used <upgrade include="install" />

Post by Marco
Updating the revision of a chained package will always execute the
upgrade of the package.
Put execute=once in the ccm package, without a check.

Well, i have a check in the ccm package, but the check will be ignored
anyways, right?

Post by Marco
Put the chain to the ccm in the firefox package

I already did. So what is the difference to my situation?
Cheers,
Holger

Post by Marco
Greetings ...
Marco

Hi,
often, after you´ve deployed a package some changes or modifications are
required for this package.
E.g. you have to (re-)configure the proxy settings for firefox etc.
I think that most of you implement change and config managment (ccm)
directly inside the package of the application itself.
But what happens, if you already deployed the package and then you have
to configure some settings for this package later?
The way wpkg works, you would have to modify the app package, add some
check conditions (e.g. with firefox: check file
exists mozilla.cfg etc), increase the revision number and....accept that
wpkg will reinstall your complete application/package
and not just only makes the desired configuration changes. Maybe it´s ok
for you with a small package like firefox - but there also exists big
software.
So i am searching for a way to avoid a reinstallation of a already
installed package while deploying new settings for this package.
My first thought was to outsource the ccm into a new package
(firefox_ccm) and then chain this package to the app package
(firefox-esr).
This will work if the app package is installed for the first time. If i
later update the ccm package (because i have to deploy new settings) and
increase the revision number for both packages and then call the app
package, the chained ccm package will be ignored.
I use precheck-upgrade="always" in my packages - if i remove this line
the chained package will not be ignored - but than i will have
again the problem that the complete application reinstalls. So i guess
that chained packages only work in install-mode, not in upgrade-mode
when using precheck-upgrade="always". Maybe i have to use a different
approach...
How you guys manage ccm in your environment? Got some tips for me?
Thanks,
Holger
-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >>
http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
https://lists.wpkg.org/mailman/listinfo/wpkg-users

-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >>
http://lists.wpkg.org/pipermail/wpkg-users/
_______________________________________________
wpkg-users mailing list
https://lists.wpkg.org/mailman/listinfo/wpkg-users

-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/

[Will Aoki]

Post by Holger Kröber
But what happens, if you already deployed the package and then you
have to configure some settings for this package later?

[...]

Post by Holger Kröber
....accept that wpkg will reinstall your complete application/package
and not just only makes the desired configuration changes.

I take two different approaches depending on the details of the package.
In some cases I'll use both together.

The first is to use a separate package for configuration, but instead of
chaining the configuration package, I make the configuration package
depend on the application package and include the configuration package
in a profile. This allows me to easily and quickly switch machines
between different configurations. For example:

<package id="foo" name="Foo Enterprise" revision="%PKG_VESRION%" reboot="false" priority="10">
<!-- do stuff that takes 15 minutes to complete -->
</package>

<package id="foo_config1" name="Foo configuration 1" revision="%PKG_VERSION%" reboot="false" priority="10">
<variable name="PKG_VERSION" value="7" />
<check type="registry" condition="equals" path="HKLM\Software\Foo\mode" value="safe" />
<install cmd='reg add "HKLM\Software\Foo" /v mode /t REG_SZ /f /d "safe"' />
<upgrade include="install" />
<remove cmd='reg delete "HKLM\Software\Foo" /v mode /f' />
</package>

<package id="foo_config2" name="Foo configuration 2" revision="%PKG_VERSION%" reboot="false" priority="10">
<variable name="PKG_VERSION" value="2" />
<check type="registry" condition="equals" path="HKLM\Software\Foo\mode" value="dangerous" />
<check type="registry" condition="equals" path="HKLM\Software\Foo\DefaultName" value="Bob" />
<install cmd='reg add "HKLM\Software\Foo" /v mode /t REG_SZ /f /d "dangerous"' />
<install cmd='reg add "HKLM\Software\Foo" /v DefaultName /t REG_SZ /f /d "Bob"' />
<upgrade include="install" />
<remove cmd='reg delete "HKLM\Software\Foo" /v mode /f' />
<remove cmd='reg delete "HKLM\Software\Foo" /v DefaultName /f' />
</package>

<profile id="student_pc" >
<package package-id="foo_config1" />
</profile>
<profile id="mgr_pc" >
<package package-id="foo_config2" />
</profile>

One drawback to this approach is that there isn't a good way to
gracefully deal with the situation where an admin accidentally assigns a
computer two conflicting configuration packages. One could have each
package touch a file and use checks which look at the files the other
packages write, but that's not very clean.

The other approach I use is to only run expensive operations as needed,
e.g.:

<package
id="whatever_pro"
name="Whatever Pro"
revision="%PKG_VERSION%-%PKG_PKGREV%"
reboot="false"
priority="10">

<!-- Increment this when deploying a new version -->
<variable name="PKG_VERSION" value="15.1" />

<!-- Reset this to 0 when deploying a new version; increment it when
deploying configuration, etc changes -->
<variable name="PKG_PKGREV" value="3" />

<check type="uninstall" condition="versiongreaterorequal" path="Whatever Pro" value="%PKG_VERSION%" />
<check type="registry" condition="equals" path="HKLM\Software\SomeoneOrOther\Whatever\destroyEverythingOnRun" value="0" />

<install cmd='msiexec /qn /i "%SOFTWARE%\whatever\whatever_pro_%PKG_VERSION%.msi"' >
<!-- This check prevents the MSI being upgraded if it's already
been installed -->
<check type="uninstall" condition="versionsmallerthan" path="Whatever Pro" value="%PKG_VERSION%" />
</install>

<!-- This always runs -->
<install cmd='reg add "HKLM\Software\SomeoneOrOther\Whatever" /v destroyEverythingOnRun /t REG_DWORD /f /d 0' />

<upgrade include="install" />

<!-- etc -->
</package>

This is quick and clean but by itself doesn't easily support multiple
different configurations. I also use this trick when bringing
manually-installed software under WPKG control, for packages which
require a reboot during the install process (e.g. things using wusa) and
for packages where re-running a step is very slow, will cause an
unnecessary reboot or will break things.

-------------------------------------------------------------------------
SSLrack - get your cheap cheap SSL certificates (standard, wildcard, EV)
http://www.sslrack.com/
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/