Puppet users - Sep 2006 - package: ignores "source"; "provider" doesn''t work as advertised?

Hi

I¹m not sure if I¹m misunderstanding, however, when I try the following:

class thttpd {
    package { thttpd:
        version => "2.25b-4.2",
        source => 
"http://dag.wieers.com/packages/thttpd/thttpd-2.25b-4.2.el4.rf.i386.rpm"
    }
[snip other code]
}

On fedora core 5, the ³source² is ignored: yum is used to pull the package
from the upstream repos listed in yum.conf

I tried to fix this, by setting the provider to rpm (details from here
http://reductivelabs.com/projects/puppet/documentation/typedocs.html#package
), which I¹m hoping is a little more obedient:

class thttpd {
    package { thttpd:
        version => "2.25b-4.2",
        provider => rpm,
        source => 
"http://dag.wieers.com/packages/thttpd/thttpd-2.25b-4.2.el4.rf.i386.rpm"
    }
[snip]
}

But this generates an error on the server:

$ sudo /usr/bin/puppetmasterd -v
info: Starting server for Puppet version 0.18.3
info: mount[dist]: allowing *.local access
Invalid parameter ''provider'' for type
''package'' in file
/etc/puppet/manifests/classes/thttpd.pp at line 6

Can anyone help explain what¹s up?

Thanks

Gary



_______________________________________________
Puppet-users mailing list
Puppet-users@madstop.com
https://mail.madstop.com/mailman/listinfo/puppet-users

Gary Law wrote:
> Hi
> 
> I’m not sure if I’m misunderstanding, however, when I try the following:
> 
> class thttpd {
>     package { thttpd:
>         version => "2.25b-4.2",
>         source => 
>
"http://dag.wieers.com/packages/thttpd/thttpd-2.25b-4.2.el4.rf.i386.rpm"
>     }
> [snip other code]
> }
> 
> On fedora core 5, the “source” is ignored: yum is used to pull the 
> package from the upstream repos listed in yum.conf
> 
> I tried to fix this, by setting the provider to rpm (details from here 
>
http://reductivelabs.com/projects/puppet/documentation/typedocs.html#package),
> which I’m hoping is a little more obedient:
> 
> class thttpd {
>     package { thttpd:
>         version => "2.25b-4.2",
>         provider => rpm,
>         source => 
>
"http://dag.wieers.com/packages/thttpd/thttpd-2.25b-4.2.el4.rf.i386.rpm"
>     }
> [snip]
> }
> 
> But this generates an error on the server:
> 
> $ sudo /usr/bin/puppetmasterd -v
> info: Starting server for Puppet version 0.18.3
> info: mount[dist]: allowing *.local access
> Invalid parameter ''provider'' for type
''package'' in file
> /etc/puppet/manifests/classes/thttpd.pp at line 6
> 
> Can anyone help explain what’s up?
Providers will be available in 0.19.0; the docs are unfortunately 
generated against the latest code.

Use ''type'' for packages for now (0.19.0 still supports that
parameter,
so don''t worry about backwards compatibility).

-- 
Due to circumstances beyond your control, you are master of your fate
and captain of your soul.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

On 4/9/06 16:53, "Luke Kanies" <luke@madstop.com> wrote:
> Gary Law wrote:
>> 
>> class thttpd {
>>     package { thttpd:
>>         version => "2.25b-4.2",
>>         source =>
>>
"http://dag.wieers.com/packages/thttpd/thttpd-2.25b-4.2.el4.rf.i386.rpm"
>>     }
> 
> Providers will be available in 0.19.0; the docs are unfortunately
> generated against the latest code.
> 
> Use ''type'' for packages for now (0.19.0 still supports
that parameter,
> so don''t worry about backwards compatibility).
Thanks Luke, that seems to fix the yum/rpm issue for me.

The source directive doesn''t work though: giving the above http: url
results
in an error, as does switching to the puppet in built file distribution
method. Could you advise? Error output follows. I''ve checked that the
host
can download the file using wget; there is no need to use a proxy.

Thanks

Gary

sudo puppetd --server server.local --verbose
Password:
notice: Starting Puppet client version 0.18.4
info: Caching configuration at /etc/puppet/localconfig.yaml
notice: Starting configuration run
err: //client/thttpd/package=thttpd/ensure: change from absent to present
failed: error: skipping
http://dag.wieers.com/packages/thttpd/thttpd-2.25b-4.2.el4.rf.i386.rpm -
transfer failed - Unknown or unexpected error
warning: _url_cache[0] 0x94ec4f8 nrefs(14438855) != 1 ( )

notice: //client/thttpd/file=/etc/thttpd.conf: Dependency package[thttpd]
has 1 failures
warning: //client/thttpd/file=/etc/thttpd.conf: Skipping because of failed
dependencies
notice: //client/thttpd/service=thttpd: Dependency package[thttpd] has 1
failures
warning: //client/thttpd/service=thttpd: Skipping because of failed
dependencies
notice: Finished configuration run in 0.76 seconds

Gary Law wrote:
> 
> Thanks Luke, that seems to fix the yum/rpm issue for me.
> 
> The source directive doesn''t work though: giving the above http:
url results
> in an error, as does switching to the puppet in built file distribution
> method. Could you advise? Error output follows. I''ve checked that
the host
> can download the file using wget; there is no need to use a proxy.
The source is expected to be a locally available file; it doesn''t 
currently download files automatically or anything.

I thought about adding that, but that''s what yum is for. :)

I''ll update the docs to reflect this.


-- 
Don''t tell me how hard you work. Tell me how much you get done.
                 -- James Ling
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

On 5/9/06 16:57, "Luke Kanies" <luke@madstop.com>
wrote:
> The source is expected to be a locally available file; it doesn''t
> currently download files automatically or anything.
Ah, that''ll be it then.  :)
> I thought about adding that, but that''s what yum is for. :)
Yum, like up2date, apt-get, pkg-get, etc., is good at keeping things up to
the latest version, whilst solving dependency problems. I''m trying to
keep
things at a given, tested, version, and I explicitly want to know about
dependency problems. Hence using rpm. It would be nice if puppet could
handle the rpm package file distribution as it does for config files.

Currently we use NFS for package distribution, so I guess I''m going to
have
to continue to do this.

Thanks

Gary

Gary Law wrote:
> 
> Currently we use NFS for package distribution, so I guess I''m
going to have
> to continue to do this.
Yeah, that''s still by far the best option.  I''d like Puppet
files to
support http sources, but I can''t compare checksums there so
it''d be
difficult.

I''ve thought about building in wget-like mechanisms for when a package 
needs to be installed, but it just didn''t seem like a big enough
problem
to be worth the effort of solving.

-- 
Every great advance in natural knowledge has involved the absolute
rejection of authority.    --Thomas H. Huxley
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com

On 5/9/06 21:32, "Luke Kanies" <luke@madstop.com> wrote:
>> Currently we use NFS for package distribution, so I guess I''m
going to have
>> to continue to do this.
> 
> Yeah, that''s still by far the best option.
>
>  I''d like Puppet files to
> support http sources, but I can''t compare checksums there so
it''d be
> difficult.
I understand why http is not a priority. But seeing as you''ve got a
config
files distribution mechanism already written, it would be cool if we could
use this for package files too.

Gary

Gary Law wrote:
> 
> I understand why http is not a priority. But seeing as you''ve got
a config
> files distribution mechanism already written, it would be cool if we could
> use this for package files too.
This is in my bucket of "nice to have, but probably not going to happen 
unless I get a patch or someone pays me to develop it".

I agree it''d be great.  Heck, I''d love to support general
URLs. I''ve
just got so many other things that are higher on my priority list that 
it''s not likely to get done by me.

It might be a good place for someone to learn ruby and Puppet, because 
most of the work is connecting Puppet to the Net::HTTP library and its 
ilk, but I''m afraid there might be some sticky issues related to trying
to figure out if a file has changed and thus should be downloaded again.

And, of course, this isn''t quite the same thing as the package source, 
since that doesn''t perform an operation, it just locates the file. 
We''d
need to do some internal skullduggery to turn the package source into a 
file object and then pull it down if the package is going to be 
installed.  I''ve tried things like that when I was working with ISconf,
and it is insanely difficult to do these in a generic way -- do the 
files go to /tmp?  /var/tmp?  Is there a size limit?  A timeout?  It 
seems straightforward at first, but it was complicated enough that I 
just went to NFS for packages rather than try to solve it.

If Puppet supported pre-hooks, or if you are willing to have all of your 
machines always have all of their packages, you could create a 
definition to wrap an exec object to pull the package down and a package 
object to install:

define(source, tmpdir = "/tmp") {
   $newpath = "$tmpdir/$name"
   exec { "get-$name":
     command => "/bin/wget -o tmpdir/$name $source"
   }
   package { $name: source => $newpath, ensure => installed }
}

Something like that, anyway.

-- 
It''s very hard to predict things . . . Especially the future.
                 -- Prof. Charles Kelemen, Swarthmore CS Dept.
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com