Page 1 of 2

Waiting for configuration verification...... forever!

Posted: Thu Oct 06, 2016 4:12 am
by srhart
Hi

I'm trying to add some services to a servicegroup in CCM on Nagios XI V5.3.0, once I do and I click 'apply configuration', I get the "Waiting for configuration verification......" screen and that just goes on forever.

Any thoughts?

Thanks

Re: Waiting for configuration verification...... forever!

Posted: Thu Oct 06, 2016 10:22 am
by jomann
You may want to tail -f the cmdsubsys.log file (located in /usr/local/nagiosxi/var/) while you run the apply configuration to see it in action, or alternatively you can run it manually by doing:

Code: Select all

cd /usr/local/nagiosxi/scripts
./reconfigure_nagios.sh
Copy the output here on the forum (redact anything you don't want to show)

Re: Waiting for configuration verification...... forever!

Posted: Tue Oct 11, 2016 8:41 am
by srhart
Sorry for the delay:
CMDLINE
/usr/bin/wget --save-cookies nagiosql.cookies --keep-session-cookies http://localhost/nagiosxi/includes/components/ccm/ --no-check-certificate --post-data 'submit=Login&hidelog=true&loginSubmitted=true&username=nagiosxi&password=n@gweb' -O nagiosql.login--2016-10-11 14:39:53-- http://localhost/nagiosxi/includes/components/ccm/
Resolving localhost (localhost)... ::1, 127.0.0.1
Connecting to localhost (localhost)|::1|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://localhost/nagiosxi/includes/components/ccm/ [following]
--2016-10-11 14:39:53-- https://localhost/nagiosxi/includes/components/ccm/
Connecting to localhost (localhost)|::1|:443... connected.
WARNING: cannot verify localhost's certificate, issued by '/C=UK/ST=XXX/L=XXX/O=XXX/OU=Support/CN=XXX/emailAddress=XXX':
Self-signed certificate encountered.
WARNING: certificate common name 'XXX' doesn't match requested host name 'localhost'.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'nagiosql.login'

[ <=> ] 18,511 --.-K/s in 0.009s

2016-10-11 14:39:53 (1.96 MB/s) - 'nagiosql.login' saved [18511]

NAGIOSQL LOGIN FAILED!

Re: Waiting for configuration verification...... forever!

Posted: Tue Oct 11, 2016 10:56 am
by rkennedy
Could you post a screenshot of your Admin -> System Settings page, and also all of the files in your /etc/httpd/conf.d/ directory? This should be a start to see what's going on.

Re: Waiting for configuration verification...... forever!

Posted: Wed Oct 12, 2016 4:12 am
by srhart
Here you go:

Code: Select all

-rw-r--r-- 1 root   root     366 Nov 19  2015 README
-rw-r--r-- 1 root   root    2926 Nov 19  2015 autoindex.conf
-rw-r--r-- 1 root   root    1054 Feb 15  2016 nagios.conf
-rw-r--r-- 1 root   root     484 Mar 18  2016 nagioslogserver.conf
-rwxrwxrwx 1 root   root     623 Feb 15  2016 nagiosmobile.conf
-rw-r--r-- 1 root   root     427 Oct  6 10:01 nagiosql.conf
-rw-r--r-- 1 root   root     699 May 16 10:46 nagiosxi.conf
-rw-r--r-- 1 apache apache  2148 Feb 15  2016 nagvis.conf
-rw-r--r-- 1 root   root     367 Feb 15  2016 nrdp.conf
-rw-r--r-- 1 root   root     691 Aug 11 22:27 php.conf
-rw-r--r-- 1 root   root   10020 Feb 15  2016 ssl.conf
-rw-r--r-- 1 root   root    9438 Feb 15  2016 ssl.conf.nagiosxibackup
-rw-r--r-- 1 root   root    1252 Nov 19  2015 userdir.conf
-rw-r--r-- 1 root   root     824 Nov 19  2015 welcome.conf

Re: Waiting for configuration verification...... forever!

Posted: Wed Oct 12, 2016 11:32 am
by tgriep
Can you post your /etc/hosts file so we can view it?
It looks like the localhost settings may be incorrect in that file which could be a cause of the error.
Also, does the server use a proxy server to connect to the internet?

Re: Waiting for configuration verification...... forever!

Posted: Mon Oct 24, 2016 10:22 am
by srhart
Sorry for the delay - have since upgraded to 5.3.0 - still have the "waiting forever problem"

Host file is (details redacted to protect the innocent):

Code: Select all

127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4  xxxxx   xxxxx.xxx-nms.co.uk
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6  xxxxx   xxxxx.xxx-nms.co.uk
1.1.1.1    xxxxx.xxx-nms.co.uk     xxxxx
No the server does not use a proxy.

Just today I need to add a host to the system - no luck, I click 'Apply Config' and I just get the dreaded "Waiting for configuration verification............" forever. It would be better if there was a timeout on this that came back with an error rather than just going on and on...

Re: Waiting for configuration verification...... forever!

Posted: Mon Oct 24, 2016 11:51 am
by rkennedy
Is 1.1.1.1 xxxxx.xxx-nms.co.uk xxxxx a duplicate of the record above pointing to 127.0.0.1? If so, I would remove it.

Can you also post your /etc/httpd/conf.d/ssl.conf for us to look at? I'd like to see how the redirection is being handled.

Re: Waiting for configuration verification...... forever!

Posted: Tue Oct 25, 2016 7:20 am
by srhart
Here you go:

Code: Select all

#
# When we also provide SSL we have to listen to the
# the HTTPS port in addition.
#
Listen 443 https

##
##  SSL Global Context
##
##  All SSL configuration in this context applies both to
##  the main server and all SSL-enabled virtual hosts.
##

#   Pass Phrase Dialog:
#   Configure the pass phrase gathering process.
#   The filtering dialog program (`builtin' is a internal
#   terminal dialog) has to provide the pass phrase on stdout.
SSLPassPhraseDialog exec:/usr/libexec/httpd-ssl-pass-dialog

#   Inter-Process Session Cache:
#   Configure the SSL Session Cache: First the mechanism
#   to use and second the expiring timeout (in seconds).
SSLSessionCache         shmcb:/run/httpd/sslcache(512000)
SSLSessionCacheTimeout  300

#   Pseudo Random Number Generator (PRNG):
#   Configure one or more sources to seed the PRNG of the
#   SSL library. The seed data should be of good random quality.
#   WARNING! On some platforms /dev/random blocks if not enough entropy
#   is available. This means you then cannot use the /dev/random device
#   because it would lead to very long connection times (as long as
#   it requires to make more entropy available). But usually those
#   platforms additionally provide a /dev/urandom device which doesn't
#   block. So, if available, use this one instead. Read the mod_ssl User
#   Manual for more details.
SSLRandomSeed startup file:/dev/urandom  256
SSLRandomSeed connect builtin
#SSLRandomSeed startup file:/dev/random  512
#SSLRandomSeed connect file:/dev/random  512
#SSLRandomSeed connect file:/dev/urandom 512

#
# Use "SSLCryptoDevice" to enable any supported hardware
# accelerators. Use "openssl engine -v" to list supported
# engine names.  NOTE: If you enable an accelerator and the
# server does not start, consult the error logs and ensure
# your accelerator is functioning properly.
#
SSLCryptoDevice builtin
#SSLCryptoDevice ubsec

##
## SSL Virtual Host Context
##

<VirtualHost _default_:443>

# General setup for the virtual host, inherited from global configuration
#DocumentRoot "/var/www/html"
#ServerName www.example.com:443

# Use separate log files for the SSL virtual host; note that LogLevel
# is not inherited from httpd.conf.
ErrorLog logs/ssl_error_log
TransferLog logs/ssl_access_log
LogLevel warn

#   SSL Engine Switch:
#   Enable/Disable SSL for this virtual host.
SSLEngine on

#   SSL Protocol support:
# List the enable protocol levels with which clients will be able to
# connect.  Disable SSLv2 access by default:
SSLProtocol all -SSLv2

#   SSL Cipher Suite:
#   List the ciphers that the client is permitted to negotiate.
#   See the mod_ssl documentation for a complete list.
SSLCipherSuite HIGH:MEDIUM:!aNULL:!MD5:!SEED:!IDEA

#   Speed-optimized SSL Cipher configuration:
#   If speed is your main concern (on busy HTTPS servers e.g.),
#   you might want to force clients to specific, performance
#   optimized ciphers. In this case, prepend those ciphers
#   to the SSLCipherSuite list, and enable SSLHonorCipherOrder.
#   Caveat: by giving precedence to RC4-SHA and AES128-SHA
#   (as in the example below), most connections will no longer
#   have perfect forward secrecy - if the server's key is
#   compromised, captures of past or future traffic must be
#   considered compromised, too.
#SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:MEDIUM:!aNULL:!MD5
#SSLHonorCipherOrder on

#   Server Certificate:
# Point SSLCertificateFile at a PEM encoded certificate.  If
# the certificate is encrypted, then you will be prompted for a
# pass phrase.  Note that a kill -HUP will prompt again.  A new
# certificate can be generated using the genkey(1) command.
SSLCertificateFile /etc/pki/tls/certs/ca.crt

#   Server Private Key:
#   If the key is not combined with the certificate, use this
#   directive to point at the key file.  Keep in mind that if
#   you've both a RSA and a DSA private key you can configure
#   both in parallel (to also allow the use of DSA ciphers, etc.)
SSLCertificateKeyFile /etc/pki/tls/private/ca.key

#   Server Certificate Chain:
#   Point SSLCertificateChainFile at a file containing the
#   concatenation of PEM encoded CA certificates which form the
#   certificate chain for the server certificate. Alternatively
#   the referenced file can be the same as SSLCertificateFile
#   when the CA certificates are directly appended to the server
#   certificate for convinience.
#SSLCertificateChainFile /etc/pki/tls/certs/server-chain.crt

#   Certificate Authority (CA):
#   Set the CA certificate verification path where to find CA
#   certificates for client authentication or alternatively one
#   huge file containing all of them (file must be PEM encoded)
#SSLCACertificateFile /etc/pki/tls/certs/ca-bundle.crt

#   Client Authentication (Type):
#   Client certificate verification type and depth.  Types are
#   none, optional, require and optional_no_ca.  Depth is a
#   number which specifies how deeply to verify the certificate
#   issuer chain before deciding the certificate is not valid.
#SSLVerifyClient require
#SSLVerifyDepth  10

#   Access Control:
#   With SSLRequire you can do per-directory access control based
#   on arbitrary complex boolean expressions containing server
#   variable checks and other lookup directives.  The syntax is a
#   mixture between C and Perl.  See the mod_ssl documentation
#   for more details.
#<Location />
#SSLRequire (    %{SSL_CIPHER} !~ m/^(EXP|NULL)/ \
#            and %{SSL_CLIENT_S_DN_O} eq "Snake Oil, Ltd." \
#            and %{SSL_CLIENT_S_DN_OU} in {"Staff", "CA", "Dev"} \
#            and %{TIME_WDAY} >= 1 and %{TIME_WDAY} <= 5 \
#            and %{TIME_HOUR} >= 8 and %{TIME_HOUR} <= 20       ) \
#           or %{REMOTE_ADDR} =~ m/^192\.76\.162\.[0-9]+$/
#</Location>

#   SSL Engine Options:
#   Set various options for the SSL engine.
#   o FakeBasicAuth:
#     Translate the client X.509 into a Basic Authorisation.  This means that
#     the standard Auth/DBMAuth methods can be used for access control.  The
#     user name is the `one line' version of the client's X.509 certificate.
#     Note that no password is obtained from the user. Every entry in the user
#     file needs this password: `xxj31ZMTZzkVA'.
#   o ExportCertData:
#     This exports two additional environment variables: SSL_CLIENT_CERT and
#     SSL_SERVER_CERT. These contain the PEM-encoded certificates of the
#     server (always existing) and the client (only existing when client
#     authentication is used). This can be used to import the certificates
#     into CGI scripts.
#   o StdEnvVars:
#     This exports the standard SSL/TLS related `SSL_*' environment variables.
#     Per default this exportation is switched off for performance reasons,
#     because the extraction step is an expensive operation and is usually
#     useless for serving static content. So one usually enables the
#     exportation for CGI and SSI requests only.
#   o StrictRequire:
#     This denies access when "SSLRequireSSL" or "SSLRequire" applied even
#     under a "Satisfy any" situation, i.e. when it applies access is denied
#     and no other module can change it.
#   o OptRenegotiate:
#     This enables optimized SSL connection renegotiation handling when SSL
#     directives are used in per-directory context.
#SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire
<Files ~ "\.(cgi|shtml|phtml|php3?)$">
    SSLOptions +StdEnvVars
</Files>
<Directory "/var/www/cgi-bin">
    SSLOptions +StdEnvVars
</Directory>

#   SSL Protocol Adjustments:
#   The safe and default but still SSL/TLS standard compliant shutdown
#   approach is that mod_ssl sends the close notify alert but doesn't wait for
#   the close notify alert from client. When you need a different shutdown
#   approach you can use one of the following variables:
#   o ssl-unclean-shutdown:
#     This forces an unclean shutdown when the connection is closed, i.e. no
#     SSL close notify alert is send or allowed to received.  This violates
#     the SSL/TLS standard but is needed for some brain-dead browsers. Use
#     this when you receive I/O errors because of the standard approach where
#     mod_ssl sends the close notify alert.
#   o ssl-accurate-shutdown:
#     This forces an accurate shutdown when the connection is closed, i.e. a
#     SSL close notify alert is send and mod_ssl waits for the close notify
#     alert of the client. This is 100% SSL/TLS standard compliant, but in
#     practice often causes hanging connections with brain-dead browsers. Use
#     this only for browsers where you know that their SSL implementation
#     works correctly.
#   Notice: Most problems of broken clients are also related to the HTTP
#   keep-alive facility, so you usually additionally want to disable
#   keep-alive for those clients, too. Use variable "nokeepalive" for this.
#   Similarly, one has to force some clients to use HTTP/1.0 to workaround
#   their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and
#   "force-response-1.0" for this.
BrowserMatch "MSIE [2-5]" \
         nokeepalive ssl-unclean-shutdown \
         downgrade-1.0 force-response-1.0

#   Per-Server Logging:
#   The home of a custom SSL log file. Use this when you want a
#   compact non-error SSL logfile on a virtual host basis.
CustomLog logs/ssl_request_log \
          "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"



## AJAXTERM #####################
ProxyRequests Off
<Proxy *>
        AuthUserFile /usr/local/nagiosxi/etc/htpasswd.users
        AuthName "Nagios Core"
        AuthType Basic
        require valid-user
        Order Deny,allow
        Allow from all
</Proxy>
ProxyPass /nagios/ajaxterm/ http://localhost:8022/
ProxyPassReverse /nagios/ajaxterm/ http://localhost:8022/
## AJAXTERM #####################


<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule nagiosxi/api/v1/(.*)$ /usr/local/nagiosxi/html/api/v1/index.php?request=$1 [QSA,NC,L]
</IfModule>
</VirtualHost>

Re: Waiting for configuration verification...... forever!

Posted: Tue Oct 25, 2016 9:31 am
by srhart
Just a note, I did try commenting that last line out and reloading the server - luckily I had backed it up before hand as the server went away and never came back - it's hosted by the way - had to restore the disk from the dashboard to get it back