I still seem to have a problem solved by copying /dev/random to
/var/spool/postfix/dev/random (urandom exists). This is on Precise with
Postfix 12.04. I am using Postfix+LDAP+OpenSSL.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
I still seem to have a problem solved by copying /dev/random to
/var/spool/postfix/dev/random (urandom exists). This is on Precise with
Postfix 12.04. I am using Postfix+LDAP+OpenSSL.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Just ran into this problem in lucid. Just wanted to leave a comment to
point out that it's still an issue.
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in Ubuntu.
https://bugs.launchpad.net/bugs/81242
Title:
postfix-ldap
Just ran into this problem in lucid. Just wanted to leave a comment to
point out that it's still an issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/81242
Title:
postfix-ldap is linked against
@Andreas,
Yes, I am using Postfix + LDAP, but I worked around this problem by
running a local slapd that syncrepl's the relevant DB's over SSL, and
then configured postfix to use ldap://127.0.0.1. It's far from elegant,
but it does have the additional benefit that mail can still be accepted,
even
@Andreas,
Yes, I am using Postfix + LDAP, but I worked around this problem by
running a local slapd that syncrepl's the relevant DB's over SSL, and
then configured postfix to use ldap://127.0.0.1. It's far from elegant,
but it does have the additional benefit that mail can still be accepted,
even
For what it's worth this is still a problem in 10.04.1 and Postfix
2.7.0-1. Manually copying /dev/random and /dev/urandom to
/var/spool/postfix/dev works around the problem.
I also find it quite strange that this doesn't affect more people. In
fact this bug seems to have been completely
For what it's worth this is still a problem in 10.04.1 and Postfix
2.7.0-1. Manually copying /dev/random and /dev/urandom to
/var/spool/postfix/dev works around the problem.
I also find it quite strange that this doesn't affect more people. In
fact this bug seems to have been completely
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Hoggarth schreef:
Should the postfix package not be updated to mknod suitable devices in
/var/spool/postfix/dev on installation?
That was the original point I made, yes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
I'm setting up some servers and workstations using Hardy, and just got bitten
by this problem - default configuration of postfix is chrooted, postfix-ldap
will not work against an LDAP server using SSL/TLS because the /dev/random and
/dev/urandom devices are not present in the chroot, which
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Neil Hoggarth schreef:
Should the postfix package not be updated to mknod suitable devices in
/var/spool/postfix/dev on installation?
That was the original point I made, yes.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.9 (GNU/Linux)
Well, for one you could work around the issue using:
mkdir /var/spool/postfix/dev
cp -a /dev/random /dev/urandom /var/spool/postfix/dev
This should solve the exit_group(2) errors, as it did for me.
Of course the proper (read: permanent) fix would be to include this in
the init scripts, but this
Well, for one you could work around the issue using:
mkdir /var/spool/postfix/dev
cp -a /dev/random /dev/urandom /var/spool/postfix/dev
This should solve the exit_group(2) errors, as it did for me.
Of course the proper (read: permanent) fix would be to include this in
the init scripts, but this
So what is needed exactly? I currently have an LDAP installation failing
due to this exact issue of being compiled against gnutls. Right now all
I have is a debut level log output. Let me know if I might be able to
supply more helpful information?
This is where ldap goes bad:
TLS: could not set
So what is needed exactly? I currently have an LDAP installation failing
due to this exact issue of being compiled against gnutls. Right now all
I have is a debut level log output. Let me know if I might be able to
supply more helpful information?
This is where ldap goes bad:
TLS: could not set
Marking as 'incomplete' and unmilestoning. We still need the stderr output of
a
process that's failing in this way to diagnose whether it's a postfix or
gnutls bug.
IMHO it is a bug in both.
- GnuTLS is a library and therefore should not do fprintf(stderr,..) + exit,
because printing to
** Changed in: postfix (Ubuntu)
Status: Incomplete = Confirmed
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in ubuntu.
--
Marking as 'incomplete' and unmilestoning. We still need the stderr output of
a
process that's failing in this way to diagnose whether it's a postfix or
gnutls bug.
IMHO it is a bug in both.
- GnuTLS is a library and therefore should not do fprintf(stderr,..) + exit,
because printing to
** Changed in: postfix (Ubuntu)
Status: Incomplete = Confirmed
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
Thu GNU TLS library does exit_group(2) when no /dev/random (or
/dev/urandom) is available (in the chroot, there isn't, so the TLS code
for LDAP is broken). Wietse Venema wrote the explanation Steve Langasek
quoted, because Wietse does not really like a library calling
exit_group(2).
I'm not aware
Thu GNU TLS library does exit_group(2) when no /dev/random (or
/dev/urandom) is available (in the chroot, there isn't, so the TLS code
for LDAP is broken). Wietse Venema wrote the explanation Steve Langasek
quoted, because Wietse does not really like a library calling
exit_group(2).
I'm not aware
[15 Apr, @01:00 CEST, Steve Langasek wrote in [Bug 81242] Re: postfix-ldap i
...]
Marking as 'incomplete' and unmilestoning. We still need the stderr
output of a process that's failing in this way to diagnose whether it's
a postfix or gnutls bug.
It will not be possible for me to provide
[15 Apr, @01:00 CEST, Steve Langasek wrote in [Bug 81242] Re: postfix-ldap i
...]
Marking as 'incomplete' and unmilestoning. We still need the stderr
output of a process that's failing in this way to diagnose whether it's
a postfix or gnutls bug.
It will not be possible for me to provide
Marking as 'incomplete' and unmilestoning. We still need the stderr
output of a process that's failing in this way to diagnose whether it's
a postfix or gnutls bug.
** Changed in: postfix (Ubuntu)
Status: Triaged = Incomplete
Target: ubuntu-8.04 = None
--
postfix-ldap is linked
** Changed in: postfix (Ubuntu)
Target: None = ubuntu-8.04
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
So we have openldap 2.4 in Hardy. Can this get fixed now? Is it
already?
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to postfix in ubuntu.
--
So we have openldap 2.4 in Hardy. Can this get fixed now? Is it
already?
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
As Soren discovered, libldap2 depends on gnutls, while slapd on libssl.
Why do we have libldap2 agains gnutls? :)
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact
I propose solution where we would leave libldap2 as is, but also build
additional libldap2-nongpl (or some other name) which would be built
against openssl. Then postfix and other non-GPL software could build
against libldap2-nongpl.
--
postfix-ldap is linked against gnuTLS
Ante,
libldap2 exists only because we need to link to gnutls, so other packages don't
inadvertently link to openssl, which is not compatible with the GPL.
OpenLDAP2.4, which is in development will link to gnutls, so, we will no longer
need openldap2 and this problem should go away.
-rick
--
http://archives.neohapsis.com/archives/postfix/2007-01/1423.html
** Changed in: postfix (Ubuntu)
Importance: Undecided = Medium
Status: New = Triaged
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a
** Changed in: postfix (Ubuntu)
Status: Triaged = Confirmed
--
postfix-ldap is linked against gnuTLS
https://bugs.launchpad.net/bugs/81242
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
Interesting situation. Both postfix and postfix-ldap pick up their
dependency on a TLS library from ${shlibs:Depends}, but get a different
answer.
** Changed in: postfix (Ubuntu)
Status: Confirmed = Triaged
** Tags added: packaging
--
postfix-ldap is linked against gnuTLS
33 matches
Mail list logo
