Re: can the l2arc memory leak fix be pulled into 10.1-RELEASE ?
-Original Message- From: Willem Jan Withagen Sent: Monday, June 22, 2015 11:48 PM To: Daniel Genis ; freebsd-stable@freebsd.org Subject: Re: can the l2arc memory leak fix be pulled into 10.1-RELEASE ? We are kind of new to FreeBSD, so we're wondering what are the plans to merge these fixes into the 10.1-RELEASE branch ? We'd love to get these fixes without having to rebuild the kernel. Is there any chance for the merge to happen in the near future, or should we compile the kernel to get the fixes? The RELEASE branch is exactly what it says, RELEASE. And is only done once per version when the actual official RELEASE is. So the next one will be the upcoming 10.2-RELEASE. Which is schedules for August 2015 according to: There are actually 2 branches tracking release: RELEASE which is the original release itself and RELENG which is the release+security and some errata fixes. In practice one should always track and compile RELENG sources with production servers, unless there's a bugfix or added driver that's only available in STABLE. The other way to get to the front of the like is starting and tracking 10-STABLE which is the running front of the kernel/software development. STABLE means stable ABI, not necessarily that the branch is running stable. It should be considered more as a beta, than something to track if one does want. (Yes, there can be even major breakages in STABLE. It's not usual but it can happen.) The running front of development is HEAD, which is 11.0 at this time - once latest major release gets first dot release, the major version number of HEAD gets advanced. HEAD is more or less recommended for those who can deal with debugging breakages and whatnot and can be severely broken from time to time. It looks like at the moment the fix for you would be temporarily track/compile 10.1 STABLE and then once 10.2 is released start tracking 10.2 RELENG -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
-Original Message- From: Daniel Kalchev Sent: Thursday, May 31, 2012 1:01 PM 2) The BSD license. Contrary to popular belief, it has brought a lot of high quality development to FreeBSD. The salient point is that BSD license (and alike licenses)seem to bring in more talented people than GPL. Postgres vs. MySQL, BSD's vs. Loonix, Postfix, Apache etc... It's funny that talented people are pleased to see their code freely distributed, where mediocritys try their best to put it under viral licensing. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8-STABLE and swap
My question now: why does the machine swap, is this normal behaviour? Why is wired at about 30 GB if ARC=23 GB and L2ARC-header=259 MB? If I've understood it right from the mailing lists, ZFS returns memory back to the OS from caches somewhat lazily, so in times of high memory load ZFS system can cause some swapping. Of course, once the situation with memory load is over, swap will still continue to show the max amount swapped ever, even if everything is again back in real memory. So nothing to worry about I'd say. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE
From: Zhihao Yuan lich...@gmail.com Subject: Re: Fwd: Re: Fail to use Dtrace on FreeBSD 8.1-STABLE My world and kernel are sync. Is it possible that the dtrace-enabled kernel must be compiled with '-g'? On Fri, Dec 3, 2010 at 5:29 PM, Andriy Gapon a...@freebsd.org wrote: I suppose that you have some problem with either your local environment or following the procedures. Most of all, I still suspect that your world and your kernel are out of sync. Changed CFLAGS? -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GSSAPI (for OpenLDAP) on FreeBSD 8?
-- From: Jan Henrik Sylvester m...@janh.de Sent: Wednesday, September 01, 2010 7:33 PM To: stable-list freebsd freebsd-stable@freebsd.org Subject: GSSAPI (for OpenLDAP) on FreeBSD 8? Does anyone have OpenLDAP+GSSAPI running on FreeBSD 8? With the libgssapi patch? With the heimdal-1.2 port? I got running and fully functional Heimdal/GSSAPI setup with Benjamins patch from http://www.freebsd.org/cgi/query-pr.cgi?pr=147454cat=kern, although I didn't test it with LDAP. Jeremys patch as far as I know removes the symptom, but it doesn't fix the cause, which is completely missing heimdal code in the base system preventing the functional operation of heimdal. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:65: error: expected specifier-qualifier-list before 'gss_ctx_id_t' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:119: error: expected declaration specifiers or '...' before 'gss_cred_id_t' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:120: error: expected declaration specifiers or '...' before 'gss_ctx_id_t' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:149: error: expected declaration specifiers or '...' before 'gss_OID' /usr/src/lib/libc/../../include/rpc/rpcsec_gss.h:150: error: expected ')' before 'oid' *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Tried to poke around a bit but I was unable to find declarations for the missing types. How to proceed if I want to test the patch? -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 18 16:37:35 moria perl: GSSAPI Error: Miscellaneous failure (see text)^B (open(/tmp/krb5cc_0): No such file or directory) -This is expected behaviour as Kerberos was not running at the moment, but with Benjamin's patch Kerberos/GSSAPI spat out a meaningful error message After dusting off my old Kerberos setup, doing basic kinit and running cyradm localhost I got: Jul 18 16:39:00 moria perl: GSSAPI Error: Miscellaneous failure (see text) (Server (imap/localh...@xxx.domain.com) unknown) -Again expected as there is no imap trust relationship defined. So at least after cursory testing it looks like that with Benjamin's patch there is a working GSSAPI/Kerberos backend available, instead of something that chokes on passed parameters that are ok for every other tested gssapi implementation. Of course, more thorough testing in proper kerberised/LDAP environment needs to be done, which is something I haven't got time at the moment. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 patch updates the heimdal-1.0.1_1 port to heimdal-1.2.1. It works for me on 7.2/i386 and 8.0/i386 and passes portlint. I needed to upgrade to Heimdal 1.2.1 on 8.0-BETA2 (base Heimdal is 1.1.0) to get GSSAPI authenticaion to work (through SASL) for the OpenLDAP server. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 applications. When linking cyrus-sasl2 against gssapi library from either the 1.0.1 official port or the inofficial 1.2.1 patchset cyradm works as expected and it logs a message from gssapi/kerberos telling that no KDC's are available - which is to be expected on a system that isn't using gssapi/kerberos in authenticating. So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday the 5th is clearly some kind of regression as system gsslib doesn't seem to recognize the mech used or segfaults. Benjamin, can you clarify how to apply your patch against the source tree - I tried 'patch the_patchset.diff' in /usr/src but it just created a bunch of files in the /usr/src which I think isn't the intention. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 context.
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-March/038956.html
I'll report back once I poke around with that.
testbox# cyradm
cyradm
Try giving command cyradm localhost instead - the cyradm without
connection starts, but trying to connect to the local server triggers
the bug. Or you can give 'server localhost' instead from the cyradm
command line.
I should note this machine **does** have Kerberos installed as part
of
the FreeBSD base system (meaning src.conf does not contain
WITHOUT_KERBEROS).
Similar as my setup - kerberos isn't excluded even if it's not really
used.
Mikhail, is there something I need to configure within cyrus-imapd23
first? Three things to note:
1) I didn't modify /usr/local/etc/cyrus.conf or imapd.conf.
2) I have not started the imapd service.
3) /var/log/all.log shows the following errors (but the daemon
starts
anyway):
Let me know as I'm doing my best to track this down. Thanks.
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 _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 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);
242
243 mg-mech = m-gm_mech_oid;
244 mg-maj_stat = maj;
when I give following comands, gdb tells me:
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p mg
No symbol mg in current context.
(gdb)
Thank you very much for your effort in the issue!
-Reko
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 the box), and I need those configuration details.
Below is the relevant parts of my config that should get you going:
my /usr/local/etc/cyrus.conf:
START {
# do not delete this entry!
recover cmd=ctl_cyrusdb -r
# this is only necessary if using idled for IMAP IDLE
idled cmd=idled
}
# UNIX sockets start with a slash and are put into /var/imap/socket
SERVICES {
# add or remove based on preferences
imap cmd=imapd -C /usr/local/etc/imapd.conf listen=imap
prefork=0
# pop3 cmd=pop3d listen=pop3 prefork=0
# pop3scmd=pop3d -s listen=pop3s prefork=0
sieve cmd=timsieved listen=sieve prefork=0
# at least one LMTP is required for delivery
# lmtp cmd=lmtpd listen=lmtp prefork=0
lmtpunix cmd=/usr/local/cyrus/bin/lmtpd
listen=/var/imap/socket/lmtp prefork=0
# this is only necessary if using notifications
notifycmd=notifyd listen=/var/imap/socket/notify
proto=udp prefork=1
}
EVENTS {
# this is required
checkpointcmd=ctl_cyrusdb -c period=30
# this is only necessary if using duplicate delivery suppression
delprune cmd=cyr_expire -E 3 at=0400
# this is only necessary if caching TLS sessions
tlsprune cmd=tls_prune period=1440
}
And /usr/local/etc/imapd.conf
#
# $FreeBSD: ports/mail/cyrus-imapd2/files/imapd.conf,v 1.8 2002/08/08
14:06:48 ume Exp $
#
# Sample configurations file for Cyrus IMAPd
# Most lines in this file are commented; in this case the default is
used.
# The commented lines (usually) contain the default value
configdirectory: /var/imap
partition-default: /usr/local/imap
unixhierarchysep: yes
lmtp_downcase_rcpt: yes
imap_allowanonymouslogin: no
sieve_allowanonymouslogin: no
imap_allowplaintext: no
sieve_allowplaintext: yes
imapidresponse: yes
admins: cyrus toor
autocreatequota: -128
duplicatesuppression: yes
sendmail: /usr/local/sbin/sendmail
postmaster: postmaster
sieve_maxscripts: 15
sasl_maximum_layer: 256
sasl_minimum_layer: 0
sasl_pwcheck_method: saslauthd
sasl_auto_transition: yes
lmtpsocket: /var/imap/socket/lmtp
idlesocket: /var/imap/socket/idle
notifysocket: /var/imap/socket/notify
#
# EOF
In addition, check that you have the following directories created +
run the mkimap for creating the rest of directories/db's
Create the configuration directory specified by the configdirectory
option in imapd.conf. The configuration directory is similar in
concept to the /usr/lib/news directory. It stores information about
the IMAP server as a whole.
This document uses the configuration directory /var/imap in its
examples. This directory should be owned by the cyrus user and group
and should not permit access to other users.
cd /var
mkdir imap
chown cyrus imap
chgrp mail imap
chmod 750 imap
Create the default partition directories specified in the
/etc/imapd.conf file.
This document uses a default partition directory of /var/spool/imap
in the following example:
cd /var/spool
mkdir imap
chown cyrus imap
chgrp mail imap
chmod 750 imap
Change to the Cyrus user and use the tool tools/mkimap to create the
rest of the directories (subdirectories of the directories you just
created).
su cyrus
tools/mkimap
exit
Hope this helps
-Reko
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 gss_release_buffer(minor_status, mg-maj_error);
241 gss_release_buffer(minor_status, mg-min_error);
242
243 mg-mech = m-gm_mech_oid;
244 mg-maj_stat = maj;
when I give following comands, gdb tells me:
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p last_error_context
Cannot find thread-local variables on this target
(gdb) p mg
No symbol mg in current context.
(gdb)
I'm not sure if you're familiar with C or not.
This is because gdb's context is at the wrong frame. In the
backtrace
you provided originally, you'd need to do:
(gdb) frame 2
To look at the variables associated with gss_display_status.c.
last_error_context could be an exported variable (you'd need to look
through the source to find out where it's declared), so you might
have
to print it with its source filename referenced. The print command
I
gave you before (p/x filename.c::variable) didn't work, and that's a
surprise since the gdb documentation I read says it should.
Also be aware that mg is a struct, so p mg won't tell you much,
other
than whether or not it's null. You're probably more interested in
members of the struct, such as mg-maj_error and mg-min_error, and
other struct members.
I gave f 2 before entering the commands above, and unless I'm much
mistaken, 'p mg' should at least give the pointer to the start of the
struct in question, so 'No symbol mg in current context' is mildly
interesting reply from GDB :) If I understand the code in question
right the last_error_context's address should be copied to mg for
accessing the error structure defined elsewhere in the scope of the
while.
the definition is in same file and is as follows:
176 #if defined(__sparc64__) || defined(__arm__) ||
defined(__mips__)
177
178 /*
179 * These platforms don't support TLS on FreeBSD - threads will
just
180 * have to step on each other's error values for now.
181 */
182 #define __thread
183
184 #endif
185
186 struct mg_thread_ctx {
187 gss_OID mech;
188 OM_uint32 maj_stat;
189 OM_uint32 min_stat;
190 gss_buffer_desc maj_error;
191 gss_buffer_desc min_error;
192 };
193 static __thread struct mg_thread_ctx last_error_context
-Reko
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 startup, I now see the following in all.log: [SNIP] I'm not sure if this feature is needed for reproducing the crash, so I modified cyrus.conf and commented the line out, then restarted imapd, which got me: Yep, idled can be disabled as far as I'm aware, so nothing drastic there either. Then for the final test: testbox# cyradm cyradm quit testbox# cyradm localhost Password: Where I hit enter/blank, which got me: Login disabled. cyradm: cannot authenticate to server with as root testbox# And no sign of a crash. So what's next? I forgot to check all.log. It contains errors. Hopefully someone will know what to do about this: Jul 16 04:03:50 testbox imap[1619]: executed Jul 16 04:03:50 testbox imap[1619]: accepted connection Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox imap[1619]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied Jul 16 04:03:50 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 04:03:50 testbox kernel: Jul 16 04:03:50 testbox perl: GSSAPI Error: Miscellaneous failure (see text) (unknown mech-code 2 for mech unknown) Jul 16 04:03:50 testbox perl: DIGEST-MD5 client step 2 Jul 16 04:04:00 testbox imap[1619]: badlogin: localhost [127.0.0.1] DIGEST-MD5 [SASL(-17): One time use of a plaintext password will enable requested mechanism for user: no secret in database] Jul 16 04:04:03 testbox perl: NTLM client step 1 Jul 16 04:04:03 testbox imap[1619]: NTLM server step 1 Jul 16 04:04:03 testbox imap[1619]: client flags: 207 Jul 16 04:04:03 testbox perl: NTLM client step 2 Jul 16 04:04:03 testbox perl: No worthy mechs found Jul 16 04:04:03 testbox kernel: Jul 16 04:04:03 testbox perl: No worthy mechs found You can move the surplus mechs (libopie*, libntlm*) from /usr/local/lib/sasl2 to for example /usr/local/lib/sasl2/disabled check that you have the following in /etc/rc.conf and restart saslauthd afterwards saslauthd_enable=YES saslauthd_flags=-a pam -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
-- 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 authentication segfaults in fbsd8stablei386 That said, can you please execute the following in gdb and provide the output? (gdb) p/x gss_release_buffer.c::buffer-value (gdb) p/x gss_release_buffer.c::buffer-length Those gave syntax error, but going to frame 1 and printing the values gives the following: (gdb) f 1 #1 0x2899ed12 in gss_release_buffer (minor_status=0xbfbfe4b8, buffer=0x280871cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 41 free(buffer-value); (gdb) p/x buffer-length $1 = 0x0 (gdb) p/x gss_release_buffer.c::buffer-length A syntax error in expression, near `::buffer-length'. (gdb) p/x buffer-value $2 = 0x280871c0 Hope this helps - definitely looks like the issue you are suspecting. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stable i386
I have a problem: ldapsearch results in Segmentation fault under openldap-2.4.23 with cyrus-sasl-2.1.23 A thread for similar issues was started by George Mamalakis back in february: http://lists.freebsd.org/pipermail/freebsd-stable/2010-February/055017.html but I find no solution / conclusion from this thread, hence I post here... I have installed FreeBSD 8.0-RELEASE-p2 on i386, updated with freebsd-update, and ports updated with portsnap fetch update. Kerberos installed from packages, configured, and seems to work OK. 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 much the same backtrace when using cyradm tool for administering cyrus mailboxes and due time constraints I solved my issue by removing all the gssapi plugin libs from /usr/local/lib/sasl2, so my solution isn't really applicable in your case. my /etc/hosts file for the server in question contains only localhost entry + entry for one IP so George's solution didnt help with my problem. /var/log/messages has: slapd[1146]: OTP unavailable because can't read/write key database /etc/opiekeys: Permission denied kernel: pid 53862 (ldapsearch), uid 1001: exited on signal 11 (core dumped) The first message is from the LDAP server. Even if it has some problem, it should not lead the client to segfault. I agree. If I was to build a test box from scratch, can you tell me how to set up all the necessary software/etc. to mimic your environment so that I could try to reproduce this? Reviewing the source isn't enough, I'd have to actually build a debug version of libgssapi to track it down. Alternatively I can try to step you through how to debug this using gdb, but again, lack of debugging symbols makes this annoying. I'd say that based on present evidence there is something broken in gssapi/sasl interaction, but due my need of getting the server functional quickly I didn't dig much further in the issue myself, although I really don't know how to enable generating debugging symbols for ports either - Which was another reason for not digging deeper in the problem. I wonder if using dovecot-sasl would work with ldap and if it has the same issue as cyrus-sasl - athough it doesn't seem to be available as separate port. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
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 much the same backtrace when using cyradm tool for administering cyrus mailboxes and due time constraints I solved my issue by removing all the gssapi plugin libs from /usr/local/lib/sasl2, so my solution isn't really applicable in your case. After building perl, cyrus-sasl2 and userland/kernel with debug symbols I was able to get the following backtrace. #0 free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 3889arena_dalloc(chunk-arena, chunk, ptr); [New Thread 286ae140 (LWP 100273)] (gdb) bt #0 free (ptr=0x280871c0) at /usr/src/lib/libc/stdlib/malloc.c:3889 #1 0x2899ed32 in gss_release_buffer (minor_status=0xbfbfe4b8, buffer=0x280871cc) at /usr/src/lib/libgssapi/gss_release_buffer.c:41 #2 0x2899e6e2 in _gss_mg_error (m=0x28a86480, maj=851968, min=2) at /usr/src/lib/libgssapi/gss_display_status.c:240 #3 0x2899afd9 in gss_init_sec_context (minor_status=0xbfbfe5a4, initiator_cred_handle=0x0, context_handle=0x28630164, target_name=0x2861b380, input_mech_type=0x0, req_flags=58, time_req=0, input_chan_bindings=0x0, input_token=0x0, actual_mech_type=0x0, output_token=0xbfbfe5a8, ret_flags=0xbfbfe594, time_rec=0x0) at /usr/src/lib/libgssapi/gss_init_sec_context.c:156 #4 0x289936c9 in gssapi_client_mech_step (conn_context=0x28630160, params=0x28a97080, serverin=0x0, serverinlen=0, prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, oparams=0x28a95860) at gssapi.c:1418 #5 0x285810f6 in sasl_client_step (conn=0x28a95000, serverin=0x0, serverinlen=0, prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8) at client.c:655 #6 0x28580ef7 in sasl_client_start (conn=0x28a95000, mechlist=0x2861b360 GSSAPI DIGEST-MD5 CRAM-MD5 , prompt_need=0xbfbfe8b0, clientout=0xbfbfe8ac, clientoutlen=0xbfbfe8a8, mech=0xbfbfe8b8) at client.c:603 #7 0x2856a94c in imclient_authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so #8 0x28566f5e in XS_Cyrus__IMAP__authenticate () from /usr/local/lib/perl5/site_perl/5.10.1/mach/auto/Cyrus/IMAP/IMAP.so #9 0x281d8f30 in Perl_pp_entersub () at pp_hot.c:2888 #10 0x281878bc in Perl_runops_debug () at dump.c:1968 #11 0x280d80a9 in S_run_body (oldscope=1) at perl.c:2431 #12 0x280d7535 in perl_run (my_perl=0x28601100) at perl.c:2349 #13 0x08048930 in main (argc=6, argv=0xbfbfec44, env=0xbfbfec60) at perlmain.c:117 I'm complete GDB-idjit though so any help in getting usable information from the following trace would be appreciated - I have the dump etc. stored away for further digging of course. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD eats 169.254.x.x addressed packets
One final comment - I still don't understand why FreeBSD won't respond to pings when it has an address like 169.254.1.1. I can ssh to the unit but it won't respond to pings. I tried setting up a linux box with an address like 169.254.1.2 and it would respond to pings. Linux is not really any measuring stick in standard compliance... -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PF + BRIDGE still causes system freezing
Hmm, I wonder if possible culprit is this: Process 12 (intr) thread 0xff00022693e0 (100016) exclusive sleep mutex Giant (Giant) r = 1 (0x80c93dc0) locked @ /usr/src/sys/dev/usb/usb_transfer.c:3023 Is the usb device used as main harddrive for the system, and have you tried other usb device or installation target media like real harddrive or livecd? -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Results of BIND RFC
Strongly disagree. Or if it cannot, the base system needs to start using pkg_* (somehow) for use, and src.conf WITHOUT_xxx (where xxx = some software) removed. Concept being: I don't need Kerberos; pkg_delete base-krb5. I also don't need lib32; pkg_delete base-lib32. Beautiful concept, hard to implement due to libraries being yanked out from underneathe binaries that are linked to them. But you get the idea. This *might* be workable. However, in general - a large part of the reason why I use FreeBSD is that the FreeBSD base system gives me most of what I want, in *one* well defined chunk, *without* having to install a zillion extra packages, and without umpteen different versions of config files and locations for the important information. me +1 If I wanted to go Gnu/BSD (or Loonix) route, I'd already installed either thank you. Funny though that BIND which is pretty straightforward as configuration goes and as much essential system component as Sendmail is getting the axe. I thought one of the main philosophies in FreeBSD always was being a system in itself, rather than kernel with some haphazardly thrown in components added. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Results of BIND RFC
Based on the inspection of the source tree, I want my bikeshed mauve. I've not been had by AFD jokes in a while but Doug pulled this one off... -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
I use OS Linux on my hosting for web-servers, base for all servers is the same m/b S5000PAL ( SR1500), 2 quad kernel cpu Xeon E5320 or E5345, 8Gb RAM. I decided to install FreeBSD 6.2 i386 on one of the servers, To be a bit mor specific with my previous reply, in order to use SCHED_ULE you need to be running 7.x (which is quite stable already even being a beta. And of course with 64 bit hardware it's best to run amd64 version of the OS. -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 2 x quad-core system is slower that 2 x dual core on FreeBSD
On Sat, 01 Dec 2007 23:37:32 +0200, Alexey Vlasov [EMAIL PROTECTED] wrote: kernel: machine i386 cpu I686_CPU ident F1RNT1 options PAE One very probable culprit for slowness options SMP options SCHED_4BSD Using _ULE might yield a bit more performance as well # cat /etc/make.conf CPUTYPE?=nocona CFLAGS=-O2 -pipe I think the recommended practise is either use CFLAGS+=your flags or put the local compiler tweaks to COPTFALGS these days. Not sure if this affects performance tho' -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ARRRRGH! Guys, who's breaking -STABLE's GMIRROR code?!
From: Karl Denninger [EMAIL PROTECTED] To: freebsd-stable@freebsd.org Sent: Sunday, September 10, 2006 9:39 PM Yes it is, in the general case; in any event if you track RELENG_6_1 you will get no bug fixes in general - security related items to filter back down but in general bug reports posted against a -RELEASE are, if addressed, put into -STABLE. You would like untested fixes to hit the release version first? By the way, possible breakage of STABLE due MFC process was announced a good while ago... -Reko ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
