Re: telnetd broken in -CURRENT
On Wed, Jan 30, 2002 at 01:47:24PM +, Mark Murray wrote: No. We dont. But if Kerberos5 is asked for, then BSD telnet is linked against Heimdal. I'm testing the fix, and will commit in a day or two. OK, great. I assume you'll import it on the vendor branch? Yup! M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
This is looking good!
Please keep a close eye on style (there is at least one assignment in
an if () statement that needs to move out. :-)
M
--=-=-=
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
Umm, you can't use opiechallenge() for that. You're not supposed to
call opiechallenge() without also calling opieverify() (plus, I think
opiechallenge() consumes a challenge). Use opielookup() instead.
Even better, opie_haskey() (which is a wrapper around opielookup()).
New patch attached.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=pam_opieaccess.diff
Index: Makefile
===
RCS file: /home/ncvs/src/lib/libpam/modules/Makefile,v
retrieving revision 1.15
diff -u -r1.15 Makefile
--- Makefile 5 Dec 2001 15:55:14 - 1.15
+++ Makefile 21 Jan 2002 00:46:54 -
@@ -34,6 +34,7 @@
.endif
SUBDIR+= pam_nologin
SUBDIR+= pam_opie
+SUBDIR+= pam_opieaccess
SUBDIR+= pam_permit
SUBDIR+= pam_radius
SUBDIR+= pam_rootok
Index: pam_opie/pam_opie.8
===
RCS file: /home/ncvs/src/lib/libpam/modules/pam_opie/pam_opie.8,v
retrieving revision 1.4
diff -u -r1.4 pam_opie.8
--- pam_opie/pam_opie.8 14 Jul 2001 08:38:24 - 1.4
+++ pam_opie/pam_opie.8 21 Jan 2002 01:18:58 -
@@ -1,5 +1,13 @@
.\ Copyright (c) 2001 Mark R V Murray
.\ All rights reserved.
+.\ Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\ All rights reserved.
+.\
+.\ Portions of this software were developed for the FreeBSD Project by
+.\ ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\ Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\ (CBOSS), as part of the DARPA CHATS research program.
+.\
.\
.\ Redistribution and use in source and binary forms, with or without
.\ modification, are permitted provided that the following conditions
@@ -9,6 +17,9 @@
.\ 2. Redistributions in binary form must reproduce the above copyright
.\notice, this list of conditions and the following disclaimer in the
.\documentation and/or other materials provided with the distribution.
+.\ 3. The name of the author may not be used to endorse or promote
+.\products derived from this software without specific prior written
+.\permission.
.\
.\ THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
.\ ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
@@ -47,6 +58,13 @@
.Dq Li auth
feature.
It also provides a null function for session management.
+.Pp
+Note that this module does not enforce
+.Xr opieaccess 5
+checks.
+There is a separate module,
+.Xr pam_opieaccess 8 ,
+for this purpose.
.Ss OPIE Authentication Module
The OPIE authentication component
provides functions to verify the identity of a user
Index: pam_opieaccess/Makefile
===
RCS file: pam_opieaccess/Makefile
diff -N pam_opieaccess/Makefile
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/Makefile 21 Jan 2002 00:53:49 -
@@ -0,0 +1,10 @@
+# $FreeBSD$
+
+LIB= pam_opieaccess
+SHLIB_NAME= ${LIB}.so
+SRCS=${LIB}.c
+DPADD= ${LIBOPIE}
+LDADD= -lopie
+MAN= pam_opieaccess.8
+
+.include bsd.lib.mk
Index: pam_opieaccess/pam_opieaccess.8
===
RCS file: pam_opieaccess/pam_opieaccess.8
diff -N pam_opieaccess/pam_opieaccess.8
--- /dev/null 1 Jan 1970 00:00:00 -
+++ pam_opieaccess/pam_opieaccess.8 21 Jan 2002 13:07:06 -
@@ -0,0 +1,116 @@
+.\ Copyright (c) 2001 Mark R V Murray
+.\ All rights reserved.
+.\ Copyright (c) 2002 Networks Associates Technologies, Inc.
+.\ All rights reserved.
+.\
+.\ Portions of this software were developed for the FreeBSD Project by
+.\ ThinkSec AS and NAI Labs, the Security Research Division of Network
+.\ Associates, Inc. under DARPA/SPAWAR contract N66001-01-C-8035
+.\ (CBOSS), as part of the DARPA CHATS research program.
+.\
+.\
+.\ Redistribution and use in source and binary forms, with or without
+.\ modification, are permitted provided that the following conditions
+.\ are met:
+.\ 1. Redistributions of source code must retain the above copyright
+.\notice, this list of conditions and the following disclaimer.
+.\ 2. Redistributions in binary form must reproduce the above copyright
+.\notice, this list of conditions and the following disclaimer in the
+.\documentation and/or other materials provided with the distribution.
+.\ 3. The name of the author may not be used to endorse or promote
+.\products derived from this software without specific prior written
+.\permission
Re: Step5, pam_opie OPIE auth fix for review
On Mon, Jan 21, 2002 at 14:07:48 +0100, Dag-Erling Smorgrav wrote: Dag-Erling Smorgrav [EMAIL PROTECTED] writes: Umm, you can't use opiechallenge() for that. You're not supposed to call opiechallenge() without also calling opieverify() (plus, I think opiechallenge() consumes a challenge). Use opielookup() instead. Even better, opie_haskey() (which is a wrapper around opielookup()). New patch attached. Yes, this patch works as expected, but I doubt about opie_haskey() status. It looks like non-standard FreeBSD addition since it is in the local opieextra.c file and not in contrib/opie. If you care about machine independance, better use opielookup() directly. No, that is OK. :-) The FreeBSD PAM modules are all written from scratch as BSD PAM modules. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam_opie(8) prompt
Does anybody mind if I change the pam_opie(8) prompt from Password: to Response:? I think users might be slightly confused when they enter an incorrect or empty response twice and get a new Password: prompt and don't realize it's the pam_unix(8) prompt. Nope - that sounds good! M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step6, corresponding /etc/pam.d/* fixes for review
On Mon, Jan 21, 2002 at 16:33:57 +0100, Dag-Erling Smorgrav wrote: 1) there's no reason to have pam_opie commented out now, it won't do One reason still exist: all users (i.e. non-OPIE too) will see OTP responses when pam_opie will be uncommented. It may leads to confusion or wrong automated scripts processing. I have idea to solve it adding no_fake_prompts option to pam_opie to control that per admin choice. Yes. That would be a good move. :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: pam_opie(8) prompt
Andrey A. Chernov [EMAIL PROTECTED] writes: Yes, I see it too now. It is definitely some bug here. When I say in login I mean I test it through: The bug is quite simply that pam_opie(8) never sets the AUTHTOK item, so pam_unix(8) doesn't know that the user already entered a password. I believe pam_get_pass() should set PAM_AUTHTOK. Any objections? Not from me :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step6, corresponding /etc/pam.d/* fixes for review
Here are the (hopefully) final patches. Any final objections before I commit the lot? According to EyeBall Mk1, this is fine! :-) I haven't extensively tested the code, but the methods used and the design are very sound, I believe. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
Bug:
There is possible when pam_sm_acct_mgmt() called, password is not
expired, but due to some delay between calls (like network delays for NIS
passwords), expired at the moment of pam_sm_authenticate() check.
It is not pam_sm_authenticate()'s job to determine such things as expiry.
This is the business of pam_sm_acct_mgmt().
It may allow user to enter with expired password under some circumstanes
when he is not allowed to do it.
Do you mean that at at the very edge of password expiry, the user may
still be able log in (maybe some seconds later)? If so this is not a
credible threat.
Fix:
Use traditional Unix check (like found in pre-PAM ftpd.c and login.c) for
password expiration at the last moment, i.e. right after checking that it
is valid.
This fix is wrong for pam_sm_authenticate(), but valid for pam_sm_acct_mgmt().
pam_sm_acct_mgmt() already has something functionally equivalent.
M
--- pam_unix.c.bak1 Sun Jan 20 21:42:47 2002
+++ pam_unix.cSun Jan 20 21:58:45 2002
@@ -152,6 +152,8 @@
retval = strcmp(encrypted, pwd-pw_passwd) == 0 ?
PAM_SUCCESS : PAM_AUTH_ERR;
+ if (pwd-pw_expire time(NULL) = pwd-pw_expire)
+ retval = PAM_AUTH_ERR;
}
else {
--
Andrey A. Chernov
http://ache.pp.ru/
--
o Mark Murray
\_ FreeBSD Services Limited
O.\_Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
Bug: srandomdev() can't be used in libraries because it touch internal RNG state which may be used by user program which not want true randomness but pseudo one. Fix: srandomdev() removed, random() replaced by arc4random() which initialize itself from true randomness automatically. This works, but strikes me as overkill. This is salt, not cryptographic randomness, so 'srandom(junk)' is most likely better as a replacement for srandomdev() (where 'junk' can be time(), pid or anything similar). Salt's purpose is to make pre-computing a dictionary infeasable from the pure space perspective. M --- pam_unix.c.oldSat Jan 19 21:29:49 2002 +++ pam_unix.cSun Jan 20 21:42:47 2002 @@ -502,15 +502,14 @@ syslog(LOG_ERR, cannot set password cipher); login_close(lc); /* Salt suitable for anything */ - srandomdev(); gettimeofday(tv, 0); - to64(salt[0], random(), 3); + to64(salt[0], arc4random(), 3); to64(salt[3], tv.tv_usec, 3); to64(salt[6], tv.tv_sec, 2); - to64(salt[8], random(), 5); - to64(salt[13], random(), 5); - to64(salt[17], random(), 5); - to64(salt[22], random(), 5); + to64(salt[8], arc4random(), 5); + to64(salt[13], arc4random(), 5); + to64(salt[17], arc4random(), 5); + to64(salt[22], arc4random(), 5); salt[27] = '\0'; pwd-pw_passwd = crypt(pass, salt); @@ -596,15 +595,14 @@ syslog(LOG_ERR, cannot set password cipher); login_close(lc); /* Salt suitable for anything */ - srandomdev(); gettimeofday(tv, 0); - to64(salt[0], random(), 3); + to64(salt[0], arc4random(), 3); to64(salt[3], tv.tv_usec, 3); to64(salt[6], tv.tv_sec, 2); - to64(salt[8], random(), 5); - to64(salt[13], random(), 5); - to64(salt[17], random(), 5); - to64(salt[22], random(), 5); + to64(salt[8], arc4random(), 5); + to64(salt[13], arc4random(), 5); + to64(salt[17], arc4random(), 5); + to64(salt[22], arc4random(), 5); salt[27] = '\0'; if (suser_override) -- Andrey A. Chernov http://ache.pp.ru/ -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step3, pam_opie snprintf bloat fix for review
Bug: snprintf is large and slow, increasing program size and slowing it down. Better way is avoid snprintf when it is not neccessary. Fix: Full functionality of snprintf is not needed below, so it is replaced by much faster strlcpy. This is fine! Style - please make it 'sizeof(foo)', not 'sizeof foo'. M --- pam_opie.c.bakSat Jan 19 21:29:49 2002 +++ pam_opie.cSun Jan 20 22:23:18 2002 @@ -125,7 +125,7 @@ } /* We have to copy the response, because opieverify mucks with it. */ - snprintf(resp, sizeof resp, %s, response); + strlcpy(resp, response, sizeof resp); /* * Opieverify is supposed to return -1 only if an error occurs. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step2, pam_unix just expired pass fix for review
On Sun, Jan 20, 2002 at 19:47:55 +, Mark Murray wrote: Do you mean that at at the very edge of password expiry, the user may still be able log in (maybe some seconds later)? If so this is not a credible threat. Yes. Few seconds can be few hours or more in case network is down or something like, this mainly for network passwords like NIS. This is still not something that is pam_authenticate()'s business. If you believe that this is a problem, then the order and time in which these are done inside pam needs to be addressed, not by kluging pam modules. Perhaps the PAM-using applications need to be looked at as well to make sure they don't do anything silly. pam_authenticate() answers the question does the user have the correct credentials?. pam_acct_mgmt() answers the question OK - they are who they say they are. Are they allowed in _now_?. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
On Sun, Jan 20, 2002 at 19:55:31 +, Mark Murray wrote: This works, but strikes me as overkill. This is salt, not cryptographic randomness, so 'srandom(junk)' is most likely better as a replacement for srandomdev() (where 'junk' can be time(), pid or anything similar). You can't call srandom() from the libraries for the same purposes as srandomdev(), i.e. it damages user application current RNG state in the same way. Hmm. OK. Do you understand, though, why the salt does not need cryptographic randomness? Another patch of yours replaced sprintf with a faster strlcpy, but this uses the _much_ slower arc4random() which is not necessary IMO. How about just using pid's or something? The original crypt(3) salt quantised the time-of-day into 4096 pieces for the salt - how about doing something like that? UUEncode time()|pid()|getuid() might work just fine. I mean this: 1) User call srandom(3) 2) Library calls srandomdev() or srandom(123) Second step is effectively damages srandom(3) RNG state. -- Andrey A. Chernov http://ache.pp.ru/ -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step1, pam_unix srandomdev fix for review
Second step is effectively damages srandom(3) RNG state. Since the library is a totally encapsulated usage, it makes sense for it to save and restore state aroun its use of the functions, which would effectively allow concurrent use of the generator with other code that uses it. Other code that cares about the state should do the same. True but not trivial. I'd be happy to commit working patches :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
requiredpam_ssh.so no_warn try_first_pass auth requiredpam_unix.so no_warn try_first_pass nullok #authsufficient pam_rootok.so no_warn --- login.bak Sat Jan 19 21:29:49 2002 +++ login Mon Jan 21 00:39:04 2002 @@ -6,7 +6,7 @@ # auth auth requiredpam_nologin.so no_warn -#authsufficient pam_opie.so no_warn +#auth [defalt=ignore success=done cred_insufficient=die] pam_opie.so no_warn #authsufficient pam_kerberosIV.so no_warn try_first_pass #authsufficient pam_krb5.so no_warn try_first_pass #authrequiredpam_ssh.so no_warn try_first_pass --- ftpd.bak Sat Jan 19 21:29:49 2002 +++ ftpd Mon Jan 21 00:39:04 2002 @@ -9,10 +9,8 @@ #authsufficient pam_kerberosIV.so no_warn #authsufficient pam_krb5.so no_warn #auth sufficient pam_ssh.so no_warn try_first_pass -# Uncomment either pam_opie or pam_unix, but not both of them. -# pam_unix can't be simple chained with pam_opie, ftpd provides proper fallback -auth requiredpam_opie.so no_warn -#authrequiredpam_unix.so no_warn try_first_pass +#auth [defalt=ignore success=done cred_insufficient=die] pam_opie.so no_warn +auth requiredpam_unix.so no_warn try_first_pass # account #account requiredpam_kerberosIV.so -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:14:13 +, Mark Murray wrote: The PAM OPIE may only do OPIE authentication. It is entirely up to the PAM stack to decide what the login policy is. (Well, the PAM stack as specified by the pam configs in /etc/pam*) Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. Sure - but you are making specialised use of the return value that assumes that pam_opie will be followed by pam_unix. This violates the PAM spec. However - the module may pass on the authentication token (the password) and any following modules are allowed to use this if they find it. (look at the try_first_pass and use_fist_pass options). I was thinking about that way but not find a good solution. That way workatround is: 1) In the failure case when Unix (plaintext) passwords are disabled pam_opie can pass specially-generated incorrect password down to pam_unix. 2) pam_unix option must be changed from try_first_pass to use_first_pass, because it asks again for password if try_first_pass active, i.e. allows user to enter Unix (plaintext) password again. So we have the same bug, but shifted to one prompt step. You may be able to do something with options. Example: if the sysadmin allows a password to be passed down the stack, otherwise pass a dummy. (like ftpdauthrequiredpam_opie.so keep_password or similar) I have doubts about 1): what specially-generated incorrect password can be? It seems that any combination is legal and MAY be equal to real password. Nope. kill the password if it is not allowed. Pass a NULL. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
On Sun, Jan 20, 2002 at 23:44:44 +, Mark Murray wrote: Yes. And to allow PAM stack to make right decision, pam_opie pass special information to PAM stack. Look at the patch, pam_opie not breaks from the stack by yourself, it is /etc/pam* do that using information from pam_opie. Sure - but you are making specialised use of the return value that assumes that pam_opie will be followed by pam_unix. This violates the PAM spec. The alternative (yet one) way can be adding Unix (plaintext) password checking code directly to pam_opie. It makes pam_opie fully independent of other modules and specific position in the /etc/pam.d/* config files and allows us to not touch them. If you agree with that way, I'll come with the patch. No. I completely disagree with that method. that is pam_unix's job. DES's PAM_IGNORE suggestion has a lot of merit. About other points stated in your message, my answer depends on what you deside for above, because it is unneded to discuss them, if you agree to make pam_opie self-containing. It must be self-contained, and it must not do stuff that is the job of other modules. Unix password checking is not pam_opie's job. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: In any case, if I understand what you're trying to do, it can be done by returning PAM_SUCCESS if OPIE authentication succeeded, PAM_IGNORE if it failed but Unix authentication is still allowed, and PAM_AUTH_ERR if OPIE failed and Unix authentication is *not* allowed. In that case, if you mark pam_opie sufficient, pam_unix will run only if OPIE authentication failed but allowed Unix authentication to proceed. Hmm, actually, that won't do. I need to think this over some more. The usual route is YES or NO, with IGNORE reserved for modules which have no authentication (like say, pam_motd, which prints /etc/motd during the pam_session_open() phase). IGNORE may have other uses, but I can't remember them offhand. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Step5, pam_opie OPIE auth fix for review
sufficient will not works due to IGNORE assigned to AUTH_ERR reaction. [default=ignore success=done auth_err=die] works. Do you agree with this variant? Eeew. It may work, but it is really a last-ditch sort of thing. I much prefer an option that specifies the behaviour. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Question to PAM hackers
Is there a way (i.e. interface function) to check if particular PAM module loaded, inside application? No. Annd nor should there be. The authentication process with PAM means that the authentication policy (including which modules are loaded) are none of the applications damn business :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: *HEADS UP!* This means you!
I for one will miss it. I used libexec/telnetd extensively during ia64 bootstrap (and still use it) before we had the crypto stuff going. This was all built by hand, 'make world' still isn't an option there. I also use usr.bin/telnet on other systems where SRA is constantly getting in my face and annoying the !^@#%!@^#!# out of me. All that will happen, is that the usual sources will be gone, and a .PATH: will point to effectively the same code (with some crypto in it, wrapped in #ifdefs that won't apply, like ENCRYPTION and AUTHENTICATION). The code this actually compiled will not change _at_all_. There will be no SRA unless you install secure/ telnet. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
*HEADS UP!* This means you!
Hi Now that I have your attention, please listen up, this may have some far-reaching consequences. We currently have 2 telnet sources in the src/ tree; src/crypto/telnet and the base telnet spread around in (src/*/*telnet*/). The base telnet is a complete subset of src/crypto telnet, and as a consequence of this, I want to remove the base telnet bits from the src/ tree. (Just the source, not the build infrastructure). This will be accomplished by removing the base sources, and building telnet without defining the AUTHENTICATION and ENCRYPTION macros. These macros are currently used with unifdef to make (by hand) the base telnet stuff). I'm not sure when I'll make the commit, but it will be soonish, with due fanfare. Those of you who believe that you may be in trouble with your government by having crypto in your posession (as opposed to using it), please let me know ASAP! This will make src/crypto mandatory if you want telnet(d). This will _not_ make crypto _use_ mandatory. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cu(8) completely broken
Well, it would seem that the cu upgrade has totally hosed cu now: # cu -l /dev/cuaa1 -s 9600 usage: tip [-v] [-speed] [system-name] Can we get this fixed please? Yes. Import coming. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: building cvsup from ports
There is already a patch in PR ports/30899. It is OK to commit it IF you can test it first on a FreeBSD 4.x system (any architecture) and also a -current Alpha system. Cool! Thank you! M John Mark Murray wrote: John I have a patch (courtesy of Brian Somers) that fixes M3. I believe he has submitted it to you. May I/We commit it? M Hello all, Sounds like a silly place to post this but...here goes. I'm getting errors compiling cvsup from ports. The ports tree installed is the default coming with the 11/12/01 snapshot. I want would use CVS, but I don't know how (and yet I call my self a computer science student). It complains about nfs/nfs.h not existing (I checked, it doesn't). This is the first thing I have built from ports except X in -current, so all of the dependencies besides X were built with this port during make install. I remeber seeing this post on stable a while ago, but can't find the message for the life or me. The error is appended for amusment to those individuals who understand such things. regards, Galen Sampson # cd /usr/ports/net/cvsup # make install To build this port without X11 (and without the GUI), define WITHOUT_X11. === Extracting for cvsup-16.1e Checksum OK for cvsup-snap-16.1e.tar.gz. === cvsup-16.1e depends on file: /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 in /usr/ports/lang/pm3-forms === Extracting for pm3-forms-1.1.15 No MD5 checksum file. === pm3-forms-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 in /usr/ports/lang/pm3-gui === Extracting for pm3-gui-1.1.15 No MD5 checksum file. === pm3-gui-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7 in /usr/ports/lang/pm3-net === Extracting for pm3-net-1.1.15 No MD5 checksum file. === pm3-net-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3.so.7 in /usr/ports/lang/pm3-base === Installing for pm3-base-1.1.15 cd boot-FreeBSD4/m3core/FreeBSD4; gmake -f make.boot CC=cc CFLAGS=-O -pipe AS=as ASFLAGS= AR=ar ARFLAGS=rv RANLIB=touch EXTRALIBS=-lm LDFLAGS= gmake[1]: Entering directory `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4' cc -O -pipe-c -o RTHeapDepC.o RTHeapDepC.c RTHeapDepC.c:101: nfs/nfs.h: No such file or directory RTHeapDepC.c: In function `mount': RTHeapDepC.c:719: dereferencing pointer to incomplete type RTHeapDepC.c:719: dereferencing pointer to incomplete type RTHeapDepC.c:720: dereferencing pointer to incomplete type RTHeapDepC.c:720: dereferencing pointer to incomplete type RTHeapDepC.c:721: dereferencing pointer to incomplete type RTHeapDepC.c:721: dereferencing pointer to incomplete type gmake[1]: *** [RTHeapDepC.o] Error 1 gmake[1]: Leaving directory `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4' gmake: *** [boot] Error 2 *** Error code 2 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error
Re: make installworld failure in usr.bin/tip
Erm, it _is_ fixed in the makefile. If you have a better method, lets hear it. :-) Back out the entire tip commit? This would also restore all the FreeBSD changes clobbered by it. It doesn't even compile cleanly: Entirely different problem. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: make installworld failure in usr.bin/tip
Mark, Poul-Henning, So, what was the concensus? Should we fix this in Makefile, or just put this as an UPDATING entry and have users manually remove the old UUCP stuff? Erm, it _is_ fixed in the makefile. If you have a better method, lets hear it. :-) M On Sat, Nov 03, 2001 at 05:07:01PM +0100, Poul-Henning Kamp wrote: === usr.bin/tip install -c -s -o root -g wheel -m 555 tip /flat/syv/usr/bin /flat/syv/usr/bin/cu - /flat/syv/usr/bin/tip ln: /flat/syv/usr/bin/cu: Operation not permitted *** Error code 1 flat# ls -l /flat/syv/usr/bin/cu -r-sr-sr-x 1 uucp dialer 124384 Oct 21 13:04 /flat/syv/usr/bin/cu flat# /flat/src/usr.bin/tip flat# cvs log Makefile | less [...] total revisions: 10;selected revisions: 10 description: revision 1.7 date: 2001/10/30 21:22:08; author: markm; state: Exp; lines: +1 -1 Make the dirty, rotten hack failsafe and quiet if cu(1) does not exist. I'm sure there is a connection somewhere... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Ruslan ErmilovOracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED]FreeBSD committer, +380.652.512.251 Simferopol, Ukraine http://www.FreeBSD.orgThe Power To Serve http://www.oracle.com Enabling The Information Age -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: building cvsup from ports
John I have a patch (courtesy of Brian Somers) that fixes M3. I believe he has submitted it to you. May I/We commit it? M Hello all, Sounds like a silly place to post this but...here goes. I'm getting errors compiling cvsup from ports. The ports tree installed is the default coming with the 11/12/01 snapshot. I want would use CVS, but I don't know how (and yet I call my self a computer science student). It complains about nfs/nfs.h not existing (I checked, it doesn't). This is the first thing I have built from ports except X in -current, so all of the dependencies besides X were built with this port during make install. I remeber seeing this post on stable a while ago, but can't find the message for the life or me. The error is appended for amusment to those individuals who understand such things. regards, Galen Sampson # cd /usr/ports/net/cvsup # make install To build this port without X11 (and without the GUI), define WITHOUT_X11. === Extracting for cvsup-16.1e Checksum OK for cvsup-snap-16.1e.tar.gz. === cvsup-16.1e depends on file: /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3formsvbt.so.7 in /usr/ports/lang/pm3-forms === Extracting for pm3-forms-1.1.15 No MD5 checksum file. === pm3-forms-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3vbtkit.so.7 in /usr/ports/lang/pm3-gui === Extracting for pm3-gui-1.1.15 No MD5 checksum file. === pm3-gui-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3tcp.so.7 in /usr/ports/lang/pm3-net === Extracting for pm3-net-1.1.15 No MD5 checksum file. === pm3-net-1.1.15 depends on file: /usr/local/lib/m3/FreeBSD4/libm3.so.7 - not found ===Verifying install for /usr/local/lib/m3/FreeBSD4/libm3.so.7 in /usr/ports/lang/pm3-base === Installing for pm3-base-1.1.15 cd boot-FreeBSD4/m3core/FreeBSD4; gmake -f make.boot CC=cc CFLAGS=-O -pipe AS=as ASFLAGS= AR=ar ARFLAGS=rv RANLIB=touch EXTRALIBS=-lm LDFLAGS= gmake[1]: Entering directory `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4' cc -O -pipe-c -o RTHeapDepC.o RTHeapDepC.c RTHeapDepC.c:101: nfs/nfs.h: No such file or directory RTHeapDepC.c: In function `mount': RTHeapDepC.c:719: dereferencing pointer to incomplete type RTHeapDepC.c:719: dereferencing pointer to incomplete type RTHeapDepC.c:720: dereferencing pointer to incomplete type RTHeapDepC.c:720: dereferencing pointer to incomplete type RTHeapDepC.c:721: dereferencing pointer to incomplete type RTHeapDepC.c:721: dereferencing pointer to incomplete type gmake[1]: *** [RTHeapDepC.o] Error 1 gmake[1]: Leaving directory `/usr/ports/lang/pm3-base/work/pm3-1.1.15/boot-FreeBSD4/m3core/FreeBSD4' gmake: *** [boot] Error 2 *** Error code 2 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-base. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-net. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-gui. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/lang/pm3-forms. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. *** Error code 1 Stop in /usr/ports/net/cvsup. __ Do You Yahoo!? Find the one for you at Yahoo! Personals http://personals.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn
Re: Un-install upgrade application software
I have installed application software from port collection . How do I make un-install ? If I want to upgrade the existing application , how do I upgrade them ? Please advise Please ask this question on [EMAIL PROTECTED] M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Change Prompt
Hi Please ask these questions on [EMAIL PROTECTED] M Hi ; I use bash shell in my FreeBSD machine . How do I change a promt from $ to # when I login as superuser from normal user to root ? my .bashrc script looks as following . PS1=[\u@\h: \w]\$ alias ls='ls -F' alias cp='cp -i' alias mv='mv -i' alias rm='rm -i Another question , what is the function of PS2 and when to use it ? Please advise To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: It's baaack... -- (make: don't know how to make copies. Stop)
Mark, please back your 1.32 revision from share/examples/Makefile out, Done. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: It's baaack... -- (make: don't know how to make copies. Stop)
David Wolfskill wrote: Found this in my typescript after a make installworld on today's There was a commit about a problem with a missing NOOBJ.. May I suggest either: - rm -rf /usr/obj/* - cd src/share; cd `make -V .OBJDIR`; rm -rf * (check that its not your srcdir first :-). Actually, it is possible for there to be no copies: target in src/share/examples/something. The copies: (actually copies::) target is built up in a .for loop that may be empty. The fix is a dummy copies:: target. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fix for pam_nologin.so runtime error
Forgot to mention, I had to make kcheckpass setuid root to make kcheckpass itself work (just verified this on -stable). Yes - this is documented. :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: kerberos5/libexec/telnetd build fails in -current
Do you really need kerberos IV and Kerberos5? M === libexec/telnetd cc -O -pipe -DLINEMODE -DUSE_TERMIO -DDIAGNOSTICS -DOLD_ENVIRON -DENV_HACK -DAUTHENTICATION -DENCRYPTION -I/usr/src/kerberos5/libexec/telnetd/../../../crypto/telnet -DINET6 -Wall -I/usr/src/kerberos5/libexec/telnetd/../../include -I/usr/src/kerberos5/libexec/telnetd/../../include -DHAVE_CONFIG_H -DKRB5_KRB4_COMPAT -DKRB4 -DINET6 -o telnetd global.o slc.o state.o sys_term.o telnetd.o termstat.o utility.o authenc.o -lutil -ltermcap /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a -lmp -lcrypto -lcrypt -lpam /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x44): undefined reference to `kerberos4_init' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x48): undefined reference to `kerberos4_send' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x4c): undefined reference to `kerberos4_is' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x50): undefined reference to `kerberos4_reply' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x54): undefined reference to `kerberos4_status' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x58): undefined reference to `kerberos4_printsub' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x64): undefined reference to `kerberos4_init' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x68): undefined reference to `kerberos4_send' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x6c): undefined reference to `kerberos4_is' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x70): undefined reference to `kerberos4_reply' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x74): undefined reference to `kerberos4_status' /usr/obj/usr/src/kerberos5/libexec/telnetd/../../lib/libtelnet/libtelnet.a(auth.o)(.data+0x78): undefined reference to `kerberos4_printsub' *** Error code 1 Stop in /usr/src/kerberos5/libexec/telnetd. *** Error code 1 Stop in /usr/src/kerberos5/libexec. *** Error code 1 Stop in /usr/src/kerberos5. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Fix for pam_nologin.so runtime error
Should I file a PR? No. I have this :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rshd broken on -CURRENT
It seems that we dont have a /usr/lib/pam_rhosts_auth.so. Yes - I need to write one. M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic on mount
After compiling a new kernel, installing it, when my laptop tries to mount its drive, it panics with this message: panic: lock (sleep mutex) vnode interlock not locked @ ../../../kern/vfs_default.c:460 which is: if (ap-a_flags LK_INTERLOCK) mtx_unlock(ap-a_vp-v_interlock); I get exactly the same thing. Manual bactrace is: panic witness_unlock _mtx_unlock_flags vop_nolock vop_defaultop vn_lock ffs_mountfs ffs_mount vfs_mountroot_try vfs_mountroot mi_startup begin M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rexecd broken(?) on -current
Hi Mark, Hi I tried to use rexecd on my -current environment, but it failed. If OPIE is defined, opiechallenge() is called to configure opiedata structue, but this structure is filled with 0 because I don't use one-time password. I think it should fallback to call crypt() or so if opiechallenge() is failed. I don't know how it should work with OPIE. Could you please fixing this, Mark? Sure! I've never used rexecd, su could you please suggest a minimalist test/command that I could use, and I'll get right to it. :-) M -- o Mark Murray \_ FreeBSD Services Limited O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI breakage on Libretto 110CT with CURRENT
/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 pmtimer0 on isa0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources ata0: Generic ESDI/IDE/ATA controller at port 0x1f0-0x1f7,0x3f6 irq 14 on isa0 sio0: 16550A-compatible COM port at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A unknown: PNP0401 can't assign resources pcic0: Intel i82365SL-A/B at port 0x3e0-0x3e1 on isa0 pcic0: Polling mode pccard0: PC Card bus (classic) on pcic0 pccard1: PC Card bus (classic) on pcic0 ad0: 19077MB TOSHIBA MK2016GAP [38760/16/63] at ata0-master BIOSPIO Mounting root from ufs:/dev/ad0s2a pccard: card inserted, slot 0 reset 1 int is 0 stat is ff pccard: card inserted, slot 1 reset 1 int is 0 stat is ff reset 2 int is 60 stat is ef reset 2 int is 60 stat is cf reset 3 int is 60 stat is ef reset 3 int is 60 stat is ef sio1 at port 0x2f8-0x2ff irq 3 slot 0 on pccard0 sio1: type 16550A M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
ACPI breakage on Libretto 110CT with CURRENT
Hi ACPI breaks my Libretto with (typed by hand): Mounting root from ufs/dev/ad0s2a setrootbyname failed ffs_mountroot: can't find rootvp Root mount failed: 6 Manual root filesystem specification: fstype:device BLAHBLAHBLAH... mountroot enter (PANIC - no root fs (no help if I type the correct root FS)) If I undef acpi_load at boot, the system boots fine. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libss termination
As far as I can tell, there's nothing in the tree which uses libss any longer, and hasnt been for quite some time. Is there any reason to keep it? Nope. Right. Kill it. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: help! su(1) is still broken
There is a recen-ish fix that may sort this out. Re-sup and build again... M I cvsupped earlier in the week (august 9th) for the first time in about 3 weeks. The pam changes seem to have broken su on my machine. I'm using the default pam.conf (via mergemaster), so I would assume that it should work. I can't seem to tweak it into behaving. I searched the list, but moving libpam to /compat/lib didn't work for me. The best clue so far is the contents of my security log (I turned on debugging). pam_wheel seems to be working, but pam_unix blows in completely: Aug 16 12:06:07 su: pam_unix: pam_sm_authenticate: Options processed Aug 16 12:06:07 su: pam_unix: pam_sm_authenticate: Got user: toor Aug 16 12:06:07 su: pam_unix: pam_sm_authenticate: Doing real authentication Aug 16 12:06:10 pam_unix: pam_sm_authenticate: Got password Aug 16 12:06:10 su: pam_unix: pam_sm_authenticate: Encrypted passwords are: **NuIxEpaVQeE * Aug 16 12:06:10 su: pam_unix: pam_sm_authenticate: returning PAM_AUTH_ERR I trimmed the lines a little. The thing that makes no sense here is that I'm using md5 passwords. When I login as toor on the console, pam_unix does the right thing. So perhaps it some sort of bizarre crypto problem. I really don't know where to go next, or what to zap and re-build, so any suggestions would be greatly appreciated. -- Robert Sexton, [EMAIL PROTECTED] No one told me that it could not be done, and so I did it. - Jack Kloepfer To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Big telnet commit coming!
Hi all I have a big commit planned for telnet(d). You can see it at http://people.freebsd.org/~markm/patches/diff.cvs.gz The main aims of the patch are to reduce the number of warnings telnet(d) emits during compilation, and to properly merge the differences between the base telnet and the crypto telnet in src/crypto/telnet. a very small amount of style(9) work has been done. In the future, I aim to have the base telnet generated entirely by unifdef(1)'ing the crypto one. This commit does not achieve that goal, and nor does it intend to - there are some other fixes that will come at a later stage. I have already asked for reviews on -audit. Those who are looking at my patches should download again, because I have done some further fixes and improvements. I'll commit in three days from the date of this email if nothing comes up. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rlogin terminal settings messed up
Does anyone know what changed? (someone has suggested the change came about when PAM's session model was changed) Following up on my previous message; I've asked re@ for permission to MFC the fix. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rlogin terminal settings messed up
For quite a while now (?3-4 months?) one's terminal settings are messed up when rlogin'ing into a FreeBSD from a FreeBSD-current one. It used to be I could rlogin from an 80x24 Xterm, and the terminal settings on the remote box would also be 80x24. Now COLUMNS=80 and ROWS and TERMCAP isn't set, so a very large number is assumed. Does anyone know what changed? Hmm. rlogind(8) on STABLE and CURRENT is effectively identical, and the bug does not show on a CURRENT-CURRENT rlogin session. (someone has suggested the change came about when PAM's session model was changed) Hmm. Maybe I need to MFC login(1) some more. Please try that, and if it works, lets get it committed. STABLE's PAM modules and support are quite a bit behind CURRENT's. What are your /etc/pam.conf entries for login? See if borrowing any CURRENT entries helps you. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntpd 4.1
According to Mark Murray: Can you make it so that if NO_OPENSSL is not defined, then openssl is used? I could of course but I don't think that having PUBKEYS by defaults (X.509 based, not the PGP ones) is probably not very useful yet as it is a fairly recent option. AUTOKEY should be enough. Any objection? No objection from me :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ntpd 4.1
Now that ntpd 4.1.0 has been released (finally!), I'll upgrade current very soon. :-) :-) :-) The question I have is the following: authentication was done with md5 code builtin and I disabled DES support (not supported anymore). Now, with 4.1, it can be linked to openssl but it is still an optional component. I'm a bit reluctant to force openssl for just ntpd. Can you make it so that if NO_OPENSSL is not defined, then openssl is used? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: su root broken in -CURRENT
I have the PR, and I will fix this :-) M On Tue, 31 Jul 2001, Terry Lambert wrote: The reason for this is that the pam code for doing the enforcement is being trusted utterly. In the past, we would consider both the primary group (the group from the passwd file entry), and the auxillary groups (the groups from the groups file entries, if any), as synonymous. With the pam code being used, we no longer consider the primary group to be on the same par as the groups file entries. I can pin this down at r1.26 of su.c (Mon May 25 03:34:52 1998 UTC (3 years, 2 months ago) by steve) Prior to this date only appearance in /etc/group was considered. The change occurred in response to PR bin/6696 Like terry, I prefer the semantics whereby the users primary group is considered. Three years of precedent should be sufficient to have this change to pam_wheel.c, I hope, before PAM use in su is MFC'd. I have just entered a PR on this. cc'd to: markm Joshua -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: cvs commit: src/lib/libpam Makefile.inc
At Thu, 12 Jul 2001 15:26:58 +0900, I wrote: Actually this doesn't help libpam.so.1, because the new pam modules (pam_*.so) do not work with it. Which means you need to recompile the programs linked with it, such as sudo, xdm, and the X server. Xwrapper I'm not sure I follow you here... M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP!! S/Key is ancient, OPIE is new
Why? Better way will be rewritting ports to use good-new OPIE. wi-ftpd already have OPIE hooks, but I not sure they works. Popper needs modifications. Doesn't know, if other ports using Skey exists. I can do base software, but I haven't time to fill all ports. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: convert libgmp to a port?
No, I'm saying that the author of the SRA patches did the right thing and used the traditional BSD math library when extending the traditional BSD telnet utility. I am furthermore making the point that FreeBSD should continue to ship with a library that provides the `libmp' interface, regardless of how it is implemented internally. Strongly disagree. The libmp interface is not very fault-tolerant, and not well used (anymore). The bignum (BN) bits of libcrypto are much more fault tolerant and ubiquitous. Time to throw out the trash. The its traditionally part of BSD argument holds no water - the BSD books that I have point to MH and Emacs in the same way. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM causes segfault in login(1)
I've noticed that new PAM segfaults when I'm typing non-existing login at console login prompt. Please fix. This current, right? I'll sort it out. Thanks for the debug-sleuthing! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAM forgets to unblock signals [was Terminal line discipline is broken [sorta]]
That explains... Attached patch solved the problem for me. I have a functionally similar but less clean patch in BDE's court for testing. Thanks for letting me know this works - I'll commit it. M Content-Type: text/plain; charset=koi8-r; name=misc_conv.c.diff Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=misc_conv.c.diff -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: nss_ldap and pam_ldap ?
Is there any plan to port pam_ldap ( and nss_ldap ) to FreeBSD-CURRENT ? No plans, but if you submit something, I would be interested. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP! Breakage in Perl/BSDPAN
Hi
Those who made a buildworld without NO_PERL=true with sources
newer than Tue, 1 May 2001 02:25:25 -0700 (PDT), but older than
2001/05/02 14:18:33 PDT, must apply the following patch as root in
/usr/libdata/perl/BSDPAN directory.
(If you are tracking CURRENT, then CVSup and/or cvs update after this
message will get you the same fix.)
A patch: (by Anton Berezin [EMAIL PROTECTED])
diff -u -ru /usr/src/gnu/usr.bin/perl/BSDPAN/BSDPAN/Override.pm ./BSDPAN/Override.pm
--- /usr/src/gnu/usr.bin/perl/BSDPAN/BSDPAN/Override.pm Tue May 1 11:25:24 2001
+++ ./BSDPAN/Override.pmWed May 2 20:38:12 2001
@@ -13,9 +13,8 @@
#
use strict;
use Carp;
+use BSDPAN;
require Exporter;
-require SelfLoader;# XXX 2nd-order magic over SelfLoader's magic :-)
-# require AutoLoader; # XXX do we need to do similar hoop-la with it?
use vars qw(@ISA @EXPORT);
@ISA = qw(Exporter);
@@ -77,8 +76,11 @@
# do we need to protect against SelfLoader?
my $sl_autoload = eval *$pkg\::AUTOLOAD{CODE};
- $sl_autoload = 0
- if $sl_autoload $sl_autoload != \SelfLoader::AUTOLOAD;
+ if ($sl_autoload) {
+ require SelfLoader;
+ $sl_autoload = 0
+ if $sl_autoload != \SelfLoader::AUTOLOAD;
+ }
# get the reference to the original sub
my $name_addr = eval *$name\{CODE};
diff -u -ru /usr/src/gnu/usr.bin/perl/BSDPAN/BSDPAN.pm ./BSDPAN.pm
--- /usr/src/gnu/usr.bin/perl/BSDPAN/BSDPAN.pm Tue May 1 11:25:23 2001
+++ ./BSDPAN.pm Wed May 2 20:39:39 2001
@@ -11,7 +11,6 @@
#
# The pod documentation for this module is at the end of this file.
#
-use Config;
my $bsdpan_path; # Directory pathname of BSDPAN itself
@@ -34,19 +33,22 @@
}
sub perl_version {
- return $Config{version};
+ require Config;
+ return $Config::Config{version};
}
sub perl_ver {
+ require Config;
# pre-5.6.0 perls
- return $Config{apiversion} if exists $Config{apiversion};
+ return $Config::Config{apiversion} if exists $Config::Config{apiversion};
# post-5.6.0 perls
- return $Config{version};
+ return $Config::Config{version};
}
sub perl_arch {
+ require Config;
# pre-5.6.0 perls
- return $Config{archname} if exists $Config{apiversion};
+ return $Config::Config{archname} if exists $Config::Config{apiversion};
# post-5.6.0 perls
return 'mach';
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PAMmed su still broken for passwordless accounts
1) su on passwordless accounts. (a) `su passwordless' now bogusly prompts for a password. It lets you in if you type an empty password. (b) `echo somecommand | su passwordless' now bogusly prompts for a password. su doesn't find a password, and exits without printing anything or running `somecommand'. I use the latter form a lot. Feature, not bug. PAM has been told to use unix authentication. You can override this by setting su authrequiredpam_permit.so instead of su authrequiredpam_unix.so try_first_pass in /etc/pam.conf. For situations where some accounts have passwords and some don't, play with the third word - required may become sufficient etc. (2) static linkage of rshd. Previously, only static linkage of many other commands that are linked to libpam was broken (ftpd was one). Those patches of yours look reasonable. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: PAMmed su still broken for passwordless accounts
Feature, not bug. PAM has been told to use unix authentication.
The bug turns out to be that PAM shouldn't have been told this. The
non-PAM case uses the following check to avoid checking for passwords
on passwordless accounts:
---
/* if target requires a password, verify it */
if (*pwd-pw_passwd) {
---
but the PAM case always calls pam_authenticate() (for non-root).
Right. To avoid a pam/other turf fight. I'll do the above until we
can fix the pams to allow a 'if no password, let him in' mode for
the pam_unix module.
The first form is equivalent to making all accounts passwordless. I don't
see how changing the third word could affect this.
Er, yes :-)
The pam modules need a mode for this. I'll do that.
login(1) uses the same configuration as su(1) in pam.conf but handles
passwordless accounts correctly. In login.c, most of the complications
for PAM authorization are in the auth_pam() function, and goto
ttycheck; skips over all types of authorization when there is no
password. The corresponding code in su.c is a tangle of ifdefs and
large inline code for PAM authorization.
I need to take out some of that #ifdef hell. For one, KERBEROS is no
longer needed. (fixed locally). WHEELSU needs to be properly documented.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: broken sshd or libssl ?
I update 4.3 RC to 5.0-CURRENT and have some troubles. Why make buildworld build system without RSA support ? And how i can correct this problem ? System cvsuped today. Go to /dev and remake all your devices. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i586 FP optimizations hosed.
Hi I have an SMP kernel with I586 and I686 support. If I boot it on a 686 it works. On a 586 it craps out with CPU1 stopping CPUs: 0x0001... Stopped. Stopped at i586_bzero_oops+0x1:jmp i586_bzero_oops late into the boot (during network/RPC init stuff). I thought the 586 FP stuff was disabled? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: random woes (no RSA support in libssl and libcrypto)
See src/UPDATING 2624 Well, but it says about `options RANDOMDEV'. Later, `device random' was invented instead of it. A few days ago I installed -CURRENT (date=2001.03.25.12.00.00) with removing all previous content of /usr/lib (which contained legacy since 3.1-RELEASE) and /usr/sbin/sshd began to refuse supporting protocol 1 with identical message (`no RSA support in libssl and libcrypto. See ssl(8)'). Also, kernel was build with `device random', and netch@iv:/usr/HEAD/src/sys/i386/confegrep '(RSA|USA)' /etc/make.conf # If you're resident in the USA, this will help various ports to determine USA_RESIDENT= NO WITH_RSA=YES You missed (and deleted) the bit where it tells you to rerun MAKEDEV to rebuild your devices. And, my questions are 1) What can happen to refuse RSA support in libcrypto, with environment described above? An incorrect /dev/urandom 2) How can one diagnose reason of such problems without abusing studying of libcrypto internals? More reading of UPDATING? I'll see if I can get it clarified. 3) Can anybody provide more descriptive message when random device works improperly? Yes. I'm working on making the random device itself moan at you. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP!! New PAM functionaity in CURRENT!
Hello all! I have just added new PAM functionality to CURRENT. There is now better support for account management and sessions. If you foul up your pam.conf merging, you may not be able to get into your system. PLEASE MERGE /etc/pam.conf WITH CARE! At the least, your login section should look like: login authrequiredpam_unix.so try_first_pass login account requiredpam_unix.so login password required pam_permit.so login session requiredpam_permit.so and your sshd section should look like: sshdauthrequiredpam_unix.so try_first_pass sshdaccount requiredpam_unix.so sshdpassword required pam_permit.so sshdsession requiredpam_permit.so M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whatever happened to CTM?
Anyway: If CTM was to ever be given up (it's good to read, that Ulf will get his CTM box connected again, soon), then there should be a alternate access method, that works through tightly configured firewalls. And CVsup via SSL might be a good candidate ... Hmm. Look at sslproxy and sslwrap in the ports. They may just work for you. It shouldn't be too difficult to set up the other side - after all, there is a need :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Whatever happened to CTM?
Just an idea: How about a CVSUP via HTTPS server (just as a means to tunnel CVSUP through a HTTPS proxy ...) ? Most probably a CVSUP daemon bound to port 443 would do (there are programs that tunnel arbitrary data through a HTTPS proxy, though I admit this is cheating ;-) You should be able to do it with SSH (assuming that you can get out with ssh!) $ ssh -v -l yourname otherhost.example.com -L5559:cvsup.example.com:5559 Then doing a cvsup with the server set to 127.0.0.1 will work. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvsup/cvsupfile question
Using cvsup to catch up to changes for 4.2-Stable, we ended up with 4.3-Beta. We used cvsup Nov-December, with (I thought) the attached cvsup file, to keep 4.2-Stable current. We ran cvsup yesterday. After `buildworld`, `buildkernel`, `uname` says: FreeBSD [host] 4.3-BETA FreeBSD 4.3-BETA #0: Wed Mar 21 previous build `uname` says: FreeBSD [host] 4.2-STABLE FreeBSD 4.2-STABLE #1: Wed Dec 6 Where'd we go wrong? Nowhere. Can it be put right? It is right. This "BETA" (not to be confused with an unstable commercial "beta") is simply "STABLE" with a tag on it to indicate that it is going through the release engineering process to become 4.3-RELEASE (and then 4.3-STABLE). You have something that is stable, and is just close to the next release. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: random woes (no RSA support in libssl and libcrypto)
It seems the compatibility with the previous minor of urandom has been silently removed (I assume this happened with the last update/cleanup of the random device). It took me two hours to figure it out. See src/UPDATING 2624 M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
In addition to reported earlier general machine slowdown with interrupt harvesting is turning on, ethernet entropy harvesting seriously hammers network performance as well. Ftping big file over my 10M network now about 15% slower with ethernet harvesting turning on. Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? Mark, please get slow machine (say 100MHz or slower) and test you fu^H^Hboring harvester on it before committing anything. The whole devrandom affair gone too far and shown exactly how things should not be developed in FreeBSD. I've done this. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Even with the Rijndael code and kern.random.sys.burst=$SMALLNUMBER ?? Rijndael stops it showing up much in top -S. I'm wondering where it is hiding :-). kern.random.sys.burst=$SMALLNUMBER had very little effect. The Rijndael code makes a 2-orders-of-magnitude difference to the speed of the Davies-Meyer hash in hash.c. In order for the random kthread to show me numbers (I got paranoid when it didn't seem to show up), I slowed it down by looping the hashing "guts" 100 times :). This very clearly shows the superior key agility of Rijndael over Blowfish. Now kern.random.sys.burst is still available for those very slow, very high interrupt cases. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Please try this patch. This should solve all the random harvesting
performance issues no matter how efficient or inefficient the hash
function (untested as I do not have a -current box at the moment).
Erm, you are behind :-)
I have already committed something that does this in a much more
configurable way.
M
-Matt
Index: yarrow.c
===
RCS file: /home/ncvs/src/sys/dev/random/yarrow.c,v
retrieving revision 1.31
diff -u -r1.31 yarrow.c
--- yarrow.c 2001/02/11 16:21:35 1.31
+++ yarrow.c 2001/03/12 19:09:15
@@ -104,11 +104,8 @@
for (;;) {
- if (harvestring.tail == harvestring.head)
- tsleep(harvestring, PUSER, "rndslp", hz/10);
-
- else {
-
+ tsleep(harvestring, PUSER, "rndslp", hz/10);
+ if (harvestring.tail != harvestring.head) {
/* Suck the harvested entropy out of the queue and hash
* it into the appropriate pool.
*/
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Mark, something like this doesn't REQUIRE any configuration!!! Don't add confusion to the system. Just make the default something reasonable. There is absolutely no reason to have to be able to adjust the interrupt seeding code if the default is made something reasonable. Matt, At it is very obvious to me that you have not even looked at the new code, let alone run it, I suggest that you do both before further engaging in this conversation. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
I don't understand what is so difficult about simply rate-limiting the code at the proper point -- at the very beginning of the call that the interrupt harvester makes, removing most of the fixed overhead for the case where a system is getting a large number of interrupts per second? Why are you going through loops to create complex, sensitive code paths when a simple solution can be plopped down and will work, SNAP, just like that? Because I need to make folks other than you happy. Lots of security minded people what _all_ the interrupt entropy they can get, and this method gives them that while allowing others to throttle the harvester back. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Ethernet entropy harvesting seriously pessimizes performance
Let me be clear about what I mean by interrupt rate limiting:
interrupt()
{
harvester(...)
}
It does that already.
harvester(...)
{
if (queue is not full) {
... add data to queue (reasonably sized queue, like 32 entries)
}
}
It does that. I guess we differ on the idea of "reasonable".
queue-runner(...)
{
for(;;) {
sleep for 1/10 second
Pull next item (if any) off queue
}
}
It almost does that, except it sleeps every N items where the user
is given control of N.
That is what my patch does. If a high rate of interrupts occur, the
queue becomes full almost instantly because the queue-runner only
pulls one item off per 1/10 second. The result is that the
harvester() routine effectively becomes a NOP for most of the
interrupts.
My code does that. Do a "cat /dev/zero /dev/random"
to see it in action.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: New improved panic!
0xc0147290 is in random_kthread (../../dev/random/yarrow.c:97).
92 mtx_lock(Giant);
93 printf("OWNERSHIP Giant == %d sched_lock == %d\n",
94 mtx_owned(Giant), mtx_owned(sched_lock));
95 mtx_unlock(Giant);
96 #endif
97
98 for (pl = 0; pl 2; pl++)
99 yarrow_hash_init(random_state.pool[pl].hash, NULL, 0);
100
101 for (;;) {
Is DEBUG defined?
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Entropy harvesting? Grim reaper is more like it...
I changed nothing from whatever the default is. It seems like a bit of POLA to freeze now. But I'll check this - if I can get that machine up again :-)... OK - if this is the entropy driver, then typing about 2 lines of shit will unlock it. Please put some echo's into the rc scripts to tie down where this is happening. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Just installed new world, rebuild kernel, ran mergemaster and after reboot discovered that the system slowed down 4-5 times. Turning harvest_interrupt=NO in /etc/rc.conf solved the problem. The system in question is Toshiba Satellite Pro 445 notebook, see dmesg and kernel config attached with this message. Please investigate and fix what is necessary. In the meantime I would suggest turning harvest_interrupt=NO in default rc.conf, as it may hurt others as well. Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. Please set maxusers to 128, and time a make world with interrupt harvesting on, and again with it off. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Apart from a ridiculously low maxusers (you have 10, I recommend 128), I'm not sure what the problem is. I do not see why it is "ridiculously low". Even GENERIC recommends 32, while this is a small system intended to be used by only one person, so I do not see any problem with it. I never had any `out of descriptors' or `can't fork' during my routine operations on this box (2.5 years). Ok - then please leave it at 32. Please set maxusers to 128, and time a make world with interrupt harvesting on, and again with it off. I do not see what it will buy you. Could you please just believe my opinion based on the boot time? After all, even when this box unslowed make world takes 4-5 hours to complete, so with this slowdown it would take about 20-30, which I certainly can't tolerate without sufficient reason. If you want me to help you, please help me get good info. It's very important to me _know_ wether this is a boot slowdown or a generic - assertions are not good enough, I need hard facts. My own laptop (A Toshiba Libretto 110CT) does a make world in about 8 hours (and it always has). Interrupt harvesting has not made a noticable difference (I have not been keeping records, but an overnight build has not yet progressed into my breakfast). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
Just do something that causes a lot of interrupts that go through the random harvester. E.g.: dd if=/dev/ad0 of=/dev/null causes 7750 interrupts/sec here (on a Celeron 366 overclocked to 522). The random task takes 100% of the available cpu cycles. This slows down cpu-bound processes by a factor of about 3.5. With a block size of 64k instead of the default of 512, this causes only 300 interrupts/sec. The random task takes a measly 27% of the cpu to process these. It can apparently only handle about 10 interrupts/second with a reasonable overhead (1%). OK. Try tweaking the "Computational intensity factor" ;-) by dropping the kern.random.yarrow.bins: # sysctl -w kern.random.yarrow.bins=2 And let me know how well that works. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
I think it would be a much better idea to cap the number of interrupts per second the reseeder accepts. e.g. have a sysctl to set the max and default it to something reasonable, like 200. The seeder would thus only run 200 times a second even if A person were getting 7750 interrupts/sec. Frankly, once we have a good random seed it would only take about 10 interrupts a second to keep the random number generator in good shape, and possibly even less. Overkill is not necessary. This effectively happens. The harvest ring is a limited length, and any overflows are discarded. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: harvest_interrupt=YES slows down machine
1) Reduce the ring size to something reasonable. 1024 is massive overkill. 32 would be just fine. I'll play with this. 2) Add a mandatory tsleep in random_kthread() for EACH entry scanned from the harvest ring. Something reasonable like 1/10 second (similar to what you do if the harvest ring is empty. Or may you could pull off 5 entries at a time and then sleep. Right now you run it in a tight loop until the ring is completely empty. Hmm. Sounds doable. I'll play. A 1/10 second sleep and a ring limit of 32 still gives you an effective 320 seeds per second. Still overkill, but at least not the massive overkill that its doing now. Event != seed. I'll juggle numbers and see if I can come up with any tweakables (sysctl's) that could give users more control here. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Can't build 5-current world on 4-stable box (perl doesn't bootstrap properly)
I reported it about a month ago, but the problem still persists. 5-current buildworld can't be performed on reasonably recent 4-stable system, hence source upgrade path from -stable to -current is broken. Please fix. I just did this on 4-STABLE with no problems at all. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Major bumping of libFOO
Please review this patch as I'd like to commit it soon. Also, I'm not 100% sure what to do about libdes.so.3, so if you have commments on that please let me know. Other than that, the patches should be close to commitable. Now is the time to toss that into compat/ M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel Panic from Yesterday's CVSup
John Baldwin said: On 06-Feb-01 Andrea Campi wrote: Sorry to bother everybody, but did anybody note from my panic trace, that instruction pointer is 0xdeadc0de? Isn't that bad? :-p That means it is free'd memory. One cause might be something that is free'ing its interrupt handler w/o releasing it properly. Alternatively, it might be a race in the interrupt list code that was been brought about by preemption. Since locks are rather expensive, we have avoided locking the list of interrupt handlers in the past, but we may have to break down and do that now. :( This will hurt interrupt latency unless I can figure out a slick way of fixing it. Can anyone confirm that a pre-preemption kernel works fine for them? I have 2 SMP boxes (one with pentium 200MMX's, the other with PPro 233's. There are other differences in peripherals). Both boxes run an identical build of a kernel dating to sun 4th feb. The PPro is rock-stable. The PentiumMMX is very fragile, and will panic easily (often in vm_fault) with a sig9 (IIRC). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Kernel hackers, please review.
Hi Please review the patch at http://people.freebsd.org/~markm/no_lock_h.diff. the idea is to remove sys/*/include/lock.h. I tested it with the usual i386 stuff, and it is known to break the cy driver because of the COM_(UN)LOCK macros (which is another issue). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kernel threading: the first steps [patch]
This is the single most flagrant lack of cooperation I have experienced while working with the FreeBSD Project. I'm truly dumbfounded. It's not a lack of co-operation.. it's a lack of communication. I didn't see an any lists that anyone was doing this yet and thought I'd get the ball rolling to promote discussion.. I'm dumfounded to discover that you've done work here already as I thought I'd have heard of it. I'm sad you take it as an insult. All I want is to start discussion, and I was doing it as a way of clarifying my thoughts as to what wqas needed. Um, Julian - I have known about this for a good couple of months. I can't remember specifically _how_ I know; suffice to say there has been a fair bit of dialogue on the lists and Jason's progress-page has a good overview. http://people.freebsd.org/~jasone/smp/ M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld failed and PERL_THREADED=true dead...
Hi I see no perl failure below... M Hello. I tried make buildworld after cvsuped my source and it failed in perl area. I remove PERL_THREADED=true and tried again and it failed. === usr.bin/kdump cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/../ktrace/subr.c gzip -cn /usr/src/usr.bin/kdump/kdump.1 kdump.1.gz cc -O -pipe -march=pentium -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:99: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the location of the previous definition In file included from ioctl.c:51: /usr/obj/usr/src/i386/usr/include/machine/i4b_rbch_ioctl.h:45: `TELNO_MAX' undeclared here (not in a function) ioctl.c: In function `ioctlname': ioctl.c:693: invalid use of `restrict' ioctl.c:693: sizeof applied to an incomplete type *** Error code 1 1 error *** Error code 2 FreeBSD 5.0-CURRENT #0: Sat Jan 13 22:57:43 MSK 2001 Any idea? -- Rgdz,/"\ Sergey Osokin aka oZZ, \ / ASCII RIBBON CAMPAIGN [EMAIL PROTECTED]X AGAINST HTML MAIL http://freebsd.org.ru/~osa/ / \ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syslogd(8) does not update hostname
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: syslogd(8) does not update hostname
On Sat, Jan 20, 2001 at 11:24:16AM +0200, Mark Murray wrote: I don't agree with this change. hostname != name-that-IP-address-resolves-to. Dunno what you are talking about. That has nothing directly to do with this. No one is talking about forcing you to change your hostname. The patch just allows syslogd(8) to take note if the hostname were to change. D'uh. Bad crack I'm on. :-) M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: current hangs...
on a 2xPII/350, 256M, two scsi disks on ahc, and ccd I have three times now hung the machine so that only reset got any attention simply by make -j 128 world Do you have an easy way to narrow it down to CCD by doing the same thing but without ccd involvement? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. Please tell me if sysctl -w kern.random.yarrow.bins=2 makes a difference for you. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: pcm status
OK, please try this, then; change the HARVEST_RING_SIZE in sys/dev/random/yarrow.h to a smaller power-of-2 (256 or 128 would be good), and let me know how that helps-or-not. Thanks! M If it helps at all, it's marginal. I still get skips. On Sat, Jan 20, 2001 at 05:36:08PM +0200, Mark Murray wrote: This is directly traceable to entropy harvesting by /dev/*random. I know it's not an option if you need to use ssh, but not loading random.ko will fix the sound problems when moving the mouse or typing. It doesn't fix the 'hwptr went backwards' messages, though. Please tell me if sysctl -w kern.random.yarrow.bins=2 makes a difference for you. Thanks! M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Atomic breakage?
Hi John There seems to be same breakage in the atomic stuff: link_elf: symbol atomic_load_acq_int undefined KLD file random.ko - could not finalize loading I back out the latest commit to sys/i386/include/atomic.h, and things work a bit better (on my laptop). M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
Start some kind of hardware-managed timer at the earliest possible opportunity (perhaps start it in the boot loader!), then when you need to pick up your first seed, read the timer's value and seed your random generator from that. I have some much more sophisticated code (written by JHB) that does effectively this. It does it by hooking interrupt randomness, and by using the interrupts from your disk controllers (SCSI and IDE/ATA), a nicely fast reseed is gained. I'll happily commit it now, but I'd prefer a code review first, and is suspect that this will be better received once Jake's preemptive ithread code is committed. The idea is to catch that timer at an unknown condition, and certainly the computer is not going to boot in the exact same amount of time, every time it's restarted. This would be especially true if the boot sequence gets interrupted (to load another kernel perhaps) or the user forces the machine into single-user mode while it's booting. All entropy harvesting uses some kind of harvesting. On i386, (Pentium and better) it is the TSC register. 80386 and 80486 use nanotime(9) and other CPUs have a TSC-like register. In my hobby platform, it's common to start the timer, then grab a value from it after the user hits a key after viewing some introduction screen. The value grabbed is often used as the actual random number, but it could be just as useful if used to seed a random generator. SOP :-) If you're particularly paranoid, you set both timers for 32-bit mode, start one first thing at startup, and the other when the user hits the key, then read both of them the first time a random number is needed. Seed your random generator from that, along with any other sources you can (such as the video raster counter and the sound device's readable oscillator, set to generate a noise waveform). Slight overkill, when the TSC register is already used and deliberately underestimated to improve randomness quality. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: entropy bikesheds
Doug Barton said:
Since this post actually has some content I'm moving it to
-current.
Cool!
Our /var isn't persistant accross boots, btw. It is a mfs file
system. Having a requirement that /var contain persistant data would
likely lead to problems.
It's precisely for these, and other hairy examples that I haven't
put the thing in /var yet. Even a diskless workstation can read files from
a RO root that the host writes out periodically, but there is no guarantee
that there will be a /var filesystem that we can read from at boot time. I
actually started to write some code to handle some obvious cases and got a
major headache just thinking about it.
What is needed is some form of persistant storage to stash the Yarrow
state over a reboot or a crash.
There are a number of people saying "Over my dead body can you put it
${HERE}!!", without coming up with alternatives that are useful. At
BSDCon, the concept of using the first swap partition was discussed,
and I think it is a great idea, but the volunteer has yet to offer
any code.
I'm still not sure why we can't do something like:
date /dev/random
cat /bin/ls /dev/random
fsck
mount the file systems
read in the entropy file
Eg, toss some bone to the random pool. Sure, it will be highly
preditable, but for the mount commands it doesn't matter. We fix
before anything interesting happens.
Just as usable is "echo 'sekrit password' /dev/random".
Might as well not bother. There is no usable randomness here, so rather
than pretending, it is better to simply admit to ourselves that the
entropy generator is giving crap numbers at this point.
I originally put a block-at-startup in precicesly because of this
complaint. Remember that on a brand-new system, at first boot, the
sshd is going to use /dev/random to make keys. How insecure do you
want that?
Can we decide this, please - do we want secure startup (which will
take some effort to achieve), or can we say "screw it" and start
insecure like the old system?
I'm happy to accomodate folks, but the constant lack of concensus
combined with extreme positions is wearing a bit thin.
M
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: YES! laptop installing
This is to let everyone know that right now as I type I am setting up FreeBSD to start downloading over my cardbus ethernet card. It seems to work great except it doesn't beep when the card enables, but that's fine with me. :-) What card? My Netgear FA510 (dc0) probes (sorta) but comes up with a crazy MAC address, and then doesn't work. It doesn't even go UP. MAC=00:00:80:00:00:80, FWIW. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld Problems at NTP
On Fri, Jan 05, 2001 at 12:37:43AM -0800, Crist J. Clark wrote: What is happening is that the system is killing off the make process because it starts to swell up so much it consumes all swap. Here is the dmesg, Were any bits of the compiler killed off? A new test snapshot of gcc was recently added to -current and maybe it's had a strange effect on makedepend or something There was a make(1) problem a couple of weeks back. Resup, make-and-install make(1), and you should be OK. Dunno why, but ntp(d) tickled the bug. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld Problems at NTP
There was a make(1) problem a couple of weeks back. Resup, make-and-install make(1), and you should be OK. Dunno why, but ntp(d) tickled the bug. To be safe, I nuked the /usr/src/usr.bin/make tree and re-cvsup'ed so I'd checkout new-car-smell-fresh copies. I killed the /usr/obj tree to ensure a clean start there and started a buildworld. Six hours later, === usr.sbin/ntp/ntpd Killed Read what I said!! Make-and-install _make_ (not anything else) first. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
{
:-#if defined(SMP)
: return zalloci(z);
:-#else
:-return _zalloc(z);
:-#endif
: }
:
: static __inline__ void
: zfree(vm_zone_t z, void *item)
: {
:-#ifdef SMP
: zfreei(z, item);
:-#else
:-_zfree(z, item);
:-#endif
: }
:
:-#endif
:+#endif /* _SYS_ZONE_H */
:
:--=-=-=--
:
:
:To Unsubscribe: send mail to [EMAIL PROTECTED]
:with "unsubscribe freebsd-current" in the body of the message
:
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
--
Mark Murray
Warning: this .sig is umop ap!sdn
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Unicode support in cd9660 [patch for review]
Aimed at the thread, not the participants. This is off-topic for audit-. Please bring it back to audit- when you have some actual code to audit. Thanks! M On Wed, Dec 27, 2000 at 12:05:57PM +0200, Maxim Sobolev scribbled: | Several days ago I got a CD with Russian filenames on it and discovered tha t | I'm unable to read those filenames. After some hacking I produced a patch, | which should solve this problem in the manner similar to what we have in | msdosfs module (i.e. user-provided conversion table). I have to emphasize t hat | it's a temporary solution until we will have iconv support in kernel. | | Please somebody review attached patches. Please do not assume Unicode. I18N/L10N efforts have been crying for programmers to *not* and *never* assume *anything*. :) Also, this belongs more on -i18n more than anything else. I really do not want to generate all the traffic on -i18n alone.. :) Have you seen ports/chinese/big5fs? Japanese/Korean do the same thing too You could simply make a port of this that loads KLD's. This enables us to have the support without having hacks in src/sys. I talked to Boris at length about this. And I think this would be the best way to implement "temporary" hacks. As to the progress of iconv, we should have it soon, as soon as itojun and I work out how to import either the Citrus code or Konstantin's code. If you make this a port, I say "go for it." :) If you wish to commit to src/sys, I have strong doubts about this. I hope you do not mind my bluntness about this, as I really want to express the feelings. Merry Christmas and a Happy New Year, Michael -- +--+ | [EMAIL PROTECTED] | [EMAIL PROTECTED] | | http://peorth.iteration.net/~keichii | Yes, BSD is a conspiracy. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-audit" in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
NFS/VM panic in current with INVARIANTS
Hi Matt I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. The panic() is "freeing free entry", and the traceback (minus most of the numbers) is: panic zerror zfreei NDFREE nfsrv_lookup nfs_nfsd nfssvc syscall(2f, 2f, 2f, 1, 0) xint0x80 NFS activity (not mounting) triggers it. The panic happens on the server box, which is a dual-cpu i386 class running an SMP kernel. What else do you need? M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: NFS/VM panic in current with INVARIANTS
On Tue, Dec 26, 2000 at 02:00:54PM +0200, Mark Murray wrote: I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS set. I suppose I could "fix" this by taking out INVARIANTS, but it seems to make more sense to try to get it fixed. Do you have NFS compiled in to the kernel? I've had trouble using INVARIANTS in the kernel and NFS as a module many times - it always panics in the zone allocation stuff. No I don't. Hmmm... (Either you always need to compile modules with the same INVARIENTS options as the kernel, or we need to fix INVARIENTS so it doesn't change the expected behaviour of anything in the kernel) OK. M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: No cable modems??
This is offtopic! If you need to discuss it, please take it to -chat. OFFTOPIC Sorry to post this to -current, but (as should be obvious from the below) it's the only way I can get Ollivier to see it :( Why are you (or your ISP) refusing to accept mail from people with cable modems? Enquiring minds want to know... ;-) : - The following addresses had permanent fatal errors - [EMAIL PROTECTED] (reason: 550 no cable modems here) Many ISP's consider cable modem pools and DSL pools as the same sort of "animal" as dialup users. Very many ISPs will refuse to receive mail from all three of those user-classes, because of the "direct-to-MX" spam issue. The solution is to use your ISP's SMTP "smarthost" for your mail. See http://mail-abuse.org/dul/ /OFFTOPIC M -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: usr.sbin/ntp/ntpd make: Cannot allocate memory
I'm also seing this, on my smallest build machine. (My biggest is an SMP box, and it hasn't completed a make world in about a week due to hard hangs). I'm new at tracking current and I'm having trouble getting past this make error. I've searched around the archive but can't find the answer. I have 128MB of memory and 384MB of swap so I'm really not sure what's going on. I'm running a tyan s1832dl with dual PII350s and SMP seems to be working fine everywhere else so I don't think it's that. Heck, I even got my sound card to make noise. Anyone want to help this newbie? Thanks, Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Mark Murray Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI and Sony laptop
That seems to be intended. I also observed this behaviour some time ago because with -current the entropy file is written by the rc.shutdown script and if this is not done at shutdown the next boot will take more time. Definitely not "intended". It is intended that a seedfile get written at shutdown. Are you fully up to date with your mergemaster(1)ing? Now I use "init 0" for shutdown and "init 6" for reboot. That is a bug if you are up to date. However, it is beyond my ken to fix. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
