On Sunday, January 25, 2015 at 4:52:08 PM UTC-6, Karen Ellrick wrote: > > I apologize in advance if this question is too general - I'm happy to > share specifics as needed. I'll attach a couple key files as a start on > that. >
It's not a major problem that you don't know off the bat what details are important. It is potentially a problem, however, that your question is more about PuPHPet and perhaps Vagrant than about Puppet. There are users of both those tools who frequent this forum, so you may be in luck, but I hope you will understand that your question is somewhat tangential to the main topic of this group. > > I used the online tool PuPHPet to create a CentOS box that was close to > meeting my needs, but because of that, my Puppet files are apparently more > complex than they need to be (all examples I have seen in tutorials are far > simpler). > Yes and no. The code generated by PuPHPet is more complex than would normally be found in a single Puppet manifest file, but that appears largely to be because it comprises code that would normally be divided among multiple separate files. Furthermore, most of those separate files would probably come from various downloadable third-party modules. So you're right in thinking that you would not normally write Puppet code anything like that complex, especially when you're just getting started with Puppet. > Then, because I was completely new to all this, I made changes to my > actual server (by SSHing into my VM and rummaging around) while having > absolutely no idea how to reflect those changes in the Puppet files. > > Not being a PuPHPet initiate myself, I'm uncertain whether that's an important issue. 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. If it does, however, then then I suggest taking a clue from the (maddeningly sparse) documentation <https://puphpet.com/help>: 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*! > That appears to be referring to a data file for Puppet's 'Hiera' component, which would make sense. We can certainly help you in a generic sense with Hiera data, but it remains to be seen how well we can help you match up the customizations you want with the specific Hiera keys and appropriate structures for data associated with those keys. The latter are not a function of Puppet itself. > Since then I have procrastinated on climbing this learning curve, but > recently I upgraded Vagrant on the host, and now "vagrant global-status" > says, "There are no active Vagrant environments on this computer! Or, you > haven't destroyed and recreated Vagrant environments that were started with > an older version of Vagrant." Hmph! I know I will lose my changes if I > destroy and recreate, so I really need to figure out how to clean up my > Puppet files. > > The directory structure looks like this: > > │ Vagrantfile > │ > ├─.vagrant > │ └─machines > │ └─default > │ └─virtualbox > │ action_provision > │ action_set_name > │ id > │ private_key > │ synced_folders > │ > └─puphpet > │ config.yaml > │ > ├─files > │ ├─dot > │ │ .bash_aliases > │ │ .vimrc > │ │ > │ ├─exec-always > │ │ empty > │ │ > │ └─exec-once > │ empty > │ > ├─puppet > │ hiera.yaml > │ manifest.pp > │ Puppetfile > │ > └─shell > execute-files.sh > initial-setup.sh > install_phalcon-devtools.sh > install_phalcon.sh > librarian-puppet-vagrant.sh > os-detect.sh > self-promotion.txt > update-puppet.sh > > To the extent that various configuration files were created and are managed by Puppet, I would expect to see corresponding ERB template files, but I don't. I also don't see a wide variety of other files associated with Puppet classes and defined types that are referenced by your 'manifest.pp', but not defined there. It may be that these are downloaded to new VMs as part of the process of applying their initial configuration. > puphpet/puppet/manifest.pp alone is 920 lines! I'm pretty sure most of > that, as well as many of the other files, is unneeded code (I keep seeing > things like "if $::osfamily == 'debian'...", for example). But the syntax > is new to me, so I'm afraid to start slashing chunks of it. > > 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. In any event, it doesn't look like trimming it back would help you solve your immediate problem. (Nevertheless, Puppet's own docs <https://docs.puppetlabs.com/>, covering its manifest file language and many other things <https://docs.puppetlabs.com/puppet/3.7/reference/>, are far more comprehensive than PuPHPet's. The basics of the language are not hard to learn, if you're interested.) > A key piece of work I remember doing was on the nginx configuration, so > I'll throw it out as a concrete example. A tree of the VM's /etc/nginx/ is > as follows, with sizes and dates (as you can probably guess, I made the box > in February last year and then fiddled with it off and on over the next > couple months): > > ├── [ 4096 Mar 6 2014] conf.d > │ ├── [ 888 Feb 13 2014] default.conf > │ ├── [ 427 Feb 11 2014] example_ssl.conf > │ ├── [ 415 Feb 13 2014] proxy.conf > │ └── [ 1469 Apr 26 2014] vhost_autogen.conf > ├── [ 4096 Feb 13 2014] conf.mail.d > ├── [ 963 Mar 6 2014] fastcgi_params > ├── [ 4096 Mar 6 2014] includes.d > │ └── [ 1127 Mar 25 2014] fastcgi_common > ├── [ 2837 Feb 11 2014] koi-utf > ├── [ 2223 Feb 11 2014] koi-win > ├── [ 3463 Feb 11 2014] mime.types > ├── [ 565 Apr 19 2014] nginx.conf > ├── [ 596 Feb 11 2014] scgi_params > ├── [ 623 Feb 11 2014] uwsgi_params > └── [ 3610 Feb 11 2014] win-utf > > Most of the work I remember doing is in vhost_autogen.conf, but the string > "autogen" doesn't appear in manifest.pp, so I don't know what code created > that file. Perhaps I'm hopelessly ignorant, but can someone point me in the > right direction? It's too bad that it isn't possible to create a Puppet > manifest from an existing server... ;-) > 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. I would certainly back up your VM -- at least the parts containing configuration you don't want to lose. The task before you is to figure out how to record your customizations in the form of Hiera data. 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. Good luck, and feel free to follow up with other questions you may have. 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/6897b81f-1d42-4423-97d1-27e8c430cec3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
