John,
Thanks for a thorough and helpful reply.
In particular, I am uncertain whether Puppet has any role in managing a
> PuPHPet-generated server configuration after it is initially created, or in
> initializing new VMs.
>
My understanding (which could be flawed, of course) is that PuPHPet is
merely an online tool designed to quickly build a functioning set of Puppet
files tailored for PHP developers, based on a finite set of selections (OS,
server packages, etc.). It's a time saver for getting started - think
"wizard". After that, the developer would customize the resulting Puppet
code as needed - PuPHPet's interface is not even close to being detailed
enough to allow every contingency (if it was, it would take a week to go
through the wizard to get anything done!). I'm pretty sure it is not
intended to be used over and over for minor changes to the same box.
(docs) "I have completely rewritten PuPHPet to take advantage of a built-in
>> configuration tool for Puppet called Hiera. Simply look inside your
>> downloaded folder and open puppet/hieradata/common.yaml. This is the
>> magical file that controls *everything*!"
>>
>
Based on the fact that my downloaded folder doesn't have a hieradata
directory and my hiera.yaml file has only six lines of code, I think that
Juan did that rewrite *after* the one and only time I used PuPHPet, which
was almost a year ago. Here is the entire contents of hiera.yaml:
---
:backends: yaml
:yaml:
:datadir: '/vagrant/puphpet'
:hierarchy:
- config
:logger: console
Based on my cursory look at the Hiera docs, that looks like something Juan
was just starting to use, not yet pivotal to his setup. I don't have any
urge to use Hiera unless there is a huge benefit - it's enough for me to
learn one tool.
> You are right that the manifest is more general than you need it to be,
> but it appears to be a generated file. It is not intended to be maintained
> manually. Indeed, I suppose that the idea is for you to use PuPHPet to
> generate an altogether new one if needed.
>
As I said before, I think PuPHPet is just a "wizard" - yes, the manifest is
generated, but manually maintaining it from then on is the normal workflow,
I assume. In any case, I have no choice - PuPHPet cannot give me everything
I need. If I should start over with a simpler, manually written Puppet
setup, that's fine.
> In any event, it doesn't look like trimming it back would help you solve
> your immediate problem.
>
True, but it would make the file easier to look through. And my server
would have less bloat, also - earlier today I looked through manifest.pp
and noticed modules it installs that I don't think I need (or want) on my
server at all, so I started my cleanup by commenting out those sections.
(As far as I remember, PuPHPet's interface didn't ask me if I wanted each
of those things - it just assumed.) Once I get as far as I can with
reflecting my desired server changes in Puppet and bravely recreate the
server, if it still does what I need, I'll remove the commented code.
> The basics of the language are not hard to learn, if you're interested.
>
Yup, that's the idea of posting here. I do want to learn, but I'm the
impatient type - I tend to start learning a new tool by doing something I
actually need to do, not just experimenting with a tutorial.
> As I already noted, one of the things that appears to be causing confusion
> is that you're not looking at all the relevant files. There is a veritable
> host of relevant Puppet manifest files that do not appear in your listing,
> plus the key Hiera data file that PuPHPet's online help references. The
> default location for such files would be either /etc/puppet or
> ~someuser/.puppet, depending on how Puppet is being run. Perhaps you could
> 'find' the 'hieradata' directory, the 'common.yaml' file, or a
> 'puppet.conf' file.
>
Oh! I didn't realize that there was more Puppet stuff on the VM itself!
Sorry - I was just looking in the files in the ZIP file PuPHPet generated
(which is on the host). It looks like the stuff you're looking for (at
least some of it) is in /etc/puppet/modules/puphpet/ - here is the tree:
puphpet/
├── files
│ └── xdebug_cli_alias.erb
├── LICENSE
├── manifests
│ ├── adminer.pp
│ ├── apache
│ │ ├── modpagespeed.pp
│ │ └── modspdy.pp
│ ├── ini.pp
│ ├── mariadb.pp
│ ├── nginx.pp
│ ├── params.pp
│ └── xdebug.pp
├── README.md
└── templates
├── apache
│ └── mod
│ └── spdy
│ ├── php-wrapper.erb
│ └── spdy_conf.erb
└── nginx
└── default_conf.erb
Apparently these files get created by Vagrant after the server is created
and fired up for the first time. There's clearly more to how Puppet runs
than I realized. Anyway, the /etc/puppet/modules directory has other
modules, too - at first glance it looks like there is a directory there for
every section of the original manifest.pp:
apt/ concat/ iptables/ mysql/ php/ rabbitmq/
supervisord/
beanstalkd/ drush/ mailcatcher/ nginx/ puphpet/ staging/ vcsrepo/
composer/ git/ mongodb/ ntp/ puppi/ stdlib/ yum/
And yes, there is also a /etc/puppet/puppet.conf file. But there is no
common.yaml, and although Hiera itself is installed on the server, there is
no hieradata.
The task before you is to figure out how to record your customizations in
> the form of Hiera data.
>
Does it need to be Hiera, or is it optionally Puppet itself?
> Moreover, you need to be aware that although you can probably extract the
> needed data and present it to Puppet, the config files it generates when
> you have successfully done so are likely to be *equivalent* rather than
> *identical*. I'm afraid that will complicate the verification process.
>
As long as my stuff runs, I'm happy. What I have done so far is easily
testable. I'm new to nginx also, so I may not have made the cleanest config
files in the world, anyway. After this, I'll keep the horse in front of the
cart, making changes in Puppet and rebuilding, rather than messing with the
server directly. It's a new paradigm, but I can learn.
Karen
>
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/4ce49f2c-9450-41e9-996a-f6b6c98e8143%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
