I am configurating multiple systems with vagrant and puppet (CentOs). I have a module which should make them all known to each other by hostname (module 'hosts').
Every machine generates a subclass called like itself, with the own hostname and ip (ex.: hosts::machine1).
Now my problem is that they have all to be included in init.pp of the host module to be executed. The machine names and count are different from run to run.
At the moment i include the subclasses each by hand ( include hosts::machine1, include hosts::machine2).
So now to my question:
Is there a possibility to include all subclasses of a module? or of a folder?
Or what would be a better way to solve this?
Greets
You're not required to generate Puppet code in classes. You could generate top-scope code instead.
# manifests/machine1.pp
host { 'machine1': ip => 'x.x.x.x' }
Make sure to configure Vagrant to use the whole manifests/ directory as the manifest. Then all resources declared in the contained .pp files will be honored.
I don't know whether Vagrant can be made to talk to PuppetDB. If it can, you should probably use exported resources for this.
Each node exports its own entry
##host { $fqdn: ip => $ipaddress, tag => 'my-cluster' }
Each note imports all entries
Host<<| tag == 'my-cluster' |>>
# also realize own export:
Host<| tag == 'my-cluster' |>
Related
I can use puppet to set up my apache httpd and add virtual hosts and load needed modules. I also know how to add custom configuration within a virtual host using the customconf-value but...
How do I configure in my pp-file to add my custom configuration in the main server config context? (I.e. outside of the virtual hosts)
I am using the standard apache module in puppet https://github.com/puppetlabs/puppetlabs-apache
I have read the documentation several times and also tried following the broken links to for example apache::mod documentation (to see if there is some similar value like customconf but... with no success).
How do I configure in my pp-file to add my custom configuration in the main server config context? (I.e. outside of the virtual hosts)
The reference documentation for the module is here: https://github.com/puppetlabs/puppetlabs-apache/blob/main/REFERENCE.md, or you can access it via the Forge here: https://forge.puppet.com/modules/puppetlabs/apache/reference.
Those document the plethora of parameters of the apache class, which expose a wide variety of Apache's configuration properties. You can manage most of the most common (and many of the less common) Apache configuration details by setting appropriate values for these class parameters.
They also document a plethora of classes that you can declare to adjust which modules are enabled, plus a native resource type (a2mod) and a defined-type wrapper apache::mod that you can use to configure modules that do not have a pre-built class.
And they document several public defined types that you can use to customize your configuration (including, but not limited to, vhosts). Of these, apache::custom_config is the most general, as it allows you to manage drop-in files containing more-or-less arbitrary Apache configuration.
I am working on a product that runs Apache, and i'm trying to make the configuration more DRY — right now there are many different vhost configs that get loaded in different situations but are 90% identical, and this is very tedious to deal with when a change needs made. I don't think Apache is really designed with this kind of dynamic environment in mind, but w/e, here i am anyway.
So i've first turned to environment variables — i have a small boot-strap script that determines the necessary configuration and dumps variables into /etc/apache2/envvars (which is loaded by apache2ctl and similar on Ubuntu). This allows me to do things like this:
envvars:
export MYKEY='/path/to/mykey'
export MYCERT='/path/to/mycert'
export MYBUNDLE='/path/to/mybundle'
vhost config:
SSLCertificateKeyFile ${MYKEY}
SSLCertificateFile ${MYCERT}
SSLCACertificateFile ${MYBUNDLE}
This works fine, but only as long as MYKEY, &al., are non-empty variables referencing non-empty files. In some configurations, for example, no CA bundle is required, so i tried just pointing MYBUNDLE to /dev/null. Apache considers this a 'syntax error' because /dev/null is an empty file, and refuses to start.
My question: Is there any way i can dynamically disable/omit configuration directives in the Apache config (based on environment variables or a similar mechanism) without having to maintain separate files for each possible scenario?
Alternative question: Is there any way i can provide an empty value/certificate to this particular directive (SSLCACertificateFile) in a manner that Apache won't consider invalid?
Ubuntu 12.04.5
Apache 2.2.22
Looks like what you want is a management tool for your configuration.
Now I'm not sure how often you deploy but you probably could make a script that generates your templates for you?
If you have a greater need, maybe consider automation software and use some kind of template? I'm thinking something like chef (https://www.chef.io/) or puppet (http://puppetlabs.com/) or ... They all support template and you can provide value based on environment / server / moods for the different values.
I know that using apache directives, one can deny / allow access to certain files based on IP address:
Allow from address
However, in Magento, there's a particular module / route where I'd like only one IP to have access. Is there a way to specify this int he configuration / xml for that module?
Otherwise, can I use the .htaccess method in some way?
Lastly, I'm using Puphpet / Vagrant environment for this project. Is it possible to specify this in the Puphpet config?
I ended up solving this by using the available bash script hooks. I created a bash script that added this specific directive to the nginx.conf, and placed it in puphpet/files/startup-always. So every time vagrant up or vagrant provision is run, this bash script is executed.
I'm thinking of using Vagrant to develop Django applications, but I'm a little confused and I'm not sure if what I would like to do is even possible.
I installed the lucid32 box successfully and created a new "instance" of vagrant, with a Vagrantfile, some shared directories and forwarded ports.
The first issue is that this doesn't seem to me the best choice when working in a team. How can we (me and other 10 developers, for example) share the box so that every change to it is shared? For example, if in 6 months we need postgresql, I need to have it working without having to install postgresql 11 times.
Also, how can I make things (like: postgresql, django, this-service, etc.) to start when the box has started up? I don't think that I have to ssh it and manually start n times all the n things I need every time.
And finally: I don't understand well if things like puppet and chef are meant to completely substitute the manual installation (through pip or apt-get, for example). Is that so?
Thank you.
And I'm sorry for bad english. :-)
I would say that your choice of Vagrant already was a good start to what you are looking for, but now you need to dig a little deeper into either Chef or Puppet, to further automate your provisioning process.
I guess a good choice in your sceneraio would be to first put both, the Vagrantfile and the corresponding Puppet manifest under version control as part of your project. Additionally, all of the configurations concerning this machine should also be put into version control and/or be made available through some sort of artifact repository.
Second, establish the rule in the team that changes (at least these that should live on for longer) to the environment need to be checked in if they are considered ready for the other team members.
Concerning your second question and coming back to my opening: Puppet (which I like) or Chef are your tools of choice and can save you and your colleagues a lot of work in the future. I'll stick to Puppet here, as I don't know Chef too good.
With puppet, you can manage all of what you want, the installation of packages, changing configurations and ensuring that certain services are running, or in general that the system has the state you want it to be. Even better, if you or another team-member made some malicious chages to his/her box, you can just rollback the changes in your Vagrantfile/Puppet manifest, type in
vagrant destroy && vagrant up
and the box is easily taken back to the last versioned state.
For example, take the following manifest file:
package { "mysql-server-5.1":
ensure => present
}
file { "/etc/mysql/my.cnf":
owner => "root",
content => "http://myrepository.local/myProject/configurations/mysql/my.cnf",
require => Package["mysql-server-5.1"]
}
service { "mysql":
ensure => running,
subscribe => File["/etc/mysql/my.cnf"],
require => File["/etc/mysql/my.cnf"]
}
What this does is, it first of all checks the package mechanism of the OS in your box (the names in the example assume a recent Ubuntu) if the package "mysql-server-5.1" is installed, and if not it'll install it. Through the 'require' attribute, the second directive will be executed after the first (and only if it worked), changing the MySQL configuration to the one you have also checked in and/or published somewhere you can reach it (that could also be put into the same folder as the Vagrantfile, and will then be available in the box under /vagrant). The last step, which again only will be executed if the altering of the configuration worked, will ensure that the "mysql" service is up and running or is getting restarted if it already was running when the configuration was changed.
Now you can hook up this manifest in your Vagrantfile:
Vagrant::Config.run do |config|
config.vm.box = "lucid32"
config.vm.box_url = "http://files.vagrantup.com/lucid32.box"
config.vm.define "node1" do |cfg|
cfg.vm.network "10.23.5.11"
cfg.vm.provision :puppet do |puppet|
puppet.manifests_path = "manifests"
puppet.manifest_file = "node1.pp"
end
end
end
With all changes besides the 'trying-stuff-out' ones made to the environment like this, all team mebers are guaranted to have the same setup easily and reproducable just at their fingertips.
I personally like to try stuff out on the box by hand, and when I found the right setup and configuration, translate it into a Puppet manifest to have if ready for later use and sharing with team members.
As Puppet (and Chef also) can manage almost all you need (users, cron jobs, packages, services, files, ...) it is a good choice for exactly such problems, and you have the benefit to even be able to use the configurations to provision staging or testing environments later on if you choose to. Their are much more options with Puppet, and a read through the language guide should give you a good idea what more you can do with it.
Hope I could help :)
We're running a reseller web host, and aliasing a particular directory for ALL the sites within. This is all happening through WHM/Cpanel, which could possibly complicate my question.
We want all hosts to run their "/concrete" directory through a shared location on the server. This is working fine by adding "Alias /concrete/ "/usr/local/share/concrete5/concrete-latest/concrete/" to the apache include editor in WHM.
However, if a local concrete/ directory exists within the particular webroot of the virtual host, we'd rather use that than "/concrete" globally. It would also be nice if we could make this alias change in the context of the virtual host, within WHM (and I haven't found a great way to modify virtual host sections in WHM without hacking a file that I don't believe we're supposed to hack.)
Thoughts?
A primitive, although probably quite effective solution might be to forget about the Alias directive and to simply rely on a symlink. A little shell script that creates those symlinks for you will simply fail if there is already something present that is called 'concrete'.