How is my apache misconfigured exactly?

I got into the beta and tried to set up a certificate, my server is Ubuntu 12.04 and has a bunch of domains on it, including the one I want to enable for ssl, each one has a file in /etc/apache2/sites-available. I get a message that apache is misconfigured, but I have no clue in what way it is misconfigured (Apache runs and works), I am sure there is something wrong, but it gives me no clue what specific change I need to make to fix it. “Apache is unable to check whether or not the module is loaded because Apache is misconfigured.”

2015-10-27 15:47:46,375:DEBUG:letsencrypt.cli:Root logging level set at 30
2015-10-27 15:47:46,375:INFO:letsencrypt.cli:Saving debug log to /var/log/letsencrypt/letsencrypt.log
2015-10-27 15:47:46,375:DEBUG:letsencrypt.cli:letsencrypt version: 0.0.0.dev20151024
2015-10-27 15:47:46,375:DEBUG:letsencrypt.cli:Arguments: ['--agree-dev-preview', '--server', 'https://acme-v01.api.letsencrypt.org/directory']
2015-10-27 15:47:46,375:DEBUG:letsencrypt.cli:Discovered plugins: PluginsRegistry(PluginEntryPoint#apache,PluginEntryPoint#webroot,PluginEntryPoint#null,PluginEntryPoint#manual,PluginEntryPoint#standalone)
2015-10-27 15:47:46,384:DEBUG:letsencrypt.cli:Requested authenticator None and installer None
2015-10-27 15:47:46,842:WARNING:letsencrypt_apache.parser:Error in checking parameter list: (98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

2015-10-27 15:47:46,849:DEBUG:letsencrypt.plugins.disco:Misconfigured PluginEntryPoint#apache: Apache is unable to check whether or not the module is loaded because Apache is misconfigured.
Traceback (most recent call last):
  File "/home/alanbell/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt/plugins/disco.py", line 103, in prepare
    self._initialized.prepare()
  File "/home/alanbell/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/configurator.py", line 151, in prepare
    self.aug, self.conf("server-root"), self.conf("ctl"))
  File "/home/alanbell/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/parser.py", line 39, in __init__
    self.update_runtime_variables(ctl)
  File "/home/alanbell/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/parser.py", line 97, in update_runtime_variables
    stdout = self._get_runtime_cfg(ctl)
  File "/home/alanbell/.local/share/letsencrypt/local/lib/python2.7/site-packages/letsencrypt_apache/parser.py", line 139, in _get_runtime_cfg
    "Apache is unable to check whether or not the module is "
MisconfigurationError: Apache is unable to check whether or not the module is loaded because Apache is misconfigured.
2015-10-27 15:47:46,850:DEBUG:letsencrypt.display.ops:Single candidate plugin: * apache
Description: Apache Web Server - Alpha
Interfaces: IAuthenticator, IInstaller, IPlugin
Entry point: apache = letsencrypt_apache.configurator:ApacheConfigurator
Initialized: <letsencrypt_apache.configurator.ApacheConfigurator object at 0x264fa90>
Prep: Apache is unable to check whether or not the module is loaded because Apache is misconfigured.
2015-10-27 15:47:46,850:DEBUG:letsencrypt.cli:Selected authenticator None and installer None
Address already in use: make_sock: could not bind to address 0.0.0.0:80

Thanks for testing out the beta :wink: Maybe restart the apache server and see what pops ?

I have the same issue with the same error message. Restarting Apache has not changed anything.

Is the client expecting some configuration which I don’t provide? This is a Debian Wheezy system with pretty standard Apache 2.2 configuration.

Is there anything I can do for troubleshooting?

@alanbell, I’m sorry you’ve been having trouble. Based on the log you included, I can tell you more about what’s going on. The Apache plugin uses the apache2ctl binary to get information about the Apache configuration. The name of this binary can be controlled with the --apache-ctl option on the command line. If you’d like more info on that, run letsencrypt-auto --help apache.

Based on the traceback you provided, what the code is doing at this point is running apache2ctl -D DUMP_RUN_CFG which returns the parsed configuration used by Apache. When it does this, apache2ctl is writing the following to STDERR and returning a non-zero return value:

(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs

This suggests to me that your Apache configuration tells Apache to bind to port 80, but it is unable to do so. If you can fix the problem with apache2ctl -D DUMP_RUN_CFG, it will fix this problem with the client. Unfortunately, I’m unable to tell you exactly what needs to be done as that depends heavily on your Apache config. Hopefully the information I’ve provided here helps.

@jftr, if you’re having the exact same issue, everything I just wrote applies to you as well. If your error/traceback is different, please include some logging output so I can better diagnose the problem.

Thanks for your help, @bmw .

Yes, the exact same situation applies to my configuration.

# apache2ctl -D DUMP_RUN_CFG
(98)Address already in use: make_sock: could not bind to address [::]:80
(98)Address already in use: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
Unable to open logs
Action '-D DUMP_RUN_CFG' failed.
The Apache error log may have more information.

Apache works just fine though. It serves several virtual hosts at port 80 just fine. Do you have any idea what could be wrong? I’ll also investigate myself, but maybe you know what could be the cause already.

1 Like

excellent, that gives me more to go on, and I can trace it as an Apache problem now rather than a letsencrypt problem.

Is it possible that for version 2.2 apache2ctl needs -t as an argument?

For me it seems as if apache2ctl -D DUMP_RUN_CFG does nothing but try to start Apache. However the server is running already and thus the error is thrown.

If I look at the help page of apache2ctl, I find no mention of DUMP_RUN_CFG but I find two similar options:

  -t -D DUMP_VHOSTS  : show parsed settings (currently only vhost settings)
  -S                 : a synonym for -t -D DUMP_VHOSTS
  -t -D DUMP_MODULES : show all loaded modules 
  -M                 : a synonym for -t -D DUMP_MODULES

Additionally, -D is also mentioned:

  -D name            : define a name for use in <IfDefine name> directives

That suggests that just calling apache2ctl -D DUMP_RUN_CFG does not what letsencrypt exects it to do. However if I add the -t flag, apache2ctl runs successfully (without any useful output though. I guess this means there are no directives defined in my configuration):

# apache2ctl -t -D DUMP_RUN_CFG
Syntax OK

Please let me know if I’m misunderstanding something. In case I am wrong: What does letsencrypt expect as output?

2 Likes

It does appear that Apache 2.2 interprets the command differently.

Thanks to @jftr and neffs on GitHub for submitting a patch which has been merged. Let us know if this didn’t solve your problems.

Thanks for reporting @svennd!

Is this patch already in master? If not, what branch do I need to pull? I will try asap.

@jftr, yes the patch is already in master. Note: letsencrypt-auto pulls from PyPI not master, but we’re planning on doing another PyPI release very soon.

The new version seems to have changed quite a bit. Without any installer options, it stops immediately with the following error message:

No installers seem to be present and working on your system; fix that or try running letsencrypt with the "certonly" command

If I run it with --apache, it does not stop – as previously – when it tries to run apache2ctl. However this does not solve the problem because not it complains about unparsable output of apache2ctl:

The apache plugin is not working; there may be problems with your existing configuration.
The error was: PluginError('Unable to parse runtime variables',)

The -t flag seems to be only a part of the solution.

Edit: I continue this discussion in a GitHub issue which seems to be the more appropriate place.

Looks like it is working now https://www.libertus.co.uk/ turns out I didn’t have mod_ssl enabled (which would have been a good thing for it to tell me about) and I had to edit my default-ssl configuration file myself, but it gave me the certificates which is awesome. I am sure it would work more smoothly on single-website computers.