apache conf.d directory deleted by recipe

[vkhatri]

hello!

is it intended to delete conf.d directory in apache2::default? any explanation is much appreciated.

directory "#{node['apache']['dir']}/conf.d" do
  action :delete
  recursive true
end

[svanzoest]

Yes since version 2.0.0 it is replaced by conf-available and conf-enabled.

[vkhatri]

@svanzoest thanks for prompt response!

it breaks apache setup for packages like icinga which creates .conf files under conf.d directory. I had to work around to get the conf file content and put it under sites-available as conf.d directory did not exists and the .conf file never existed.

may be there is a better way to work with packages which still creates .conf file under conf.d directory.

[svanzoest]

What platform and apache version are you seeing this on? You can use the definitions to drop the file in conf-available and enable it.

[vkhatri]

@svanzoest

Platform: Amazon AMI 2014-09
Apache version - httpd-2.2.29-1.4.amzn1.x86_64

To get the definitions i had to stop chef client, uninstall icinga2 packages, reinstall icinga2 packages, copy icinga2 apache .conf files to conf-available.

[svanzoest]

The cookbook does things the apache 2.4 way and switched to using the a2enconf scripts similar to the Debian packages. You could add your own directive in conf-enabled to Include conf.d/*.conf until you are ready to move over to apache 2.4

[vkhatri]

@svanzoest Indeed i am using a2enconf to manage conf, sites etc. I am not using conf.d at all for any purpose.

Issue is that apache2::default recipe deletes conf.d directory which is used by other packages to create default apache conf. As conf.d directory does not exists it does not create any .conf at all.

Issue is not about managing the conf's, its regarding missing conf.d directory, which is still default location for other packages and also created by apache package.

Though having conf.d directory could create an issue while setting up conf's under conf-enabled, as conf.d is default location for most of the packages to create conf files.

But, getting the conf file definitions for a package (e.g. icinga) is still a problem as package will never create any conf file due to missing conf.d directory.

[svanzoest]

I am okay with adding a backwards compatibility flag for conf.d that symlinks it to conf-available for apache 2.2 systems if that eases the transition. This could also be addressed in the icinga cookbook.

[drpebcak]

I think the icinga cookbook should address this - they might want to add constraints to what versions of the apache2 cookbook are supported.

But, there is already the ability to place .conf files anywhere you want in our definitions. The problem you might run into is managing when things are in conf-* or in conf.d - it could get complicated having both. Adding a flag to not delete conf.d would be fairly trivial.

[svanzoest]

Worth noting #250 for the record, as in that case, it was unclear how to migrate forward.

[hrak]

This issue is still holding us back from rolling out this cookbook in production, as reported by me in #250. In a mixed Ubuntu 12.04 / 14.04 (Apache 2.2/Apache 2.4) environment, rolling out this cookbook will break 12.04 based Apache boxes with config files in conf.d (as is usually the case).

A flag, or as i suggested, a "if node['apache']['version'] == '2.4'" check around the deletion of /etc/apache2/conf.d would be very welcome!

[svanzoest]

@hrak are your conf.d files not managed by chef? Can you provide the scenario where this is not working for you? How can we migrate the config file creation from conf.d to conf-available?

The older packages writing configs to conf.d is one such scenario any others?

[hrak]

@svanzoest Its mostly that scenario indeed (packages on Ubuntu 12.04 and possibly other distros that drop off config bits in conf.d/, f.e. phpmyadmin).

Some of our own cookbooks drop small config changes in there as well, but we could simply fix that in our wrapper/app cookbooks by using apache_config.

Migrating from conf.d to conf-available could also be a nice thing to implement. Let the cookbook check for existance of conf.d, if it is there and there are files in there, move them to conf-available and link them in conf-enabled, and then remove the conf.d dir. It would be a nice idempotent solution that does not result in data/config loss.

[svanzoest]

@hrak I agree with your comments. My additional concern is that between apache 2.2 and apache 2.4 you can not just copy over the conf.d files and enable them as they may not be compatible with apache 2.4 and therefore break a running service in production. It seems tricky to do this on such an upgrade between 2.2 and 2.4.

Of course if we are talking a cookbook only update then it would be a lot easier as it is more likely that the configuration files should continue to work. It seems like the configuration files should be managed by chef though and therefore there would be no config loss at all. The exceptions would be a default configuration dropped by a package that chef is not aware of. Maybe the best way forward to ensure we keep a history of what the configuration files are, is copy them over, but not enable them.

A somewhat related issue is #279 where packages drop in configuration files that are not known by the cookbook, or the cookbook expected those to be deleted, but they would be added again when the new yum package gets installed before the next chef run that can delete them again. I am starting to lean more towards rewriting the config empty, as ugly as that is, to avoid for them to be written again.

[hrak]

The cookbook upgrade scenario is the most likely to happen, and the only one I'm worried about atm. I don't think people in for example a mixed Ubuntu 12.04/14.04 environment are crazy enough to combine a major cookbook version bump with a distro upgrade :) (or upgrade a working Apache 2.2 setup to 2.4 and expect things to work flawlessly)

Yum rewriting config files and resetting permissions has bitten me quite some time as well, and i never really found a good way of preventing/fixing it. I guess RPM users just have to trigger a Chef run after running updates ;)

[dgm]

As we are only beginning to utilize chef, we have some conf files in conf.d that are not under chef control... and it's a bit of a pain to upgrade servers to this cookbook when I have to first backup the conf.d files, run chef-client, and then restore any missing configs.

[svanzoest]

@dgm my suggestion to you is to not do that. Determine what files are in conf.d and add them to your chef wrapper cookbook and test them. Once you do that you can just run chef-client and not even worry about it. The configs will be available in conf-enabled without a hitch and you now also have documented exactly what is required to configure the web server.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.