Re: [Puppet Users] puppet cert clean cleaning over and over
Hi, thanks for helping. I found about puppet cert reinventory a few weeks ago and it solved the issue for me. Sorry for not reporting back any earlier. Greetings Marc On Thu, May 17, 2018 at 02:30:08PM +1000, John Warburton wrote: > These are held in the CA inventory .../puppet/ssl/ca/inventory.txt > > See > https://ask.puppet.com/question/25818/how-to-manage-size-of-inventorytxt/ > for a discussion about cleaning it up, but essentially - delete your test > host entries here > > John -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20180517064031.jhdvsoetakmq4nre%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet cert clean cleaning over and over
Hi, I do have a certain host that I use for testing. It thus gets deleted and re-created (in Foreman) over and over again. Eventually, rebuilding the host times out at the puppet cert clean state. Foreman issues "puppet cert clean FQDN". When I invoke that from the command line, I get "Notice: Revoked certificate" for a number of serials, filling screens: Notice: Revoked certificate with serial 4898 Notice: Revoked certificate with serial 4903 Notice: Revoked certificate with serial 4904 Notice: Revoked certificate with serial 4945 Notice: Revoked certificate with serial 4946 Notice: Revoked certificate with serial 5149 When the foreman cert clean has eventually finished, the foreman-proxy has timed out in the mean time, and the build fails. Repeating the puppet cert clean results in the same serials being revoked again and again. Is there a method to clean up the puppet CA so that puppet cert clean doesn't try revoking certificates that do no longer exist at all? There is no file matching the FQDN in /var/lib/puppet/ssl at all. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20180422143251.i5t7v77ed3el5p7e%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] Influence hiera file selection from within hiera
Hi Dirk,
On Wed, Sep 07, 2016 at 02:00:46PM +0200, Dirk Heinrichs wrote:
> Am 07.09.2016 um 13:50 schrieb Marc Haber:
> > I would like to be able to influence which files hiera reads from with
> > in hiera.
>
> You can use facts in :datadir:, like for example:
>
> :datadir: '/etc/puppetlabs/code/environments/%{::environment}/hiera'
>
> While the :hierarchy: stays the same, we checkout different branches of
> a hiera repository in each environment to get different file content.
That's a pretty severe trick, which would require duplicating the
entire tree. I doubt that this is feasible in our environment here.
Greetings
Marc
--
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160908060414.GG10115%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Influence hiera file selection from within hiera
Hi,
I would like to be able to influence which files hiera reads from with
in hiera. Here is a minimal test:
$ cat hiera.yaml
---
:backends:
- yaml
:yaml:
:datadir: "/home/e13itfe/hieratest/yaml/"
:logger: console
:hierarchy:
- "0_harddefaults"
- "6_%{::redir}"
- "9_softdefaults"
$ head -n-0 yaml/*
==> yaml/0_harddefaults.yaml <==
---
redir: in-harddef
::redir: in-harddef-with-colons
==> yaml/6_redir.yaml <==
---
foo: file-redir
==> yaml/9_softdefaults.yaml <==
---
foo: file-softdef
redir: in-softdef
::redir: in-softdef-with-colons
I would like the redir variables that are set in 0_harddefaults.yaml
and in 9_softdefaults.yaml to influence the name of the 6_%{::redir}
file that is in hiera.yaml.
But according to my tests, this does of course not work:
$ hiera --debug --config hiera.yaml foo ::redir=redir
DEBUG: 2016-09-07 13:02:56 +0200: Hiera YAML backend starting
DEBUG: 2016-09-07 13:02:56 +0200: Looking up foo in YAML backend
DEBUG: 2016-09-07 13:02:56 +0200: Looking for data source 0_harddefaults
DEBUG: 2016-09-07 13:02:56 +0200: Looking for data source 6_redir
DEBUG: 2016-09-07 13:02:56 +0200: Found foo in 6_redir
file-redir
$ hiera --debug --config hiera.yaml foo
DEBUG: 2016-09-07 13:02:59 +0200: Hiera YAML backend starting
DEBUG: 2016-09-07 13:02:59 +0200: Looking up foo in YAML backend
DEBUG: 2016-09-07 13:02:59 +0200: Looking for data source 0_harddefaults
DEBUG: 2016-09-07 13:02:59 +0200: Looking for data source 6_
DEBUG: 2016-09-07 13:02:59 +0200: Cannot find datafile
/home/e13itfe/hieratest/yaml/6_.yaml, skipping
DEBUG: 2016-09-07 13:02:59 +0200: Looking for data source 9_softdefaults
DEBUG: 2016-09-07 13:02:59 +0200: Found foo in 9_softdefaults
file-softdef
$
That means that I can influence the file names that hiera reads from
the command line and probably later in puppet with external variables,
but not from the hiera code itself: The second that hiera starts
reading in the files from the datadir, the list of actual files to be
read is already made and the file names fully expanded.
This sounds logical, but am I reasoning correctly?
Assuming that I am right, is there a way to achieve a similar result?
Assuming that I am wrong, why does it not work?
Any hints will be appreciated.
Greetings
Marc
--
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160907115050.GE10115%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: How to handle predictable network interface names
On Fri, Aug 26, 2016 at 08:40:49AM -0700, Luke Bigum wrote: > My Dell XPS 13, 2016 model: > > /sys/class/net/docker0 > /sys/class/net/enp0s20u1u3i5 > E: ID_NET_NAME_MAC=enx9cebe824ebee > E: ID_NET_NAME_PATH=enp0s20u1u3i5 What a name! > For both the Dell R720 and R730, there's no NET_NAME stuff: > > [root@r720 ~]# udevadm info -q all -p /sys/class/net/p4p2 > P: /devices/pci:40/:40:02.0/:42:00.1/net/p4p2 > E: UDEV_LOG=3 > E: DEVPATH=/devices/pci:40/:40:02.0/:42:00.1/net/p4p2 > E: INTERFACE=p4p2 > E: IFINDEX=7 > E: SUBSYSTEM=net Maybe OS too old? The interface name "p4p2" also looks fishy. > > What I get from the abstraction above is being able to take our > > > profiles and re-use them in a completely different site on the other > > > side of the world, or in a staging / testing environment. So I don't > > > have the concept of "VLAN 123 in Production UK", I've just got "The > > > STORAGE network" which in Production UK happens to be vlan 123 > > > (buried low down in Hiera, and only specified once once), but in Dev > > > it's 456, and over there it doesn't exist so we'll give it the same > > > vlan tag as the CLIENT network, etc... The physical-ness of the > > > network is abstracted from the concepts our software relies on. > > > > Yes, that is a really nice concept with should have been considered > > here years ago. Alas, people didn't. > > To be fair we didn't design it this way from the start, it's only in the > last couple evolutions that abstraction appeared. Yes. I have never seen an installation doing it _this_ right in the first iteration. > > > > So you do create network interfaces in the profile and not in the > > > > role? > > > > > > > > > > We try to follow the design rule that "Roles only include Profiles". > > > > ... "and don't define their own resources", you mean? > > > > That's one of the aspects of the role-and-profiles approach that I > > have never seen spelled out explicitly, but still honored by nearly > > anybody, and I have not yet fully grokked the reasons for doing so. > > > > Yes, we definitely don't define resources, and don't include component / > base level classes. I think we pulled it from an early Gary Larizza post, > along with "roles don't have parameters, if you need to configure a role > you've got two different roles". Yes, but dropping a supplementary file does not mean that a role has parameters. And also, it would be duplication if one had two distinct roles that would only differ in single setting? > I've always understood the logic to be based on the layers of abstraction > the role/profile design is trying to achieve. I always envision this tree: > > Node (has one) -> > Role (has one or more) -> > Profile (has one or more) -> > Defined Type (has zero or more) -> > Resources > or Class (has zero or more) -> > Resources > or Resource That's the way it's in the books. What I'd like to see clarified (and explained why) is that this tree should have "and nothing else" spelled out in multiple places: Node (has one) -> Role (and nothing else!) Role (has one or more) -> Profile (and nothing else!) Profile (has one or more) -> Defined Type (has zero or more) -> Resources or Class (has zero or more) -> Resources or Resource Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20160827175059.GB2471%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: How to handle predictable network interface names
On Thu, Aug 25, 2016 at 08:08:13AM -0700, Luke Bigum wrote: > On Thursday, 25 August 2016 13:21:24 UTC+1, Marc Haber wrote: > > On Wed, Aug 24, 2016 at 08:36:49AM -0700, Luke Bigum wrote: > > > Here we have very strict control over our hardware and what interface > > goes > > > where. We keep CentOS 6's naming scheme on Dell hardware, so p2p1 is PCI > > > slot 2, Port 1, and don't try rename it. > > > > Isn't CentOS 6 still using eth0, 1, 2, 3? How do you handle different > > hardware having different slot numbers, or PCI bridges shifting bus > > numbers? > > > > I find this depends on the manufacturer. I've never come across a Dell > server newer than an R510 that *doesn't* give you PCI based names. I just > checked an R510 and it does. All of our ancient HP gear (7 years, older > than the R510s which is old) give the ethX names. Also random SuperMicro > hardware gives ethX. I don't really know what's missing for the kernel / > udev to name them so, but for us it doesn't really matter. Can you run $ for iface in /sys/class/net/*; do echo $iface; sudo udevadm info -q all -p $iface | grep ID_NET_NAME; done on some of your gear? I'd like to learn what different vendors deliver. My Thinkpad T450: /sys/class/net/br0 /sys/class/net/enx11121314 E: ID_NET_NAME=enp0s20u4 E: ID_NET_NAME_MAC=enx11121314 E: ID_NET_NAME_PATH=enp0s20u4 /sys/class/net/eth0 E: ID_NET_NAME=enp0s25 E: ID_NET_NAME_MAC=enx507b9d681b36 E: ID_NET_NAME_PATH=enp0s25 /sys/class/net/lo My APU at home (with a lot of bridges and VLANs): [2/501]mh@aida:~$ for iface in /sys/class/net/*; do echo $iface; sudo udevadm info -q all -p $iface | grep ID_NET_NAME; done /sys/class/net/br181 /sys/class/net/br182 /sys/class/net/br183 /sys/class/net/br184 /sys/class/net/br185 /sys/class/net/br186 /sys/class/net/br187 /sys/class/net/br188 /sys/class/net/br189 /sys/class/net/br191 /sys/class/net/br192 /sys/class/net/br281 /sys/class/net/br381 /sys/class/net/br382 /sys/class/net/br383 /sys/class/net/brenp1s0 /sys/class/net/brenp2s0 /sys/class/net/brenp3s0 /sys/class/net/enp1s0 E: ID_NET_NAME_MAC=enx000db9342afc E: ID_NET_NAME_PATH=enp1s0 /sys/class/net/enp2s0 E: ID_NET_NAME_MAC=enx000db9342afd E: ID_NET_NAME_PATH=enp2s0 /sys/class/net/enp3s0 E: ID_NET_NAME_MAC=enx000db9342afe E: ID_NET_NAME_PATH=enp3s0 /sys/class/net/int181 /sys/class/net/int182 /sys/class/net/int191 /sys/class/net/int192 /sys/class/net/lo /sys/class/net/per281 /sys/class/net/unt381 /sys/class/net/unt382 /sys/class/net/unt383 [3/502]mh@aida:~$ A KVM VM with a lot of interfaces: /sys/class/net/eth0 E: ID_NET_NAME=enx525400422c88 E: ID_NET_NAME_MAC=enx525400422c88 /sys/class/net/eth1 E: ID_NET_NAME=enx525400d22ad3 E: ID_NET_NAME_MAC=enx525400d22ad3 /sys/class/net/eth2 E: ID_NET_NAME=enx52540095dfa6 E: ID_NET_NAME_MAC=enx52540095dfa6 /sys/class/net/int181 /sys/class/net/int182 /sys/class/net/int183 /sys/class/net/int184 /sys/class/net/int185 /sys/class/net/int186 /sys/class/net/int187 /sys/class/net/int188 /sys/class/net/int189 /sys/class/net/int191 /sys/class/net/int192 /sys/class/net/lo /sys/class/net/per281 /sys/class/net/unt381 /sys/class/net/unt382 /sys/class/net/unt383 > > We have a 3rd party patch manager tool (patchmanager.com), LLDP on > > > our switches, and a Nagios check that tells me if an interface is not > > > plugged into the switch port it is supposed to be plugged into > > > (according to patchmanager). > > > > Nice ;-) Is the code for the Nagios stuff public? > > > > Unfortunately no Too bad ;-) > :-( Another one of those LMAX modules that's had years of > development but too much company specific stuff hard coded in it to > release. It's not a huge amount though, and I did just ask my Lead if > I could clean up our networking module and release it and he was more > than happy, I'm sure I could do the same for our nagios module. Watch > this space, but don't hold your breath. That would be really really nice. > > This works perfectly on Dell hardware because the PCI name mapping > > > works. > > > > And you don't have many different kinds of servers. > > We try keep as few as possible, but it's not that small a list: > > *** > [root@puppet ~]# mco facts productname > Report for fact: productname > > .found 1 times > KVM found 603 times > OptiPlex 7010found 1 times > OptiPlex 7020found 2 times > PowerEdge FC430 found 15 times > PowerEdge FC630 found 56 times > PowerEdge R220 found 1 times > PowerEdge R3
Re: [Puppet Users] How to handle predictable network interface names
On Thu, Aug 25, 2016 at 09:00:46AM -0700, Luke Bigum wrote:
> On Thursday, 25 August 2016 13:31:17 UTC+1, Marc Haber wrote:
> > So the "database" machine wouldn't have an entry in
> > networking::interfaces at all, or could one define, for example, the
> > management interface in networking::interfaces and the database
> > interfaces in the machine-specific hiera tree?
> >
>
> That's technically possible with our module, yes, although I personally
> don't want to mix the styles.
I understand.
> In my current profiles though I started with the management interfaces
> inside the same software profiles. Turns out this was not the best idea as
> they are not directly related, and what our roles should really look like
> is this:
>
> ***
> class role::database {
> include profile::mandatory#Everything mandatory on
> EL6
> include profile::authentication #Authentication is not
> mandatory
> include profile::database #The profile that does
> most of the work for our software
> class { 'profile::management': #management network
> definition and dependent services (sshd, etc)
> type => 'database' #but for a specific
> type of machine
> }
> }
> ***
>
> So management would be separate. This would allow me to do smarter ordering
> of Puppet classes for management services like SSH (and remove a little bit
> more Hiera glue).
That looks smart, thanks.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160826073850.GI2471%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to handle predictable network interface names
On Wed, Aug 24, 2016 at 09:03:16AM -0700, Luke Bigum wrote: > The template will create udev rules from two sources. The first is > @interfaces, which is the giant multi-level hash of network interfaces that > our old designs use. A VM might look like this in Hiera: > > networking::interfaces: > eth0: > ipaddr: 1.1.1.1 > hwaddr: 52:54:00:11:22:33 > > The second source of udev rules is also a Hash and also from Hiera, but > rather than it be embedded in the giant hash of networking information, it > is there to compliment the newer role/profile approach where we don't > specify MAC addresses. This is purely a cosmetic thing for VMs to make our > interface names look sensible. Here is a sanitised Hiera file for a VM with > the fictitious "database" profile: > > profile::database::subnet_INTERNAL_slaves: > - 'eth100' > profile::database::subnet_CLIENT_slaves: > - 'eth214' > networking::extra_udev_static_interface_names: > eth100: '52:54:00:11:22:33' > eth214: '52:54:00:44:55:66' So the "database" machine wouldn't have an entry in networking::interfaces at all, or could one define, for example, the management interface in networking::interfaces and the database interfaces in the machine-specific hiera tree? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20160825123111.GA2471%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to handle predictable network interface names
Hi Rob, On Wed, Aug 24, 2016 at 10:30:20AM -0400, Rob Nelson wrote: > We use VMware's vSphere, which still results in "random" but predictable > interface names - eth0 is now eno16780032, eth1 is now eno3359296, etc. In my experience, the numbers are rather random, different on each VM. > We've stuck with that because while it's somewhat painful (eth# is soo > much easier to comprehend), it's far less painful to memorize that than to > maintain some udev rules that may need tweaked across time. having net.ifnames=0 looks easier than working with those eight-digit numbers. > However, if we were on bare metal, it might be worth disabling the > rules to get the older style back. That's probably still less optimal > than customized names, but it's well documented at least. For > example, http://carminebufano.com/?p=108 or > http://amolkg.blogspot.in/2015/05/centos-7-change-network-interface-name.html > - though there are multiple ways to do it even then. Yes, that's what I'd see as a last moment manoeuvre. My gut feeling says "bad idea, don't do that". I don't have any evidence-based arguments for that though. Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20160825123035.GZ2471%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to handle predictable network interface names
On Wed, Aug 24, 2016 at 09:20:56AM -0700, Luke Bigum wrote: > Now that I think about it, I might be able to post a sanitised version of > the module online with most of the internal stuff stripped out. It might > prove useful for educating our own staff in the concepts, as well as other > people. It's not a 5 minute job though so if/when it's done, I'll write a > new Group post instead of continuing to hijack this one :-) Thanks in advance! Greetings Marc -- ----- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20160825122621.GY2471%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: How to handle predictable network interface names
ame = 'eth0',
> $internal_interface_name = 'eth1',
> $perimiter_interface_name = 'eth2'
> ) {
> firewall { '001_allow_internal':
> chain => 'INPUT',
> iniface => $internal_interface_name,
> action => 'accept',
> proto => 'all',
> }
>
> firewall { '002_some_external_rule':
> chain => 'INPUT',
> iniface => $external_interface_name,
> action => 'accept',
> proto => 'tcp',
> dport => '443',
> }
> }
>
> That very simple firewall profile probably already works on your HP
> hardware, and on your Dell hardware you'd need to override the 3 parameters
> in Hiera:
>
> profile::some_firewall::internal_interface_name: 'em1'
> profile::some_firewall::external_interface_name: 'p3p1'
> profile::some_firewall::perimiter_interface_name: 'p1p1'
On the Dell R680, yes. A hypothetical "R680s" would need some other
definition, and a VMware Vm comes up with eno interfaces with
eight-digit , basically random.
Thanks for your input, I appreciate it.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160825122110.GW2471%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] How to handle predictable network interface names
Hi, I would like to discuss how to handle systemd's new feature of predictable network interface names. This is a rather hot topic in the team I'm currently working in, and I'd like to solicit your opinions about that. On systems with more than one interface, the canonical way to handle this issue in the past was "assume that eth0 is connected to network foo, eth1 is connected to network bar, and eth2 is connected to network baz" and to accept that things fail horribly if the order in which network interfaces are detected changes. While upstream's focus is as usual on desktop machines where Ethernet, USB and WWAN interfaces come and go multiple times a day (see upstream's reasoning in https://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/), this seldomly happens in our happy server environment, which reduces the breakage potential to disruptive kernel updates or vendor firmware changes peddling with the order in which network interfaces are enumerated. This happens rather seldomly in my experience. I would, however, like to stay with the new scheme since I see its charms. But, how would I handle this in a puppetized environment? Currently, the code that is already, for example for a firewall assumes that eth0 is the external interface, eth1 the internal one and eth2 the perimeter networks. In the new setup, all those interfaces can have different names depending on different hardware being used. That means that the same puppet code cannot be used on one firewall instance running on Dell hardware and a second one running on HP hardware because BIOS indices and/or PCI paths will vary. If I used the MAC scheme, things are even worse since interface names will be different even on different pieces of otherwise identical hardware. Many of my team members thinkt hat one should simply turn of predictable network interface names altgether and so that our old code continues to work. I think that this would be a bad idea, but don't have any logical arguments other than my gut feeling. Generating udev rules to fix the network names (and assign names like ext1, int1, per1) already in postinst of the OS does not work since we don't know how the machine is going to be wired and even used. Any ideas? How do _you_ do this? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20160824135527.GP2471%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to access $facts['os'] in a manifest
On Thu, Jun 02, 2016 at 06:10:42PM +0200, Henrik Lindberg wrote:
> With future parser you can do:
>
> notice($os =~ Hash)
>
> Which will notice 'true' if $os is a hash
$ sudo puppet apply -e '$hmpf=is_hash($os) notify{"foo ${hmpf}":}'
Notice: Compiled catalog for hostname in environment production in 0.02 seconds
Notice: foo false
Notice: /Stage[main]/Main/Notify[foo false]/message: defined 'message' as 'foo
false'
Notice: Finished catalog run in 0.25 seconds
So we have stringify_facts turned the wrong way here. Thanks for
helping.
Greetings
Marc
--
-----
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160603102653.GX14027%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to access $facts['os'] in a manifest
On Thu, Jun 02, 2016 at 03:41:35PM +0200, Henrik Lindberg wrote:
> On 02/06/16 14:58, Marc Haber wrote:
> >On Thu, Jun 02, 2016 at 02:42:17PM +0200, Henrik Lindberg wrote:
> >>On 02/06/16 09:22, Marc Haber wrote:
> >>>On Wed, Jun 01, 2016 at 05:34:59PM +0200, Henrik Lindberg wrote:
> >>>>First check what you get in puppet with a simple manifest:
> >>>>
> >>>>notice($facts)
> >>>
> >>>$ sudo puppet apply -e 'notify{"${os}":}'
> >>>Notice: Compiled catalog for host in environment production in 0.02 seconds
> >>>Notice: {"name"=>"CentOS", "family"=>"RedHat", "release"=>{"major"=>"7",
> >>>"minor"=>"2", "full"=>"7.2.1511"}, "lsb"=>{"distcodename"=>"Core",
> >>>"distid"=>"CentOS", "distdescription"=>"CentOS Linux release 7.2.1511
> >>>(Core) ", "release"=>":core-4.1-amd64:core-4.1-noarch",
> >>>"distrelease"=>"7.2.1511", "majdistrelease"=>"7", "minordistrelease"=>"2"}}
> >>>Notice: /Stage[main]/Main/Notify[{"name"=>"CentOS", "family"=>"RedHat",
> >>>"release"=>{"major"=>"7", "minor"=>"2", "full"=>"7.2.1511"},
> >>>"lsb"=>{"distcodename"=>"Core", "distid"=>"CentOS",
> >>>"distdescription"=>"CentOS Linux release 7.2.1511 (Core) ",
> >>>"release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
> >>>"majdistrelease"=>"7", "minordistrelease"=>"2"}}]/message: defined
> >>>'message' as '{"name"=>"CentOS", "family"=>"RedHat",
> >>>"release"=>{"major"=>"7", "minor"=>"2", "full"=>"7.2.1511"},
> >>>"lsb"=>{"distcodename"=>"Core", "distid"=>"CentOS",
> >>>"distdescription"=>"CentOS Linux release 7.2.1511 (Core) ",
> >>>"release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
> >>>"majdistrelease"=>"7", "minordistrelease"=>"2"}}'
> >>>Notice: Finished catalog run in 0.70 seconds
> >>>$ sudo puppet apply -e 'notify{"foo ${facts}":}'
> >>>Notice: Compiled catalog for host in environment production in 0.03 seconds
> >>>Notice: foo
> >>>Notice: /Stage[main]/Main/Notify[foo ]/message: defined 'message' as 'foo '
> >>>Notice: Finished catalog run in 0.81 seconds
> >>>$ sudo puppet --version
> >>>3.8.6
> >>>
> >>>Unfortunately, I cannot see here whether ${os} is actually a string,
> >>>can I?
> >>>
> >>
> >>When you notice ${os} it turns the value into the printed string. That
> >>string looks like a hash, so you are indeed seeing a structure value where
> >>you should be able to access $os[name] etc.
> >
> >How would it look like if ${os} were actually a hash?
> >
> Like in the output you got (above).
> i.e. { "name" => "CentOS", "family" => " ...", ... }
We're turning around in circles. So I cannot see in a notify whether I
am notifying a hash or a stringyfied hash.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160602135524.GL14027%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to access $facts['os'] in a manifest
Hi,
thanks for your answers. They're helpful.
On Thu, Jun 02, 2016 at 02:42:17PM +0200, Henrik Lindberg wrote:
> On 02/06/16 09:22, Marc Haber wrote:
> >On Wed, Jun 01, 2016 at 05:34:59PM +0200, Henrik Lindberg wrote:
> >>First check what you get in puppet with a simple manifest:
> >>
> >>notice($facts)
> >
> >$ sudo puppet apply -e 'notify{"${os}":}'
> >Notice: Compiled catalog for host in environment production in 0.02 seconds
> >Notice: {"name"=>"CentOS", "family"=>"RedHat", "release"=>{"major"=>"7",
> >"minor"=>"2", "full"=>"7.2.1511"}, "lsb"=>{"distcodename"=>"Core",
> >"distid"=>"CentOS", "distdescription"=>"CentOS Linux release 7.2.1511 (Core)
> >", "release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
> >"majdistrelease"=>"7", "minordistrelease"=>"2"}}
> >Notice: /Stage[main]/Main/Notify[{"name"=>"CentOS", "family"=>"RedHat",
> >"release"=>{"major"=>"7", "minor"=>"2", "full"=>"7.2.1511"},
> >"lsb"=>{"distcodename"=>"Core", "distid"=>"CentOS",
> >"distdescription"=>"CentOS Linux release 7.2.1511 (Core) ",
> >"release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
> >"majdistrelease"=>"7", "minordistrelease"=>"2"}}]/message: defined 'message'
> >as '{"name"=>"CentOS", "family"=>"RedHat", "release"=>{"major"=>"7",
> >"minor"=>"2", "full"=>"7.2.1511"}, "lsb"=>{"distcodename"=>"Core",
> >"distid"=>"CentOS", "distdescription"=>"CentOS Linux release 7.2.1511 (Core)
> >", "release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
> >"majdistrelease"=>"7", "minordistrelease"=>"2"}}'
> >Notice: Finished catalog run in 0.70 seconds
> >$ sudo puppet apply -e 'notify{"foo ${facts}":}'
> >Notice: Compiled catalog for host in environment production in 0.03 seconds
> >Notice: foo
> >Notice: /Stage[main]/Main/Notify[foo ]/message: defined 'message' as 'foo '
> >Notice: Finished catalog run in 0.81 seconds
> >$ sudo puppet --version
> >3.8.6
> >
> >Unfortunately, I cannot see here whether ${os} is actually a string,
> >can I?
> >
>
> When you notice ${os} it turns the value into the printed string. That
> string looks like a hash, so you are indeed seeing a structure value where
> you should be able to access $os[name] etc.
How would it look like if ${os} were actually a hash?
> >$ sudo puppet apply -e '$myhash={ key1 => 'val1', key2 => 'val2' }
> >notify{"foo ${myhash}":}'
> >Notice: Compiled catalog for host in environment production in 0.08 seconds
> >Notice: foo {"key1"=>"val1", "key2"=>"val2"}
> >Notice: /Stage[main]/Main/Notify[foo {"key1"=>"val1",
> >"key2"=>"val2"}]/message: defined 'message' as 'foo {"key1"=>"val1",
> >"key2"=>"val2"}'
> >Notice: Finished catalog run in 0.71 seconds
> >$ sudo puppet apply -e '$mystring="{\"key1\"=>\"val1\", \"key2\"=>\"val2\"}"
> >notify{"foo ${mystring}":}'
> >Notice: Compiled catalog for host in environment production in 0.03 seconds
> >Notice: foo {"key1"=>"val1", "key2"=>"val2"}
> >Notice: /Stage[main]/Main/Notify[foo {"key1"=>"val1",
> >"key2"=>"val2"}]/message: defined 'message' as 'foo {"key1"=>"val1",
> >"key2"=>"val2"}'
> >Notice: Finished catalog run in 0.72 seconds
> >1.pportal|e13itfe@jira01 ~ $
> >
> >Is ${os} now a string or not?
>
> There is no mention of ${os} in that snippet
Misleading question. The snipped was to find out how a notified hash
looks like and a notified string that looks like a stringyfied hash.
There seems to be no difference.
> >And, why is ${facts} obviously empty?
> >
>
> By default, $facts is an opt in before 4.0 and did not exist before 3.5.0.
I missed the part that it's default off in pre 4.0.
> In almost every case it is ok to turn on support for $facts. It only breaks
> something if you already have global variables that clash (very unlikely).
Opened a local ticket.
Thanks agan.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160602125842.GJ14027%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to access $facts['os'] in a manifest
On Wed, Jun 01, 2016 at 05:34:59PM +0200, Henrik Lindberg wrote:
> First check what you get in puppet with a simple manifest:
>
> notice($facts)
$ sudo puppet apply -e 'notify{"${os}":}'
Notice: Compiled catalog for host in environment production in 0.02 seconds
Notice: {"name"=>"CentOS", "family"=>"RedHat", "release"=>{"major"=>"7",
"minor"=>"2", "full"=>"7.2.1511"}, "lsb"=>{"distcodename"=>"Core",
"distid"=>"CentOS", "distdescription"=>"CentOS Linux release 7.2.1511 (Core) ",
"release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
"majdistrelease"=>"7", "minordistrelease"=>"2"}}
Notice: /Stage[main]/Main/Notify[{"name"=>"CentOS", "family"=>"RedHat",
"release"=>{"major"=>"7", "minor"=>"2", "full"=>"7.2.1511"},
"lsb"=>{"distcodename"=>"Core", "distid"=>"CentOS", "distdescription"=>"CentOS
Linux release 7.2.1511 (Core) ", "release"=>":core-4.1-amd64:core-4.1-noarch",
"distrelease"=>"7.2.1511", "majdistrelease"=>"7",
"minordistrelease"=>"2"}}]/message: defined 'message' as '{"name"=>"CentOS",
"family"=>"RedHat", "release"=>{"major"=>"7", "minor"=>"2",
"full"=>"7.2.1511"}, "lsb"=>{"distcodename"=>"Core", "distid"=>"CentOS",
"distdescription"=>"CentOS Linux release 7.2.1511 (Core) ",
"release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
"majdistrelease"=>"7", "minordistrelease"=>"2"}}'
Notice: Finished catalog run in 0.70 seconds
$ sudo puppet apply -e 'notify{"foo ${facts}":}'
Notice: Compiled catalog for host in environment production in 0.03 seconds
Notice: foo
Notice: /Stage[main]/Main/Notify[foo ]/message: defined 'message' as 'foo '
Notice: Finished catalog run in 0.81 seconds
$ sudo puppet --version
3.8.6
Unfortunately, I cannot see here whether ${os} is actually a string,
can I?
$ sudo puppet apply -e '$myhash={ key1 => 'val1', key2 => 'val2' } notify{"foo
${myhash}":}'
Notice: Compiled catalog for host in environment production in 0.08 seconds
Notice: foo {"key1"=>"val1", "key2"=>"val2"}
Notice: /Stage[main]/Main/Notify[foo {"key1"=>"val1", "key2"=>"val2"}]/message:
defined 'message' as 'foo {"key1"=>"val1", "key2"=>"val2"}'
Notice: Finished catalog run in 0.71 seconds
$ sudo puppet apply -e '$mystring="{\"key1\"=>\"val1\", \"key2\"=>\"val2\"}"
notify{"foo ${mystring}":}'
Notice: Compiled catalog for host in environment production in 0.03 seconds
Notice: foo {"key1"=>"val1", "key2"=>"val2"}
Notice: /Stage[main]/Main/Notify[foo {"key1"=>"val1", "key2"=>"val2"}]/message:
defined 'message' as 'foo {"key1"=>"val1", "key2"=>"val2"}'
Notice: Finished catalog run in 0.72 seconds
1.pportal|e13itfe@jira01 ~ $
Is ${os} now a string or not?
And, why is ${facts} obviously empty?
> If all the data elements are strings, turn off stringify_facts - it flattens
> data and makes all facts be strings.
I cannot do this in the production without excessive coordinative
effort. The colleagues managing the master side say that haven't
explicitly configured that settings and are going to stay with the
default.
> If you can, hop on to the puppet slack or IRC channels to get more help from
> community members - always easier interactively.
I am reluctant to discuss configuration snippets on IRC and currently
cannot guarantee timely answers. And, I am trying to cut down on the
number of IRC channels I am on ;-) But I'll think about it.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
--
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/20160602072200.GA14027%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] How to access $facts['os'] in a manifest
Hi,
I have the following code:
if( $facts['os']['family'] == 'RedHat' and $facts['os']['release']['major']
== '7' ) {
file { "...":
ensure => 'file',
path=> "...",
content => "...",
}
}
My agent is puppet 3.8.4, my master is 3.7.3 with no special
configuration.
Here is the fact:
$ facter | grep ^os
os => {"name"=>"CentOS", "family"=>"RedHat", "release"=>{"major"=>"7",
"minor"=>"2", "full"=>"7.2.1511"}, "lsb"=>{"distcodename"=>"Core",
"distid"=>"CentOS", "distdescription"=>"CentOS Linux release 7.2.1511 (Core) ",
"release"=>":core-4.1-amd64:core-4.1-noarch", "distrelease"=>"7.2.1511",
"majdistrelease"=>"7", "minordistrelease"=>"2"}}
osfamily => RedHat
When building the catalog, I get the dreaded "facts is not a hash or
array". When searching for this, I get tangled in a maze of "if your
agent is older than foo, and your server has stringify_bla set, then
you might succeed with baz."
How do I write my manifest to get things
(a) pretty
(b) non-deprecated?
Any hints will be appreciated.
Greetings
Marc
--
-
Marc Haber | "I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things."Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
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/20160601144332.GA24651%40torres.zugschlus.de.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] puppet-4-able agent for RHEL7 on ppc64?
Hi, I am looking for a puppet agent rpm that can run against a puppet 4 server (and can use its features) for RHEL 7 on ppc 64. On yum.puppetlabs.com, I can only find binaries for agent 1.2.4 (latest version) for x86_64 and i386, and the corresponding SRPM directories do only have puppetdb and puppetserver src.rpms. What can I do to be able to use puppet 4 with my ppc64 LPAR systems? Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421 -- 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/20150924125447.GI23456%40torres.zugschlus.de. For more options, visit https://groups.google.com/d/optout.
Re: [Puppet Users] How to create a directory if that path does not yet exist?
On Mon, Oct 01, 2012 at 04:11:06PM -0400, Thomas Linkin wrote: There is no way in the resource declaration for 'file' to stop it from ensuring your symlink is made into a directory. That is because this is the state you're asking to have ensured when you compile that resource into a catalog. What you may want to do is find a way to have the resource either ensure a symlink for those hosts or not be in your catalog. I recommend the finding a way to have it ensure a symlink. Thanks for the explanation. I'm going to use an exec. Ugly, but it will be easier to understand than the other options you mentioned. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: How to recursively ship files while keeping their modes
Hi, On Mon, Sep 17, 2012 at 07:39:38AM -0700, Alessandro Franceschi wrote: Have you tried to add: mode = undef, it might work (not tested). thanks for answering. I have lost my puppetmaster VM due to filesystem failure[1] and have not yet built a new one[2]. I will report whether your hint worked when I have built a new one. Greetings Marc [1] and, it being a test system, it was of course not backed up [2] and I cannot try that in the live puppet due to team rules -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] How to create a directory if that path does not yet exist?
Hi,
I have the following resource defined:
file { /var/lib/foo:
ensure = directory,
owner = root,
group = root,
mode = 0755,
}
On some systems, but not on all, I have /var/lib/foo symlinked to
another partition with more space. Those symlinks (/var/lib/foo =
/space/foo) are replaced during the puppet run with a local directory.
Neither the force nor the replace parameter to the File resource seems
to stop this behavior.
Is there anyway to obtain this behavior short of using an exec?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] How to recursively ship files while keeping their modes
Hi,
I have defined a resource like this:
file { /etc/foo/conf.d :
ensure = directory,
recurse = true,
purge = true,
force = true,
owner = root,
group = root,
source = puppet:///modules/foo/client/etc/foo/conf.d,
}
This works fine.
However the directory contains both snippets that need to be taken
verbatim (with mode 644) and executeables that need to be executes and
their output taken (with mode 755). It is ok to deliver the
executeables, since the code running on the target which builds the
actual foo.conf out of the contents of foo/conf.d takes care of this,
but it needs the mode for doing so.
This mechanism is in use inside a Debian package, and I would like to
be of least surprise for the casual user, so I'd like to keep this
scheme albeit puppet would be able to generate a monolithic
configuration itself.
Puppet seems to always reset the access bits for others, so 644
mutates to 640 on the target system. I cannot say whether this is
deliberate configuration of the people running the puppet master or
whether this is a feature of puppet.
Is this a feature of puppet? If yes, is there a possibility to have
puppet 2.7.18 ship the files with the mode given to them in the
modules/foo/client/etc/foo/conf.d directory on the Master?
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to subscribe to an exported resource?
On Thu, Aug 16, 2012 at 01:27:04PM +0200, Marc Haber wrote: On Wed, Aug 15, 2012 at 08:34:03PM +0200, Marc Haber wrote: On Tue, Aug 14, 2012 at 07:58:21PM +0100, Stephen Gran wrote: The classic is: https://github.com/ripienaar/puppet-concat So that is a module that would need to be compiled and installed (on the puppetmaster, run by a different department)? Sorry, I got confused by the rakefile and didn't scroll down all the way where the docs are. I have now understood ;-) This works fine, and I have already used it in multiple places. Very helpful, thanks. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to subscribe to an exported resource?
On Wed, Aug 15, 2012 at 08:34:03PM +0200, Marc Haber wrote: On Tue, Aug 14, 2012 at 07:58:21PM +0100, Stephen Gran wrote: The classic is: https://github.com/ripienaar/puppet-concat So that is a module that would need to be compiled and installed (on the puppetmaster, run by a different department)? Sorry, I got confused by the rakefile and didn't scroll down all the way where the docs are. I have now understood ;-) Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] How to subscribe to an exported resource?
On Tue, Aug 14, 2012 at 07:58:21PM +0100, Stephen Gran wrote: The classic is: https://github.com/ripienaar/puppet-concat So that is a module that would need to be compiled and installed (on the puppetmaster, run by a different department)? Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: How to subscribe to an exported resource?
On Wed, Aug 15, 2012 at 06:43:18AM -0700, jcbollinger wrote: On Tuesday, August 14, 2012 6:27:36 AM UTC-5, Marc Haber wrote: I would, however, prefer to have the exec subscribed to the File instead of notifying the exec from the File. Why? Personal style, fits better into the rest of the core, more linear. With that said, Stephen is right that you are reinventing the wheel (though he didn't put it in those terms). The Concat module is all about constructing files from pieces, and those pieces can easily be imported resources declared by other nodes. I'll talk to the people running the puppetmaster whether they can install the concat module. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061 Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] How to subscribe to an exported resource?
Hi,
I am trying to build (on node A) an authorized_keys file that contains
all host keys from all nodes that have class C imported. Here is my
code:
class C {
@@file { /var/lib/foo/authorized_keys/$fqdn:
ensure = present,
content = from=\$ipaddress_eth0\ ssh-rsa $sshrsakey\n,
tag = foo,
}
}
node A {
class { 'bar': }
}
class bar {
File | tag == 'foo' | {
notify = Exec[/home/bar/.ssh/authorized_keys],
}
exec { /home/bar/.ssh/authorized_keys:
command = cat /var/lib/foo/authorized_keys/*
/home/bar/.ssh/authorized_keys
path = /bin:/usr/bin,
provider = shell,
}
}
This works.
I would, however, prefer to have the exec subscribed to the File
instead of notifying the exec from the File. I would like to write
class bar {
File | tag == 'foo' |
exec { /home/bar/.ssh/authorized_keys:
command = cat /var/lib/foo/authorized_keys/*
/home/bar/.ssh/authorized_keys
path = /bin:/usr/bin,
provider = shell,
subscribe = File | tag == 'foo' |,
}
}
which doesn't compile.
How can I refer to the File in my exec?
That being said, is there a way to do things more elegantly? I
understand that I need to create one file by node of class C, or is
there a way to have the exported resources all concatenated into the
same file?
Any hints will be appreciated.
Greetings
Marc
--
-
Marc Haber | I don't trust Computers. They | Mailadresse im Header
Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 31958061
Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
