[Bug 987532] Re: description of puppet configuration is wrong
https://help.ubuntu.com/12.04/serverguide/puppet.html -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987532 Title: description of puppet configuration is wrong To manage notifications about this bug go to: https://bugs.launchpad.net/serverguide/+bug/987532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 987532] [NEW] description of puppet configuration is wrong
Public bug reported: In the server guide, the configuration described for puppet is not correct, and can be misleading for people trying to use this as a known starting point. The nodes.pp file is not needed here, as the entries for package and service 'apache2' will apply to all nodes by default. Either these should be moved under a class 'apache' and then sites.pp should import nodes or the nodes.pp file part should be removed and it should be explained that this will apply to all nodes. ** Affects: ubuntu-docs (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/987532 Title: description of puppet configuration is wrong To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-docs/+bug/987532/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 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 Bugs, which is subscribed to 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-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 426778] Re: Please upgrade calendarserver to version 2.3 from upstream
Trying to determine how to develop a package working from the source code for 2.3, since the upstream doesn't seem to be moving. Page now on the wiki: https://wiki.ubuntu.com/CalendarServerPackaging Hopefully others can contribute who have more expertise in packaging. -- Please upgrade calendarserver to version 2.3 from upstream https://bugs.launchpad.net/bugs/426778 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 403349] Re: calendarserver has dependency on non-existent python-xml package in karmic
Trying to determine how to develop a package working from the source code for 2.3, since the upstream doesn't seem to be moving. Page now on the wiki: https://wiki.ubuntu.com/CalendarServerPackaging Hopefully others can contribute who have more expertise in packaging. -- calendarserver has dependency on non-existent python-xml package in karmic https://bugs.launchpad.net/bugs/403349 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 403349] Re: calendarserver has dependency on non-existent python-xml package in karmic
It looks like version 2.3 will require a fair number of changes to the debian and ubuntu packaging, from what I can see. Spent a fair amount of time working with 1.4 from http://trac.calendarserver.org/browser/CalendarServer/tags/release/CalendarServer-1.4 which was released at basically the same time as 2.3, that is, 3 months ago. I'm a newbie at this packaging business, so am sure it is not quite right yet. I took the source for 1.4 and copied in the debian subdirectory from the prior ubuntu package. Needed to make a number of changes to some patch files and the control file. Have been able to build the source package, build the package, and install on my system (though with a syntax warning in one module that may indicate another patch that needs changing). I'm finished with this for the weekend, so thought I would forward along my source directory and orig.tar.gz tarball that I was using in construction. I'm assuming that really the way this should work is either for the debian upstream to be fixed, or for the source to be retrieved via the svn from macports and then a debian subdirectory added, but I'm definitely not sure on that. Perhaps others can carry on with the packaging and testing from here? thanks, Peter ** Attachment added: Attempt to get 1.4 source version working. http://launchpadlibrarian.net/35936991/calendarServer1.5Attempt.tgz -- calendarserver has dependency on non-existent python-xml package in karmic https://bugs.launchpad.net/bugs/403349 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 403349] Re: calendarserver has dependency on non-existent python-xml package in karmic
Interesting, perhaps 2.3 isn't so bad. I took the source from macports for 2.3 and copied in the debian subdirectory from the ubuntu 1.2 source. Removed all files from patches (after all, these may have been fixed). Modified calendarserver.examples to point at conf/auth/accounts.xml rather than conf/accounts.xml. Modified control file to remove dependence on python-twisted-calendarserver, and changed dependence on python-xml to python-lxml. This seems to build and install. No idea if it works well or at all. -- calendarserver has dependency on non-existent python-xml package in karmic https://bugs.launchpad.net/bugs/403349 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 437483] Re: Improved description of permissions for openldap using TLS
Sorry to hear that is still trouble. I've been slowly working on the patch to provide better error reporting when using GNUtls, but it will be a while. With an official cert, you will need all 3 of the olcTLSxxx parameters set. Assuming that is in line, I would be sure the group has read permissions on the certs and key and read and execute on the directories containing them. -- Improved description of permissions for openldap using TLS https://bugs.launchpad.net/bugs/437483 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 437483] Re: Improved description of permissions for openldap using TLS
Yes, indeed. I guess I'm not familiar enough with bazaar version control. I obtained a copy of the docs, modified and performed a commit with a message, giving me rev # 354. But I take it that must not propagate the change. I was trying to follow the instructions in the bugs playbook at: https://wiki.ubuntu.com/DocumentationTeam/SystemDocumentation?action=AttachFiledo=viewtarget=BugsPlaybook.pdf but the command 'bzr diff diffname.txt' near the end didn't give anything. Subsequently, I've generated a differences file using 'bzr diff -r 353 changes.txt', which seems to contain the differences, and I attach here. Please let me know if there was some other more proper way of accomplishing this. ** Attachment added: changes.txt http://launchpadlibrarian.net/32531511/changes.txt -- Improved description of permissions for openldap using TLS https://bugs.launchpad.net/bugs/437483 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 437483] [NEW] Improved description of permissions for openldap using TLS
Public bug reported: Binary package hint: ubuntu-docs With the use of GNUtls users often encounter an error of the form main: TLS init def ctx failed: -1 without further explanation (which was available with openssl). Witness for example https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/420277 To help avoid this, I've update the notes on the network authentication page regarding the use of certificates and items to check, revno 354 of ubuntu-doc. ** Affects: ubuntu-docs (Ubuntu) Importance: Undecided Status: New -- Improved description of permissions for openldap using TLS https://bugs.launchpad.net/bugs/437483 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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
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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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
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
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-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. 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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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
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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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] 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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-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
[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 Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
Also, should I be registering this as a new bug on 2.6.28-4, since it has to do with the new drivers, rather than the old? -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
Again, thanks Stefan for the suggestions. I followed up on this and tried getting the Tandberg VXA-2 tape drive and PacketLoader tape library to mount with the new drivers. Booted off a jaunty alpha 3 live cd, which gives kernel 2.6.28-4-generic. Then, with the tape drive not plugged in, did modprobe -r ohci1394 modprobe firewire-ohci modprobe firewire-sdp2 so far, this gives the following in the kern.log: Feb 4 00:07:14 ubuntu kernel: [ 152.065612] ieee1394: Node removed: ID:BUS[0-00:1023] GUID[003093412325] Feb 4 00:07:28 ubuntu kernel: [ 166.296014] firewire_ohci: Added fw-ohci device :03:01.0, OHCI version 1.10 Feb 4 00:07:29 ubuntu kernel: [ 166.796127] firewire_core: created device fw0: GUID 003093412325, S800 I then plug in the tape drive and the following shows up: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 scsi3 : SBP-2 IEEE-1394 firewire_sbp2: Workarounds for fw1.0: 0x2 (firmware_revision 0x000201, model_id 0x00) scsi4 : SBP-2 IEEE-1394 firewire_sbp2: Workarounds for fw1.1: 0x2 (firmware_revision 0x000201, model_id 0x00) firewire_core: created device fw1: GUID 0010100319003177, S800 firewire_sbp2: fw1.0: logged in to LUN (0 retries) scsi 3:0:0:0: Sequential-Access EXABYTE VXA-2a 2152 PQ: 0 ANSI: 2 scsi 3:0:0:0: Attached scsi generic sg2 type 1 firewire_sbp2: fw1.1: logged in to LUN 0001 (0 retries) firewire_sbp2: released fw1.0, target 3:0:0 firewire_sbp2: released fw1.1, target 4:0:0 st: Version 20080504, fixed bufsize 32768, s/g segs 256 Driver 'st' needs updating - please use bus_type methods osst :I: Tape driver with OnStream support version 0.99.4 osst :I: $Id: osst.c,v 1.73 2005/01/01 21:13:34 wriede Exp $ Driver 'osst' needs updating - please use bus_type methods firewire_core: giving up on config rom for node id ffc1 firewire_core: phy config: card 0, new root=ffc1, gap_count=5 firewire_core: giving up on config rom for node id ffc0 scsi5 : SBP-2 IEEE-1394 firewire_sbp2: Workarounds for fw1.0: 0x2 (firmware_revision 0x000201, model_id 0x00) scsi6 : SBP-2 IEEE-1394 firewire_sbp2: Workarounds for fw1.1: 0x2 (firmware_revision 0x000201, model_id 0x00) firewire_core: created device fw1: GUID 0010100319003177, S800 firewire_core: phy config: card 0, new root=ffc0, gap_count=5 firewire_sbp2: released fw1.0, target 5:0:0 firewire_sbp2: released fw1.1, target 6:0:0 firewire_core: phy config: card 0, new root=ffc1, gap_count=5 firewire_core: giving up on config rom for node id ffc0 Looks like it initially figured out it was a VXA-2 and created the sg device, but then it was released and something went on with the tape driver. This seems to loop forever, creating two more devices, then giving up on them, over and over again. Is there something else I need to do about the tape driver? Other ideas for testing on jaunty? -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
Firstly, thanks for the extensive explanation Stefan. I tried setting the 0x100 option for sbp2, and you are correct, no other workarounds are now enabled, but that doesn't fix this. I also tried a modified kernel module, where there is a distinction between the first and second time out messages. This is the first message. I also tried increasing the timeout value to 40s, this also didn't help. In reviewing all of the dmesg logs however, I noticed there is an early complaintm after the host is added, there a large number of complaints that ieee1394: The root node is not cycle master capable; selecting a new root node and resetting... Eventually this stops repeating. And then there is the complaint ieee1394: Error parsing configrom for node 0-00:1023 (where this node id is for the tape drive in question) Do these two items indicate that something else is actually going on here? I would certainly appreciate any other suggestions on what I could try to get this tape drive working under ubuntu. It is reported to work under FreeBSD, so perhaps I'll try that next. -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 279342] Re: External ieee1394 drive not recognized 2.6.27-5
I would like to add an additional device that seems to be having a very similar same problem, under a variety of kernel versions. (I am happy to move this to a new thread if people think that is better). This is the Tandberg Data StorageLoader VXA-2 1U with firewire interface. (http://www.tandbergdata.com/us/en/products/search- result/?action=2product=62ref=166) The dmesg looks like: - [ 78.748200] ieee1394: sbp2: Workarounds for node 0-00:1023: 0x2 (firmware_revision 0x000201, vendor_id 0x001010, model_id 0x00) - [ 99.737945] ieee1394: sbp2: Error logging into SBP-2 device - timed out [ 99.738104] sbp2: probe of 0010100319003177-1 failed with error -16 I am able to access the drive and tape library under MacOS X using the manufacturer provided tools and am able to upgrade the firmware, etc. The message above is under ubuntu hardy heron server (8.04 i386) kernel 2.6.24-19-server. It persists after unloading and loading the ohci1394 module or the sdp2 module. This message is also produced when booting off the LiveCD versions for either Ubuntu Intrepid Ibex or the Jaunty alpha 3 release. The controller chip on the host (a SuperMicro server) is a Texas Instruments TSB82AA2 IEEE-1394b Link Layer Controller (rev 01). It appears that this tape/library is using an Initio Firewire-PATA controller bridge. Three are given on their site http://www.initio.com/Html/Products.asp. Given the age of the product, I might suspect the inic-1430. I understand this chip has had issues in the past under Linux kernels, and I see in the dmesg that a workaround is being used. The comments in the source (sdp2.c) for this workaround note, however, that this may have been only necessary for their older products, and the lookup is using a wildcard for the model_id. So is it possible, with the latest firmware upgrades, that this workaround itself is causing the timeout on login? (the workaround seems to be chopping the length in the request to conform to some older windows bug) And if this is true, is there a way to turn off the workaround? Or perhaps modify this module to identify the devices for which the workaround is really needed? -- External ieee1394 drive not recognized 2.6.27-5 https://bugs.launchpad.net/bugs/279342 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
