Applying Benjamin's patch to RELENG_8 sources csupped yesterday stops
the buildworld in last library stage:
In file included from /usr/src/lib/libc/rpc/clnt_dg.c:55:
/usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:52: error: expected
specifier-qualifier-list before 'gss_cred_id_t'
After manually changing the gssapi header used in
/usr/src/include/rpc/rpcsec_gss.h to somewhat klunky #include
/usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h system csupped
yesterday built okay and after rebuilding cyrus-sasl, saslauthd and
cyrus I get the following failures in log:
Jul
On 07/17/2010 03:37 PM, Reko Turja wrote:
Can you try reproducing the issue on 8-STABLE?
I recently submitted a Heimdal patch against 8.1-STABLE and
9.0-CURRENT that resolves some libgssapi-related issues:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454
The patch breaks ABI, so
On 07/18/2010 06:52 AM, Reko Turja wrote:
After manually changing the gssapi header used in
/usr/src/include/rpc/rpcsec_gss.h to somewhat klunky #include
/usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h system csupped
yesterday built okay and after rebuilding cyrus-sasl, saslauthd and
cyrus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, 16 Jul 2010, Jeremy Chadwick wrote:
On Fri, Jul 16, 2010 at 03:58:04PM +0300, Reko Turja wrote:
I think we need the OP of the PR[1], Mikhail T., to chime in here
with his
setup.
While waiting, can you test the following: In the
On Sat, Jul 17, 2010 at 08:55:54AM +0200, Joerg Pulz wrote:
i followed this thread so far and searched a little bit about the issue.
I also tested on my machines and came to an interesting point.
First my setup is pretty straight forward.
Set HEIMDAL_HOME=/usr .
Build security/cyrus-sasl2
I'll build an i386 version of my testbox and start the procedure
over
again.
Just installed cyrus for testing into another i386 system and hit the
same exact bug. I wonder if this is the reason for the problem we're
encountering:
http://www.freebsd.org/cgi/query-pr.cgi?pr=138929
This
On Sat, Jul 17, 2010 at 05:00:15PM +0300, Reko Turja wrote:
I'll build an i386 version of my testbox and start the procedure
over
again.
Just installed cyrus for testing into another i386 system and hit
the same exact bug. I wonder if this is the reason for the problem
we're encountering:
On 07/17/2010 07:41 AM, Jeremy Chadwick wrote:
The problem really looks to be with GSSAPI, which is part of the base
system (src/lib/libgssapi).
If I can reproduce the problem on the test i386 system I'm building,
which will have the same port + configuration as the test amd64 system,
then
On Sat, Jul 17, 2010 at 11:15:42AM -0700, Benjamin Lee wrote:
On 07/17/2010 07:41 AM, Jeremy Chadwick wrote:
The problem really looks to be with GSSAPI, which is part of the base
system (src/lib/libgssapi).
If I can reproduce the problem on the test i386 system I'm building,
which will
Can you try reproducing the issue on 8-STABLE?
I recently submitted a Heimdal patch against 8.1-STABLE and
9.0-CURRENT that resolves some libgssapi-related issues:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454
The patch breaks ABI, so you'll have to rebuild libgssapi-dependent
On 17.07.2010 09:41, Jeremy Chadwick wrote:
The test system is amd64. I'm not doubting the issue may be more
apparent/easier to occur on i386, but pure luck on amd64 is a bit
surprising.
I'll build an i386 version of my testbox and start the procedure over
again.
Set the malloc(3) flags to
On Sun, Jul 18, 2010 at 01:37:06AM +0300, Reko Turja wrote:
Can you try reproducing the issue on 8-STABLE?
I recently submitted a Heimdal patch against 8.1-STABLE and
9.0-CURRENT that resolves some libgssapi-related issues:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454
The
On Sat, Jul 17, 2010 at 07:38:19PM -0700, Jeremy Chadwick wrote:
On Sun, Jul 18, 2010 at 01:37:06AM +0300, Reko Turja wrote:
Can you try reproducing the issue on 8-STABLE?
I recently submitted a Heimdal patch against 8.1-STABLE and
9.0-CURRENT that resolves some libgssapi-related
On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
Furthermore, relevant bug (PR 144754) indicates there's an easier way to
induce this problem, so I'm going to see if I can reproduce it here
locally. It's almost certainly the same problem but induced via a
slightly different
On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
Furthermore, relevant bug (PR 144754) indicates there's an easier
way to
induce this problem, so I'm going to see if I can reproduce it here
locally. It's almost certainly the same problem but induced via a
slightly different
On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote:
Another datapoint that might or might not have some connection with
the issue is that in _gss_mg_error (m=0x28a86480, maj=851968, min=2)
at /usr/src/lib/libgssapi/gss_display_status.c
void
232 _gss_mg_error(struct
On Fri, Jul 16, 2010 at 11:56:17AM +0300, Reko Turja wrote:
On Thu, Jul 15, 2010 at 09:22:51AM -0700, Jeremy Chadwick wrote:
Furthermore, relevant bug (PR 144754) indicates there's an
easier way to
induce this problem, so I'm going to see if I can reproduce it here
locally. It's almost
This doesn't help. The problem is that Cyrus imapd is completely
freaking out, continually dying and re-forking itself, with my
kernel
message buffer filling rapidly + all.log filling. So, there is
further
configuration of this daemon that's needed (meaning it does not work
straight out of
void
232 _gss_mg_error(struct _gss_mech_switch *m, OM_uint32 maj,
OM_uint32 min)
233 {
234 OM_uint32 major_status, minor_status;
235 OM_uint32 message_content;
236 struct mg_thread_ctx *mg;
237
238 mg = last_error_context;
239
240
On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote:
This doesn't help. The problem is that Cyrus imapd is completely
freaking out, continually dying and re-forking itself, with my
kernel
message buffer filling rapidly + all.log filling. So, there is
further
configuration of this
On Fri, Jul 16, 2010 at 04:04:27AM -0700, Jeremy Chadwick wrote:
On Fri, Jul 16, 2010 at 12:43:22PM +0300, Reko Turja wrote:
This doesn't help. The problem is that Cyrus imapd is completely
freaking out, continually dying and re-forking itself, with my
kernel
message buffer filling
Thanks. Most of this worked, except the following:
[SNIP]
Which worked. I hope this was the right thing to do.
My bad there, I was slightly pressed for time and did not check if
default cyrus documentation was sane in freebsd context - what you did
was quite correct.
However, upon
On Fri, Jul 16, 2010 at 02:33:17PM +0300, Reko Turja wrote:
You can move the surplus mechs (libopie*, libntlm*) from
/usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled
To deal with this in a more clean manner, I rebuilt
security/cyrus-sasl23 with the following OPTIONS unchecked:
I think we need the OP of the PR[1], Mikhail T., to chime in here
with his
setup.
While waiting, can you test the following: In the
/usr/local/etc/imapd.conf file comment out
#sasl_pwcheck_method: saslauthd
and add below it:
sasl_mech_list: gssapi pam plain
-Reko
On Fri, Jul 16, 2010 at 03:58:04PM +0300, Reko Turja wrote:
I think we need the OP of the PR[1], Mikhail T., to chime in here
with his
setup.
While waiting, can you test the following: In the
/usr/local/etc/imapd.conf file comment out
#sasl_pwcheck_method: saslauthd
and add below it:
On Thu, Jul 15, 2010 at 12:14:58AM +0300, Reko Turja wrote:
I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd
linked against system kerberos.
(uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1:
Sat Jun 12 00:39:22 EEST 2010
--
From: Jeremy Chadwick free...@jdc.parodius.com
Sent: Thursday, July 15, 2010 7:22 PM
To: Reko Turja reko.tu...@liukuma.net
Cc: Henrik /KaarPoSoft hen...@kaarposoft.dk;
freebsd-stable@freebsd.org
Subject: Re: openldap client GSSAPI
I had similar issue with 8-RELEASE and cyrus-sasl2 with cyrus-saslauthd linked
against system kerberos.
(uname -a xxx.xxx.xxx 8.0-RELEASE-p3 FreeBSD 8.0-RELEASE-p3 #1: Sat Jun 12 00:39:22 EEST 2010
r...@xxx.xxx.xxx:/usr/obj/usr/src/sys/WWW i386)
The problem manifested itself with pretty
29 matches
Mail list logo
