My introduction to Puppet and Foreman has been very painful, but I know there's a big community around it, so I'm hoping that someone can set me straight here.
I set up Foreman and Puppet using the Foreman-Installer and it went great. I had Foreman up and running and it worked great! However, I added the OpenStack controller role to the machine, it wiped out the Apache vhosts for Foreman. I've scoured Google and Github for copies of the vhost files, but with no luck.
So the main questions here:
1) How do I locate/generate the Foreman vhosts for Apache?
2) How do I prevent Puppet from removing them again?
Thanks in advance all you Puppet Masters!
To prevent Puppet from blasting your Apache config, start managing that config through Puppet.
I'm not sure how your OpenStack controller role works, but it likely employs the puppetlabs-apache module, which will purge unmanaged configuration. You should use this module to configure the Foreman vhost on the machine.
As for getting it back - Puppet should have stored the contents of deleted files in the clientbucket. Check the logs on that machine. There should be md5 sums for all removed files. Use those to retrieve the contents, either through the filebucket tool, or by manually trudging /var/lib/puppet/clientbucket (or whatever puppet agent --configprint clientbucketdir yields).
Related
I'm having problems deploying in Elastic Beanstalk (Tomcat).
When I deploy my WAR, an Apache config syntax check is done:
/usr/sbin/apachectl -t -f /var/elasticbeanstalk/staging/httpd/conf/httpd.conf
But it fails because that httpd.conf doesn't define modules needed:
Syntax error on line 214 of /etc/httpd/conf.d/ssl.conf
Invalid command 'SetEnvIf', perhaps misspelled or defined...
That modules, in this case, setenvif_moduleis defined in /etc/httpd/conf/httpd.confthat is my httpd config file.
I don't know where /var/elasticbeanstalk/staging/httpd/conf/httpd.confcomes from.
Any idea of how to solve this?
From my investigation, this seems only related to an initial instance install/build using Elastic Beanstalk. The ssl.conf file in question actually comes from the initial Apache install and is not part of the Elastic Beanstalk configuration.
The issue is happening because AWS no longer installs mod_setenvif.so as a module in httpd.conf and therefore this error is being thrown.
In order to remove this ongoing issue from my builds and due to the fact that I already customize my Apache configuration, I copied a working AWS httpd.conf file from another instance and added the mod_setenvif.so module to it. Using the directions at http://docs.aws.amazon.com/elasticbeanstalk/latest/dg/java-tomcat-platform.html#java-tomcat-proxy-apache, Elastic Beanstalk configuration scripts use the new httpd.conf file and the error is no longer thrown.
I consider this a workaround answer since the main scripts is controlled by AWS. It my be a defect in the script or it may not. Regardless, I just wanted to find a solution quickly.
I'm using a plain apache server as a front-end and a mod-perl enabled apache server as a backend with mod_proxy.
I'm in the process of moving to a new hosting company so I'm installing software. In the past I've built both of these from source but it would be easier to use yum to install so that they are easily updated. Is it possible to install 2 separate httpd servers with yum? And if so how?
I'm thinking that the solution might be to move the front-end to lighttpd or similar but I'd still like to know whether it is possible.
I'm using Centos 7.
Seem to have it working now. Hope this might help someone else.
I now have one httpd with two different configuration files in /etc/httpd/conf/: httpd_docs.conf and httpd_perl.conf
Set the PidFile to two different files at the top of the config files.
Copied the /etc/httpd/conf.modules.d to /etc/httpd/conf.modules.perl and updated the 'Include' in the two config files to point to the different directories and then deleted unnecessary files in each directory so that the httpd_docs instance does not use mod_perl and the httpd_perl instance does.
Copied /etc/sysconfig/httpd to /etc/sysconfig/httpd_perl and edited each one to include an OPTIONS line
OPTIONS="-d /etc/httpd -f conf/httpd_docs.conf"
and
OPTIONS="-d /etc/httpd -f conf/httpd_perl.conf"
Copied /usr/lib/systemd/system/httpd.service to /usr/lib/systemd/system/httpd_perl.service and edited to point to correct EnvironmentFile.
Used this question to help answer my own question
https://serverfault.com/questions/31838/can-rhel-4-have-two-instances-of-apache-httpd-running-using-two-different-config
I am fairly new with puppet but not new to the server administration world.
I've managed to get a puppet master up and running as well as a puppet node on a different machine. I've been working on configuring the node as a web server. I've configured my first non SSL vhost and all seems well.
I've went to setup a SSL Vhost but this is where I am running in to what I suspect is a trivial problem. I have the SSL Key/Cert/CSR/Intermediate Chain file. However, after googling I cannot seem to be able to get these files copied over to the node, automatically, through puppet.
Any help would be welcomed!
You want to organize your site manifest into modules. These allow you to store files in canonical locations so that you can deploy them to agents using the file type, e.g.
file { "/etc/apache2/ssl/chain-and-key.pem":
ensure => file,
source => "puppet:///mymodule/etc/apache2/ssl/chain-and-key.pem";
}
I have apache pointing to a symbolic link for a website. I'm using capistrano to deploy the code so it updates the symbolic link to point to the new release
After capistrano updates the symbolic link to the new release directory apache uses the previous release directory.
The weird thing is it doesn't happen all the time. After a deploy everything either works fine or apache follows the previous link until i restart or reload apache.
any ideas?
This may depend on Apache httpd holding a handle on the old symlink. As long as that is the case the old data (symlink) is not thrown away in Unix based filesystems.
It seems you are unable to predict whether this is the case. Maybe use of lsof can help. What could also help is to trigger a graceful restart of httpd.
I have an application with some cacheing backend and I want to clear the cacheing whenever the webserver is been restarted.
Is there a apache configuration directive or any other way to execute a shell script upon webserver (re)start?
Thanks,
Phil
Adding some more information, as asked by some answers already:
Base system is ofc linux based, in this exact situation: CentOs
Modifying the startup script is unfortunately no option as pointed out by one of the comments already, due to it beeing not configuration file within the respective RPM packages and therefor beeing replaced by updates. Also I think modifying the startup script would be a bad thing in general
I see, that actually linking both "restarting the webserver" and "clearing my app cache" is not exactly what should be tied together. I will consider other alternatives
My situation is as follows: I can define how the virtual host config looks like, but I can not define how the rest of the servers configuration looks like.
The application is actually PHP based (and runs on the symfony framework). Symfony pre-compiles alot of stuff into dynamic php files from what it finds in the static configuration files. We deploy our apps via RPM and after deployment, an webserver restart is actually initiated already, so I thought it might make sense to tie the cache-cleanup to it. But I think after getting all your feedback, it looks like it is better to put the cache cleanup process into the installation process itself.
You haven't provided a lot of detail here, so it's hard to give a concrete answer, but I would suggest that your best option is to write a script which handles restarting apache, and clearing your cache. It would look something like this:
#!/bin/sh
# restart apache
/etc/init.d/httpd graceful
# whatever needs to be done to clear cache
rm -rf /my/cache/dir
Ramy suggests modifying the system startup script for Apache -- this is a bad idea! If and when you update Apache on your server, there is a good chance that your change will be lost.
Dirk suggests that what you are trying to do is probably misguided, and I think he's right. You haven't told us what platform you are running, but I can think of few situations where restarting your webserver and clearing a cache actually need to happen together.
You can modify Startup script for the Apache Web Server in /etc/init.d/httpd and write your own syntax inside it.
chattr +i /etc/init.d/httpd
If you have (root) access to the server you could do this by shell scripts but I would consider if it is the best way of cache management to rely on apache restarts.