I understand. thank you both for your help.
El mar., 21 ene. 2020 20:54, Gabriel Filion <gabs...@lelutin.ca> escribió:
> On 2020-01-20 2:34 a.m., Joaquin Veira wrote:
> > I understand what you mean but I guess there must be any way to check if
> I
> > file exists on the client and act in consecuence.
> >
> > I mean, if I want to identify a MySQL server by the existance of
> > /etc/my.cnf and execute a systemctl enable mysql && systemctl start
> mysql
> > that should work, right?
>
> I guess you could write a boolean custom fact that is true if the file
> exists and false otherwise.
>
> but I guess what Ben was trying to expose was that this makes the logic
> somewhat reversed for what ppl usually do with puppet.
>
> with puppet you usually want to dictate what a machine should have, e.g.
> your logic would read somewhat like "This host is a mysql server".
>
> If you have some manifest that configures something if a certain file
> exists it means that puppet is not authoritative about what a server is
> but is merely reacting to what sysadmins do directly on the machine. It
> also means that if someone installs mysql by mistake or somehow gets an
> /etc/my.cnf file created, then your manifests might wrongly install some
> things as though this machine was supposed to be a production mysql
> server, but without a clear decision about this in your infrastructure
> code.
>
> > El sábado, 18 de enero de 2020, 1:12:57 (UTC+1), Ben Ford escribió:
> >>
> >> But when I execute this from a server-client infrastructure it seems
> like
> >>> the conditionals don't work They are not even processed:
> >>
> >>
> >> Oh, they're processed just the same. But the key part that you've
> missed
> >> is that the catalog is compiled on the *master*. That's where all
> >> functions run. The catalog that the agents get is just a json file that
> >> describes what state the system should be in. The reason it appeared to
> >> work when you ran puppet apply was that apply operates like both master
> and
> >> agent in that it compiles the catalog and then enforces it.
> >>
> >> What's the use case you're trying to solve? Writing code that does
> >> different things based on some arbitrary condition that might have
> >> completely different results at different times is generally a brittle
> >> anti-pattern. We generally want a catalog to manage a system with a
> known
> >> end state.
> >>
> >> On Fri, Jan 17, 2020 at 8:15 AM Joaquin Veira <joaqui...@gmail.com
> >> <javascript:>> wrote:
> >>
> >>> Hi,
> >>>
> >>> I'm trying to use a condition based on the existance of a file.
> Something
> >>> like this:
> >>>
> >>> if find_file('/etc/if_this_file_exists') {
> >>> file { '/etc/create_this_file':
> >>> ensure => present,
> >>> owner => 'root',
> >>> group => 'root',
> >>> mode => '0755',
> >>> source =>
> >>> "puppet:///modules/${module_name}/etc/create_this_file",
> >>> }
> >>> }
> >>>
> >>> This is working correctly in a laboratory environment launched with:
> >>>
> >>> [root@labserver ~]# puppet apply --modulepath=/home/user/git/ -e
> "include
> >>> my_module" --verbose --noop
> >>> Info: Loading facts
> >>> Notice: Compiled catalog for labserver in environment lab in 0.04
> seconds
> >>> Info: Applying configuration version '1579255663'
> >>> Notice: /Stage[main]/my_module::Files/File[/...]/mode: current_value
> >>> '0777', should be '0755' (noop)
> >>> Notice: /Stage[main]/my_module::Files/File[/....]/mode: current_value
> >>> '0777', should be '0755' (noop)
> >>> Notice: /Stage[main]/my_module::Files/File[/...]/mode: current_value
> >>> '0777', should be '0644' (noop)
> >>> Notice: /Stage[main]/my_module::Files/File[/...]/mode: current_value
> >>> '0777', should be '0770' (noop)
> >>> Notice: /Stage[main]/my_module::Files/File[/...]/ensure: current_value
> >>> 'absent', should be 'file' (noop)
> >>> Notice: Class[my_module::Files]: Would have triggered 'refresh' from 5
> >>> events
> >>> Notice: Stage[main]: Would have triggered 'refresh' from 1 event
> >>> Notice: Applied catalog in 0.12 second
> >>>
> >>> But when I execute this from a server-client infrastructure it seems
> like
> >>> the conditionals don't work They are not even processed:
> >>>
> >>> [root@devserver ~]# puppet agent -tv --debug --noop
> >>> ...
> >>> Debug: /Stage[main]/previous_module::Install/File[/...]: Adding
> >>> autorequire relationship with User[root]
> >>> Debug: /Stage[main]/my_module::Files/File[/...]: Adding autorequire
> >>> relationship with File[/etc/cron.daily]
> >>> Debug: /Stage[main]/my_module::Files/File[/...]: Adding autorequire
> >>> relationship with User[root]
> >>> Debug:
> /Stage[main]/next_module::Config/App::Conf[00-syslog]/File[/...]:
> >>> Adding autorequire relationship with User[root]
> >>> ...
> >>>
> >>> Sorry I have to modify the output so I don't show the real paths &
> files.
> >>>
> >>> Can anyone explain to me why is this not working, please?
> >>>
> >>> Thanks & regards,
> >>>
> >>> Joaquín
> >>>
> >>> --
> >>> You received this message because you are subscribed to the Google
> Groups
> >>> "Puppet Users" group.
> >>> To unsubscribe from this group and stop receiving emails from it, send
> an
> >>> email to puppet...@googlegroups.com <javascript:>.
> >>> To view this discussion on the web visit
> >>>
> https://groups.google.com/d/msgid/puppet-users/a13df78f-e816-47e8-92d7-3cc46c316276%40googlegroups.com
> >>> <
> https://groups.google.com/d/msgid/puppet-users/a13df78f-e816-47e8-92d7-3cc46c316276%40googlegroups.com?utm_medium=email&utm_source=footer
> >
> >>> .
> >>>
> >>
> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/11c85422-3389-5bd1-6f70-51f545e2d02a%40lelutin.ca
> .
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/CACTmrXrZx6oV5Kq3BzRMszMK5iDiW41zSDpa2yc8z9GJKurPKg%40mail.gmail.com.
