[Bug 988421] [NEW] nagios3 check_load produces no output
Public bug reported: I am running a nagios3 server on ubuntu 10.04 server (nagios3 3.2.0-4ubuntu2.2) and a nrpe server on ubuntu 10.10 (nagios-nrpe-server 2.12-4ubuntu1.10.10.1, nagios-plugins 1.4.14-5ubuntu3) Have these both basically up and running, and the server is able to run a check_disk command on the npre server and receives results. For a check_load command, however, the status information is '(No output returned from plugin)'. I have looked extensively on the web for this, and it appears there are a number of reasons this may happen. On the server, if I run sudo su - nagios -c /usr/lib/nagios/plugins/check_nrpe -H 10.41.129.36 -c check_load there is nothing returned. If I change the user from nagios to peter, then I get the expected response. On the nrpe server, the same thing is happening. If I run sudo su - nagios -c /usr/lib/nagios/plugins/check_load -w 15,10,5 -c 30,25,20 there is nothing returned. If I change the user to peter it returns the expected output. I've tried making the plugins all owned by nagios:nagios, that doesn't help. I've tried adding a line for nagios to sudoers file and then adding the sudo command prefix, that doesn't fix it when invoking the command on the nagios server. I've also tried adding the nagios user to the admin group and that doesn't help. I've enabled the debugging on the nrpe server, and for the command from the nagios server, I see the connection and request in syslog when the user is peter, but no such request when the user is nagios. Neither of the local commands generate any syslog output. It is difficult to understand why this command, check_load, on the nrpe server is returning output for users 'peter' and 'root' but not for user 'nagios' when 'nagios' owns the executable. When I check executing the check_disk command locally on the nrpe server with sudo su - nagios -c /usr/lib/nagios/plugins/check_disk -w 20% -c 10% -p /dev/sda1 it works and returns a report. Curiously, if I change the nagios user to have a login shell, such as /bin/bash, on the nrpe server, then the check_load command is returning output, though still doesn't work from the nagios server. In neither case, however, does the nagios user have a password. Both the check_load and check_disk plugins are owned by nagios:nagios and have -rwxr-xr-x permissions, so what is the difference? /proc/loadavg is owned by root:root and has rw-r--r-- permissions, so should be readable. It appears this is a problem with the nagios user setup in the ubuntu packaging. I have checked the upstream bug fixes to current and there is nothing in nagios-plugin which would appear to address this issue. ** Affects: nagios-plugins (Ubuntu) Importance: Undecided Status: New ** Tags: nagios3 ** Tags added: nagios3 -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to nagios-plugins in Ubuntu. https://bugs.launchpad.net/bugs/988421 Title: nagios3 check_load produces no output To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nagios-plugins/+bug/988421/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 986649] [NEW] puppet agent can't obtain catalogs
Public bug reported: For puppet 2.7.1-1ubuntu3.5~maverick1 running on maverick server, the agent fails to be able to obtain catalogs from the puppetmaster, due to a failure to validate the ca certificate. This is a dangerous bug as it appears when following the instructions in the server guide for installing puppet and is just silent, in the sense that there is nothing normally in the logs. It only appear if one checks whether the changes are being propagated or runs the puppet agent with a command like: sudo puppetd agent --no-daemonize --verbose --debug which will show something like: err: Could not retrieve catalog from remote server: SSL_connect returned=1 errno=0 state=SSLv3 read server session ticket A: sslv3 alert bad certificate notice: Using cached catalog err: Could not retrieve catalog; skipping run after retrieving the signed ca certificate. It is NOT due to a problem with time syncing, as can be verified by checking the validity time of the certificate with a command like: sudo openssl x509 -text -noout -in /etc/puppet/ssl/certs/ca.pem and ensuring that the not before time lies in the future. It is likely due to an inability of the ruby puppet application to properly verify the ca certificate. See for example this now closed bug at puppetlabs: http://projects.puppetlabs.com/issues/14067 This page contains a fair amount of useful information about puppet's use of certificates: http://projects.puppetlabs.com/projects/1/wiki/Certificates_And_Security ** Affects: puppet (Ubuntu) Importance: Undecided Status: New ** Tags: puppet server -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to puppet in Ubuntu. https://bugs.launchpad.net/bugs/986649 Title: puppet agent can't obtain catalogs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/puppet/+bug/986649/+subscriptions -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 579924] Re: Upgrading Ubuntu LTS skips database version - Fatal error: Version error for database bacula. Wanted 12, got 10
Also just affected me on upgrade from karmic to lucid, using mysql. This just cost me a couple of hours, so I definitely vote in favor of having this handled properly during upgrade, especially as it affects LTS-LTS upgrades. -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to bacula in Ubuntu. https://bugs.launchpad.net/bugs/579924 Title: Upgrading Ubuntu LTS skips database version - Fatal error: Version error for database bacula. Wanted 12, got 10 -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
For the time being, I posted an update for the network-auth.xml in ubuntu-docs. https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/437483 -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
Yes, continues to be annoying. One thing to do is to carefully verify the certificate chain you have configured for LDAP use. If the certificate is self-signed, then don't configure the olcCACertificateFile item. Otherwise, make sure the CA signing the certificate has its certificate in this property. -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
Thanks Dave. I agree about the docs on this. Can you comment on which howto you were using? -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
Playing around with the source today and debugging slapd with gdb.
It appears that much of the pain here is in tls_g.c, the wrappers for
gnutls. The function tlsg_ctx_init in particular. This is where, at
least for my configuration, most of the failures are occurring. And the
code in this function often makes a call onto a gnutls function, as in:
if (lo-ldo_tls_cacertfile != NULL) {
rc = gnutls_certificate_set_x509_trust_file(
ctx-cred,
lt-lt_cacertfile,
GNUTLS_X509_FMT_PEM );
if ( rc 0 ) return -1;
}
and doesn't really do anything with the return code. There are 3 places
in tlsg_ctx_init where this occurs with no logging of what the actual
error code was. It just returns -1, rather than a more specific error
code. Upshot is that we simply get a -1 error code in the log with no
further advice on the specific problem.
The code in tls_o.c for this function and others seems better developed
and reports more useful error codes.
With a self-signed certificate, and setting only the olcTLSCertificateFile
olcTLSCertificateKeyFile, the server works and does answer properly when trying
with a command on another machine like:
openssl s_client -connect ldapServerIP:636 -showcerts
If oldTLSCACertificateFile is set to the self-signed certificate, slapd
fails to initialize TLS.
I suspect most of the problems being reported are due to configuration
issues, like those reported by Christian R. Without better error output,
it is very difficult to figure these out.
Now I'd be delighted to try and add more debugging and produce a patch;
however, perhaps I can get a bit of help with the packaging?
I've been able to get the source with 'apt-get source libldap-2.4-2',
and go in change the debian/configure.options, followed by a 'debchange
-i' and 'debuild -us -uc -i -I', then a 'sudo debi', and get a version
with debugging symbols installed.
What has been eluding me (after reading the HOWTO and several other
tutorials), is how to get changes in the source to build into the
package properly when installed and how to get other Debug statements to
work (though perhaps that is just because the packaging isn't working
right, since the machine language statements in the debugger don't agree
with the source listed in gdb, ouch). With a -nc option on debuild it
builds, but likely isn't actually including the changes. Without the
-nc, it complains about the upstream patches not being able to be
applied.
Hopefully someone can point me to the correct descriptions or give me
some help on this one.
Of course, a fixed up package with better error output from one of the
openldap gurus would be most welcome!
thanks,
Peter
--
ldap tls refusing to initialize
https://bugs.launchpad.net/bugs/420277
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to openldap in ubuntu.
--
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
Interesting. My version also was an upgrade from hardy-intrepid-jaunty. My /etc/ldap/ldap.conf doesn't contain a line about TLS_RANDFILE though, and my install doesn't report the TLS: gcry_control error, rather, there is nothing other than the main: TLS init def ctx failed: -1 complaint. I suspect these may be related problems, at least in the sense of hard to tell what is going wrong during initialization. I will likely later this weekend try to clear aside configuration and try a local build of openldap with debugging for gdb turned on and built against gnutls. -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
Interesting that there is the TLS complaint through TLS: gcry_control ... Nothing like that in mine. I was looking through the source a bit last night on this. It seems that the TLS init call is returning a -1 error code under some circumstances without really throwing another error message. Despite the problems with gnutls, it seems the ubuntu folks are committed to staying with it for licensing reasons. -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
** Changed in: openldap (Ubuntu) Status: Invalid = New -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] Re: ldap tls refusing to initialize
Thanks Mr. Gug. I checked this, placing the apparmor profile into complain mode with sudo aa-complain /usr/sbin/slapd. The same problem occurs with an attempt to start slapd, but there are no entries in /var/log/kern.log associated and no audit entries. I also moved the certificates and keys generated using gnutls into /etc/ssl/certs and /etc/ssl/private. Still the same problem with no audit entries in the /var/log/kern.log. I'm not quite certain what is meant by standard locations, since https://help.ubuntu.com/9.04/serverguide/C/openldap-server.html says to put then in /etc/ssl/certs and /etc/ssl/private under the TLS and SSL sections, though I am happy to try moving them anywhere that may help. Is there some setting I should be using to get more information out of gnutls about what may be going on? thanks, Peter -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
[Bug 420277] [NEW] ldap tls refusing to initialize
Public bug reported: Binary package hint: libldap-2.4-2 Trying to run a slapd server in Ubuntu 9.04, generally following the docs at: https://help.ubuntu.com/9.04/serverguide/C/openldap- server.html. It works fine until I try and use certificates as per the section TLS and SSL on that page. Then, if I try and start using /etc/init.d/slapd it tells me to start using the debugging flags. If I then do so with the command: sudo slapd -d -1 -h 'ldap:/// ldapi:/// ldaps:///' -g openldap -u openldap -F /etc/ldap/slapd.d/ At the end of copious output is: main: TLS init def ctx failed: -1 slapd destroy: freeing system resources. slapd stopped. This is with entries in /etc/ldap/slapd.d/cn=config.ldif like: olcTLSCACertificateFile: /home/peter/CA/server-ca-cert.pem olcTLSCertificateFile: /home/peter/CA/server-gnutls-cert.pem olcTLSCertificateKeyFile: /home/peter/CA/server-gnutls-key.pem If these entries are commented out, the server will start and work. This occurs with a private key and certificate generated using both openssl and with the gnutls certtool. Dependencies for slapd are: ldd -v $(which slapd) linux-gate.so.1 = (0xb7de2000) libldap_r-2.4.so.2 = /usr/lib/libldap_r-2.4.so.2 (0xb7d97000) liblber-2.4.so.2 = /usr/lib/liblber-2.4.so.2 (0xb7d89000) libdb-4.7.so = /usr/lib/libdb-4.7.so (0xb7c34000) libodbc.so.1 = /usr/lib/libodbc.so.1 (0xb7bcd000) libpthread.so.0 = /lib/tls/i686/cmov/libpthread.so.0 (0xb7bb4000) libslp.so.1 = /usr/lib/libslp.so.1 (0xb7ba4000) libnsl.so.1 = /lib/tls/i686/cmov/libnsl.so.1 (0xb7b8b000) libsasl2.so.2 = /usr/lib/libsasl2.so.2 (0xb7b73000) libgnutls.so.26 = /usr/lib/libgnutls.so.26 (0xb7ad5000) libtasn1.so.3 = /usr/lib/libtasn1.so.3 (0xb7ac3000) libz.so.1 = /lib/libz.so.1 (0xb7aad000) libgcrypt.so.11 = /lib/libgcrypt.so.11 (0xb7a44000) libcrypt.so.1 = /lib/tls/i686/cmov/libcrypt.so.1 (0xb7a12000) libresolv.so.2 = /lib/tls/i686/cmov/libresolv.so.2 (0xb79fb000) libltdl.so.7 = /usr/lib/libltdl.so.7 (0xb79f2000) libdl.so.2 = /lib/tls/i686/cmov/libdl.so.2 (0xb79ee000) libwrap.so.0 = /lib/libwrap.so.0 (0xb79e5000) libc.so.6 = /lib/tls/i686/cmov/libc.so.6 (0xb7882000) /lib/ld-linux.so.2 (0xb7de3000) libgpg-error.so.0 = /lib/libgpg-error.so.0 (0xb787e000) Related packages installed: gnutls-bin 2.4.2-6ubuntu0.1 gnutls26 install ok installed gnutls-doc 2.4.2-6ubuntu0.1 gnutls26 install ok installed ldap-utils 2.4.15-1ubuntu3 openldap install ok installed libcurl3-gnutls 7.18.2-8ubuntu4.1 curl install ok installed libgnutls26 2.4.2-6ubuntu0.1 gnutls26 install ok installed libldap-2.4-2 2.4.15-1ubuntu3 openldap install ok installed slapd 2.4.15-1ubuntu3 openldap install ok installed It doesn't seem like this could be a problem with V1 certificates, since both the CA cert and the server cert have X.509 Certificate Information: Version: 3 (cf. https://bugs.launchpad.net/bugs/305264). Additionally they have Signature Algorithm: RSA-SHA. I wonder if it is related to a cipher suite specification, given http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256. Though I tried setting 'olcTLSCipherSuite: +AES-256-CBC:+SHA1' in the cn=config.ldif file, to no avail. I don't know how to get the more detailed information from TLS, I only see the 'main: TLS init def ctx failed: -1' line. Is this another issue with the gnutls specifications? Or just something missing in the docs there for jaunty. Strikes me as a fairly important issue for ubuntu server. Peter ** Affects: openldap (Ubuntu) Importance: Undecided Status: New ** Tags: ldap tls -- ldap tls refusing to initialize https://bugs.launchpad.net/bugs/420277 You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to openldap in ubuntu. -- Ubuntu-server-bugs mailing list Ubuntu-server-bugs@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs
