Puppet users - Mar 2008 - Identifying the current version of an installed package

Hi!

I''m currently creating a puppet configuration repository for the Kolab
groupware server (http://kolab.org). As the server runs on a variety
of different platforms there exists a certain variability in the
versions of the server components. So I need to provide configurations
for different software versions and I''d like to be able to ask puppet
for the currently installed version.

What would be the best approach to do that?

I am able to do what I want on Gentoo using this code snippet:

    # Determine the package version
    case $operatingsystem {
      gentoo: {
        $eix_out = generate(''/usr/bin/eix'',
''--nocolor'', ''--format'',
''"<installedversionsshort>"'',
''--pure-packages'', ''--exact'', ''--
category-name'', ''net-nds/openldap'')

        case $eix_out {
          "No matches found.": {
              $version = false
          }
          default: {
            $version = $eix_out
          }
        }
      }
      default: {
        $version = false
      }
    }

But this becomes quite tedious after a while and I''d much rather like
to have a simple function that allows me to do something like this:

$version = get_package_version(''openldap'')

I tried using this:

class os::gentoo::package::version
{
  $eix_out = generate(''/usr/bin/eix'',
''--nocolor'', ''--format'',
''"<installedversionsshort>"'',
''--pure-packages'', ''--exact'', ''--
category-name'', "$package_name")

  case $eix_out {
    "No matches found.": {
      $version = false
    }
    default : {
      $version = $eix_out
    }
  }
}

and then using

      # Determine the package version
      $package_name = $operatingsystem ? {
        gentoo  => ''net-nds/openldap'',
        default => ''openldap''
      }

      include os::package::version

      # Rewrite the application version to the configuration version
      # Fail if we don''t know the version
      case $os::package::version::version {
...

But using a class does not really work as I can only define
$package_name once.

Is there a way to get a simple function for the task?

Thanks!

Cheers,

Gunnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi
> I''m currently creating a puppet configuration repository for the
Kolab
> groupware server (http://kolab.org). As the server runs on a variety
> of different platforms there exists a certain variability in the
> versions of the server components. So I need to provide configurations
> for different software versions and I''d like to be able to ask
puppet
> for the currently installed version.
> 
> What would be the best approach to do that?

why not simply provide per distro (os) a specific config file, which
means that you would automatically support only the latest version of
the specific distro/os. So something like this:

file{''kolab_confi'':
	...foobar...,
	source => [
"puppet://$server/kolab/config/kolab.config.$operatingsytem.$lsbdistcodename",
"puppet://$server/kolab/config/kolab.config.$operatingsytem",
"puppet://$server/kolab/config/kolab.config.Default" ],
}

so puppet would on a debian etch first to to fetch:

"puppet://$server/kolab/config/kolab.config.Debian.Etch"

then

"puppet://$server/kolab/config/kolab.config.Debian"

and then finally:

"puppet://$server/kolab/config/kolab.config.Default"

which might be a version of the most uptodate kolab version. (You could
even link the os/distro specific once with this if they are the same
version)

Or you could put kolab.config.$version under /kolab/config/ and link the
os/distro-files to them.

so for example:

/kolab/config/kolab.config.Debian.Etch -> /kolab/config/kolab.config.2.4
and
/kolab/config/kolab.config.Debian.Sarge -> /kolab/config/kolab.config.2.3

This how DavidS do it for example on:
http://git.black.co.at/?p=module-munin;a=blob;f=manifests/client.pp;h=0ad7856380f6affadff782e780fd2f7cbf057750;hb=ff89c05910e5185a3c5cf47bd6f4e3f52596cf33
line 105 and I adapted this to fit most kind of these problems.

Please note that you''ll need (at least part of) DavidS common-module to
get the lsbdistcodename thing, afair.

greets pete

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mar 31, 2008, at 12:54 PM, Gunnar Wrobel wrote:
<snip>
>
> Is there a way to get a simple function for the task?
Yup: http://reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions

-Blake

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mar 31, 2008, at 2:54 PM, Gunnar Wrobel wrote:
>        $eix_out = generate(''/usr/bin/eix'',
''--nocolor'', ''--format'',
> ''"<installedversionsshort>"'',
''--pure-packages'', ''--exact'', ''--
> category-name'', ''net-nds/openldap'')

Note that this will only work if the server is also where you''re  
running your software.  This command runs on the server, not on the  
client.

The only way to get client information to the server is via facts.

-- 
Football is a mistake. It combines the two worst elements of American
life. Violence and committee meetings. -- George F. Will
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Peter,

thanks for the reply.

On 31 Mrz., 22:07, Peter Meier <peter.me...@immerda.ch>
wrote:
> Hi
>
> > I''m currently creating a puppet configuration repository for
the Kolab
> > groupware server (http://kolab.org). As the server runs on a variety
> > of different platforms there exists a certain variability in the
> > versions of the server components. So I need to provide configurations
> > for different software versions and I''d like to be able to
ask puppet
> > for the currently installed version.
>
> > What would be the best approach to do that?
>
> why not simply provide per distro (os) a specific config file, which
> means that you would automatically support only the latest version of
> the specific distro/os. So something like this:
This works rather well with distros like Debian where a single release
number indicates which software versions most of the installed
packages have.

With distros such as Gentoo it gets more complicated. There is no
single release version and users can have any package version
installed from a wide range of available package versions.

Of course you are right and I could just accept the latest available
version. But I''d be back to a problem I already had in the past:
I''ll
always have to track the latest version currently provided by Gentoo
and ensure that I provide the correct configuration templates for this
version.

So this is a problem I''d like to solve with puppet. In the ideal case
puppet would detect the version and see that it has no template for
the newest version yet. It would then fail and inform the user to test
if the old templates still work and/or inform upstream of the new
version.

Cheers,

Gunnar
>
> file{''kolab_confi'':
>         ...foobar...,
>         source => [
>
"puppet://$server/kolab/config/kolab.config.$operatingsytem.$lsbdistcodename",
> "puppet://$server/kolab/config/kolab.config.$operatingsytem",
> "puppet://$server/kolab/config/kolab.config.Default" ],
>
> }
>
> so puppet would on a debian etch first to to fetch:
>
> "puppet://$server/kolab/config/kolab.config.Debian.Etch"
>
> then
>
> "puppet://$server/kolab/config/kolab.config.Debian"
>
> and then finally:
>
> "puppet://$server/kolab/config/kolab.config.Default"
>
> which might be a version of the most uptodate kolab version. (You could
> even link the os/distro specific once with this if they are the same
> version)
>
> Or you could put kolab.config.$version under /kolab/config/ and link the
> os/distro-files to them.
>
> so for example:
>
> /kolab/config/kolab.config.Debian.Etch -> /kolab/config/kolab.config.2.4
> and
> /kolab/config/kolab.config.Debian.Sarge ->
/kolab/config/kolab.config.2.3
>
> This how DavidS do it for example
on:http://git.black.co.at/?p=module-munin;a=blob;f=manifests/client.pp;h...
> line 105 and I adapted this to fit most kind of these problems.
>
> Please note that you''ll need (at least part of) DavidS
common-module to
> get the lsbdistcodename thing, afair.
>
> greets pete
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Hi Blake,

On 31 Mrz., 22:07, Blake Barnett <sha...@gmail.com>
wrote:
> On Mar 31, 2008, at 12:54 PM, Gunnar Wrobel wrote:
> <snip>
>
>
>
> > Is there a way to get a simple function for the task?
>
> Yup:http://reductivelabs.com/trac/puppet/wiki/WritingYourOwnFunctions
>
> -Blake
Okay, will try to do it that way :)

Thanks!

Gunnar
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On 31 Mrz., 22:49, Luke Kanies <l...@madstop.com>
wrote:
> On Mar 31, 2008, at 2:54 PM, Gunnar Wrobel wrote:
>
> >        $eix_out = generate(''/usr/bin/eix'',
''--nocolor'', ''--format'',
> > ''"<installedversionsshort>"'',
''--pure-packages'', ''--exact'', ''--
> > category-name'', ''net-nds/openldap'')
>
> Note that this will only work if the server is also where you''re
> running your software.  This command runs on the server, not on the
> client.
>
Right, I didn''t really consider that yet. Currently I''m
running in
client mode anyhow and I guess it will be client mode for most Kolab
users. Nevertheless I shouldn''t loose sight of also allowing client/
master mode.
> The only way to get client information to the server is via facts.
Okay, I guess I''ll have to investigate how I would get this done.

Thanks!

Gunnar
>
> --
> Football is a mistake. It combines the two worst elements of American
> life. Violence and committee meetings. -- George F. Will
> ---------------------------------------------------------------------
> Luke Kanies |http://reductivelabs.com|http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mar 31, 2008, at 10:27 PM, Gunnar Wrobel wrote:
> On 31 Mrz., 22:49, Luke Kanies <l...@madstop.com> wrote:
>> On Mar 31, 2008, at 2:54 PM, Gunnar Wrobel wrote:
>>
>>>       $eix_out = generate(''/usr/bin/eix'',
''--nocolor'', ''--format'',
>>> ''"<installedversionsshort>"'',
''--pure-packages'', ''--exact'', ''--
>>> category-name'', ''net-nds/openldap'')
>>
>> Note that this will only work if the server is also where
you''re
>> running your software.  This command runs on the server, not on the
>> client.
>>
>
> Right, I didn''t really consider that yet. Currently I''m
running in
> client mode anyhow and I guess it will be client mode for most Kolab
> users. Nevertheless I shouldn''t loose sight of also allowing
client/
> master mode.
>
>> The only way to get client information to the server is via facts.
>
> Okay, I guess I''ll have to investigate how I would get this done.
In case you hadn''t seen this yet either:
http://reductivelabs.com/trac/puppet/wiki/AddingFacts

-Blake

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users-unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

On Mon, 31 Mar 2008 22:24:40 -0700 (PDT)
Gunnar Wrobel <gwrobel@googlemail.com> wrote:
> 
> On 31 Mrz., 22:07, Peter Meier <peter.me...@immerda.ch> wrote:
> > Hi
> >
> > > I''m currently creating a puppet configuration repository
for the Kolab
> > > groupware server (http://kolab.org). As the server runs on a
variety
> > > of different platforms there exists a certain variability in the
> > > versions of the server components. So I need to provide
configurations
> > > for different software versions and I''d like to be able
to ask puppet
> > > for the currently installed version.
> >
> > > What would be the best approach to do that?
> >
> > why not simply provide per distro (os) a specific config file, which
> > means that you would automatically support only the latest version of
> > the specific distro/os. So something like this:
> 
> This works rather well with distros like Debian where a single release
> number indicates which software versions most of the installed
> packages have.
> 
> With distros such as Gentoo it gets more complicated. There is no
> single release version and users can have any package version
> installed from a wide range of available package versions.
> 
> Of course you are right and I could just accept the latest available
> version. But I''d be back to a problem I already had in the past:
I''ll
> always have to track the latest version currently provided by Gentoo
> and ensure that I provide the correct configuration templates for this
> version.
> 
> So this is a problem I''d like to solve with puppet. In the ideal
case
> puppet would detect the version and see that it has no template for
> the newest version yet. It would then fail and inform the user to test
> if the old templates still work and/or inform upstream of the new
> version.
> 
On Gentoo I use package masking to control which version is installed
when version updates may require differing configuration files or break
other packages installed outside of portage.

I have a gentoo module that handles this that I should have ready to
publish before too much longer.

jeffl


-- 
Jeffrey F. Lawhorn                       |Internet Security Consulting
Software Design Associates, Inc.         |Firewall & IDS
jeffl@wanet.net       858-679-5900 x:5900|Installation & Monitoring
http://www.wanet.net/ 858-679-2327 fax   |Policy Compliance

Great minds discuss ideas,
Average minds discuss events,
Small minds discuss people.

Jabber: jeffl@chat.wanet.com
AIM:    jfl2010