[Puppet Users] Managing MySQL Users and Permissions with Puppet

[Jonathan Preston]

I've searched for answers, but couldn't find anything quite matching my use 
case.

I have a series of servers, managed with Puppet and Foreman. These make up 
my company's development, staging, and production environments, plus a few 
small stand-alone servers for side projects.

I want to manage MySQL permissions on these servers, but the trick is that 
each server environment may have some different accounts.

We use scripts based around Percona XtraBackup to copy production databases 
to staging and development environments for testing purposes. If I restore 
a backup from our production environment to our development environment, it 
copies all the data, which is good, but it also sets the users and 
permissions to match the production environment as well. This is a problem 
in our case.

What I want to do is configure, in Puppet/Foreman, all of the credentials 
that should be present on a given server, and have the Puppet client not 
only set up whatever the Puppet master says, but also purge any credentials 
that aren't in the list. In other words, the accounts I specify, and only 
those, should end up on the Puppet client machine, and Puppet should be 
responsible for purging anything else there.

Naturally, I don't want to rebuild the grant tables every time Puppet runs, 
so I presume I'd need a way to intelligently read and parse what's already 
there.

Is anyone aware of someone having done something like this? Any ideas at 
all on how I might accomplish it?

Thanks in advance.

-- 
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/64266da0-47c4-4b4c-ba6c-48ce2e2eea2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PuppetDB: manually import reports

[Wyatt Alt]

On 4/19/18 4:46 AM, Thomas Müller wrote:

HI

I've got some prod puppetserver/puppetdb and some dev 
puppetserver/puppetdb. But to have the complete overview over all 
nodes with the prod puppetdb I'd like to import the reports from the 
dev puppetserver (stored by reports=store config) into the prod puppetdb.


is there some hidden tool to do so? I wasn't able to find anything in 
that direction.


Reading 
https://github.com/puppetlabs/puppetdb/blob/master/puppet/lib/puppet/reports/puppetdb.rb 
this could maybe adapted to read a yaml file and then send it to puppetdb.


If I'm understanding you right, you could normally use the import/export 
tools for this:


https://puppet.com/docs/puppetdb/5.0/anonymization.html#using-the-export-command

There's a corresponding "admin" API on PuppetDB you can search for. The 
process would be to do an export, extract the resulting tarball and 
remove everything but reports (if desired), then tar it up again and run 
it through the import tool. Unfortunately though, this is broken for me 
on current PDB due to PDB-3796. If you're on an older version it may be 
worth a try -- it worked at some point. If you've got the bug it'll 
cause your dev server to OOM and restart.


Assuming that's broken for you too, I think the most tractable way to do 
what you're asking is basically what you're suggesting -- either parse 
the yaml reports into the report wire format 
(https://puppet.com/docs/puppetdb/5.1/api/wire_format/report_format_v8.html) 
and post to your prod PDB's commands endpoint 
(https://puppet.com/docs/puppetdb/5.1/api/command/v1/commands.html) or 
get the json reports out of your dev PuppetDB, in batches to work around 
the bug, and do the equivalent parsing/posting. The wire formats change 
from time to time so take care to use whatever version of the docs 
aligns with your PDB version.


Wyatt




- Thomas
--
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/d5a3b811-655f-4497-84de-a5693954d08e%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
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/ae2bf29b-c3e5-c0cf-8bff-a75258cad299%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppetserver vardir configuration

[jcbollinger]

Ok, now this is getting weird.

I had originally specified vardir in the [master] section of puppet.conf, 
and not specified reportdir explicitly.  I had that setup for weeks, and 
yesterday discovered reports only under a different directory, as described 
in the previous message.

After discovering the problem, I tried setting both vardir and reportdir in 
the [main] section instead, but after restarting the puppetserver service, 
I observed new reports still being written in the same place as before.  
That's when I wrote the previous message.

Afterward, I went home for the day, leaving the Puppet configuration as it 
was.  This morning, I find that reports for all nodes are now being stored 
in the directory I designated.  Node facts, however, are still being 
recorded relative to puppetserver's default vardir, not the one specified 
in puppet.conf.  The only notable thing I am aware of that happened 
overnight is that a handful of new nodes were enrolled and started making 
catalog requests.  I did also change my environment timeout to 0 yesterday 
(in the [master] section of my configuration), but only before moving 
around the vardir and reportdir settings.

So what gives?


John

-- 
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/a8b97e1e-b2b9-49ea-a536-4fece6e16d96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: puppet "package" resource type for multi-file installer

[Ty Young]

puppet/archive sounds cool, potentially.  Thanks for the recommendations, 
guys.Just to be sure I've communicated clearly:

   - my Puppet master (5.4) is RHEL7 and contains a Windows installer .zip 
   file in /somedir
   - one or more nodes onto which I want to push my installer .zip file are 
   Windows servers
   - after I push the .zip file up, I want Puppet to unzip it into a temp 
   location (i.e. C:\temp\) then install it

I'm not 100% sure on the usage for puppet/archive in this use case.


Thanks

ty

On Wednesday, April 18, 2018 at 9:55:40 PM UTC-5, Ty Young wrote:
>
> I'm still ramping up on Puppet 5.4.0, but I'm stuck on something.
>
> I have a customer needing to automate installation of a software package 
> on Windows nodes. The installer is most easily transported as a .zip file, 
> but (obviously) would need to be unzipped before running the enclosed .bat 
> file to perform the installation.  
>
> Any suggestions?   
>
> Thanks
>
>

-- 
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/f5343a41-46f6-48de-8c9b-3e176bdc291a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PuppetDB: manually import reports

[jcbollinger]

On Thursday, April 19, 2018 at 2:30:11 PM UTC-5, Thomas Müller wrote:
>
>
>
> Am Donnerstag, 19. April 2018 19:18:34 UTC+2 schrieb Christopher Wood:
>>
>> To challenge an assumption, what are you gaining from having more than 
>> one puppet infrastructure (puppetservers+puppetdb)? 
>>
>> Could you perhaps handle your dev stuff with another environment or set 
>> of puppetservers under the same CA with the same puppetdb? 
>>
>> Is there any reason for a separate puppet infrastructure to live longer 
>> than it takes to proof an upgrade for production? 
>>
>
> I can't just throw away the dev infra after preparing changes for prod 
> because of non-technical reasons. i'm limiting the usage of the dev system 
> as much as I can, but there will be system connected to this dev infra. but 
> I also want the data in the prod puppetdb to have a single point to make 
> queries/reports (third party departments) or run octocatalog-diff to run 
> against real facts from any system. 
>


That seems to respond only to Am's last question.  You can have varying 
degrees of dev / prod separation while still maintaining a shared CA and 
puppetdb, and that has nothing to do with the lifetime or life cycle of the 
dev machines.  I strongly advise at least the shared CA if you're 
contemplating combining dev and prod data by any mechanism.

There are several good reasons to prefer the minimum separation of Puppet 
infrastructure, especially since for at least some purposes, you want to 
aggregate the dev and prod data.  And doing so would take care of the 
problem up front -- there would be no extra step needed to aggregate dev 
and prod data, because it would not be physically separated in the first 
place.
 

>
> Another usecase could be to have a async puppetdb connection from the 
> second datacenter. If the connection between the datacenters is not  stable 
> enough to use a single puppetdb I would need to add a puppetdb per DC.Then 
> I also would want to sync data to the central puppetdb instance.
>
>
Is that an *actual* use case or a hypothetical one?

If hypothetical, then don't let it influence your decisions about your 
actual use cases: if and when you need to account for that, the details 
will matter, and the technological landscape will have changed, so any 
time, effort, and compromises made to accommodate it now will probably be 
wasted.  If it never materializes as an actual use case, then resources 
spent now to accommodate it will *definitely* be wasted.

If you do need to account for it now, then you should still use at least a 
common CA.  It might make sense to use common aggregated puppetdb database, 
too, maybe supported by database synchronization between the PG instances 
at the PG level.  It's hard to make good recommendations, however, without 
a better handle on the requirements for this scenario.


John

-- 
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/09201110-7ca2-4757-ae3d-56e7b3e08346%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: linux domain machines - cert error

[jcbollinger]

On Thursday, April 19, 2018 at 6:44:57 PM UTC-5, empb...@gmail.com wrote:
>
> Hello guys,
>
> At my place of work we have some computer labs. In these laboratories each 
> computer has the operating system windows and linux. Both systems are in 
> our AD domain.
>
> I did a lab of tests and I have a functional puppet server. I put some 
> nodes as root of the system. Everything working perfectly.
>
> When I log in with a domain user on linux machines and run the "puppet 
> agent -t" command, a new certificate is generated, but an error occurs 
> stating that it does not match the server's certificate.
>
> How can I get around this and make it always the same certificate?
>


It sounds like your machines use the same hostname whether they are running 
Windows or Linux.  This makes sense from a physical perspective, but not 
from a logical one -- one of your machines has very different 
characteristics when running Windows than it does when running Linux.

In any case, the Puppet installations on Windows and Linux are separate and 
do not share data (by default), so each manages its own certificate.  In 
that sense, they absolutely are distinct machines from Puppet's 
perspective.  By default, however, Puppet uses machines' hostnames as their 
certificate names, so if you have two machines with the same hostname then 
their certificates will collide.  It will also happen if you rebuild / 
re-image your machines without preserving their certificates, but reusing 
the same hostnames.

You have several options for working around that, among them:

   - Give your machines different hostnames for Windows and Linux.  The 
   easiest way to do that might be to add "-linux" and / or "-windows" 
   suffixes to the hostnames you are using now.  Then each personality of each 
   machine has a distinct name, and everything should just work.
   - Use the 'certname' setting in your machines' Puppet configuration (
   [main] section) to assign a unique certname to each personality of each 
   machine.  Perhaps you could use a pattern similar to the one I suggested 
   for unique hostnames.
   - You could also arrange for your machines to share their certificates 
   between their two personalities, either by copying them or by putting them 
   in a place that both personalities can access.  I have several technical 
   reasons to dislike this alternative, and I don't recommend it, but having 
   understood the problem, you probably would have thought of it anyway.

 John

-- 
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/4bdc7608-17ce-4c52-b0f9-dfce67d9c151%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Accessgin facts hash from manifests

[Arnau]

Hi all,

I'm having the first experiences with puppet 5 & facter 3

In old puppet versions I tend to add debug messages like:

notify { "OS : {::osfamily}: }

and it usually worked.

According to https://puppet.com/docs/puppet/5.3/lang_facts_and_
builtin_vars.html#accessing-facts-from-puppet-code I can still access the
facts using the old way, but it recommend to use the facts has, so the new
code should look like:


  notify { "OS: $facts[os][family]": }

But when I do that I get the full list of facts and [os][family] at the
bottom:


Notice: OS: {agent_specified_environment => test, aio_agent_version =>
5.5.1, architecture => x86_64, augeas => {version => 1.10.1}
[ TONS OF FACTS ...]  clientversion => 5.5.1, clientnoop =>
false}['os]['family']"

If I use the same syntax in a conditiona statement:

  if $facts['os']['family'] == 'RedHat' {
notify { "I'm a RedHat": }
  }

then it works:

Notice: /Stage[main]/Common::Yumrepos/Notify[I'm a RedHat]/message: defined
'message' as 'I\'m a RedHat'

So, what's wrong with the above notify?


TIA,
Arnau

-- 
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/CAM69jx_sAms0%3Da%2B5MhHBtnydtPKsUDeAAcera8tXSsaANaTchA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.