Re: HEADS UP! bad bug in -current.
On Tue, 1 May 2001, Peter Wemm wrote: Any -current kernel built over the weekend is a likely victim of this bug. In a nutshell, it will eat your root filesystem at the very least, leaving you with maybe one or two files in /lost+found. spec_vnops.c rev 1.156 is should be avoided at all costs. BEWARE: there are some snapshots on current.freebsd.org with this bug. They will self destruct after install. Too late - I'm just rebuilding one of my scratch machines right now :-( -- Doug Rabson Mail: [EMAIL PROTECTED] Phone: +44 20 8348 6160 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Rfork'd threads, signals, and LDTs
On Wed, 2 May 2001, Bruce Evans wrote: On Tue, 1 May 2001, Daniel Eischen wrote: Why are %fs and %gs set back to default (_udata_sel) when posting signals? All segment registers are set to a default state so that signal handlers have some chance of running when they interrupt code that has changed the segment registers to unusual values. OK. I am planning on using %fs for TSD/KSD and want it to be valid in signal handlers. Imagine doing the same thing with %ds, or better yet, %ss. %ss must be set to the default for the kernel to even provide a normal stack for the signal handler. Similarly for %ds, except it is possible for signal handlers to set up their own %ds as necessary provided both the user code and the signal trampoline is written to avoid using %ds before initializing it. Well, we're not using %ds or %ss for TSD. It was discussed on -arch some time ago that we would reserve %fs for TSD, so we really on care about that case. I threw in %gs because that was also an option except that WINE used it. [ patch snipped ] There is also the osendsig() case, and corresponding code in several emulators. I don't think we care too much about osendsig() since anything that uses a new threads library will have to be recompiled and wouldn't use the old routines. I think the same is true for emulators; an application that used the new threads library wouldn't be running in emulation would it? The problem has some similarites to ones for handling floating point state. We should be setting the FPU to a clean state so that signal handlers can use floating point. (We don't do this on i386's because signal handlers rarely use floating point and it is difficiult to do without pessimizing delivery of all signals.) OTOH, I believe C99 says that the floating point environment (things like rounding control) is inherited by signal handlers. This seems to be even more difficult to implement on i386's. Changes in the enviroment made by fesetenv() should apply to signal handlers, but temporary ones made by the compiler and library functions should not. So, what if we just make the change for %fs. Or is there a way to tell the kernel Hey, I don't want %fs to be changed when setting up the signal handler? A flag to sigaction sa_flags? The other option is for the userland signal handler to fetch the value for %fs out of the sigcontext^Wucontext and manually set it. But this gets icky because now the threads library has to have arch-dependent signal handlers. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
No Subject
Salve, Con DirectLine potrai riferirti ad un unico operatore per tutte le tue chiamate urbane, interurbane, internazionali e verso cellulari a tariffe MAI VISTE... Inoltre, con la semplice iscrizione gratuita, avrai diritto ad inviare i tuoi fax in tutta Italia a costo zero grazie al servizio freefax Il segreto di DirectLine è che non ha spese gestionali (che ricadono, inevitabilmente, sull'utente): le bollette, i pagamenti, l'assistenza transitano esclusivamente via email. Segnalando il Club ai tuoi amici, arriverai ad eliminare del tutto la bolletta telefonica, e se gli amici sono tanti... potrai addirittura guadagnare denaro! il Club DirectLine è lieto di annunciarLe nuovi ribassi di tariffe in vigore dal 1 Aprile 2001 NUOVE TARIFFE IN VIGORE DAL 1 APRILE 2001 +--+---+-+ | Destinazione| Fascia | Fascia | | |Ord. | Rid.| +--+---+-+ |Italia Urbano* | 50 | 50 | |Italia Inter.* | 85 | 70 | |Italia Cell.* | 449 | 449| +--+---+-+ * Con Scatto alla risposta di Lire 50 per il primo minuto IL GIRO DEL MONDO CON POCHE LIRE +--+---+ | Destinazione| Tariffa | | | al min/Lre| +--+---+ |Francia | 199 | |Germania | 199 | |Grecia| 499 | |Hong Kong | 419 | |Ungheria | 629 | |India | 1399| |Iran | 1609| |Irelanda | 199 | |Israele | 419 | |Giappone | 349 | |Kenya | 1399| |Korea del Sud | 419 | |Libano| 1329| |Libia | 221 | |Olanda| 199 | |Filippine | 839 | |Polonia | 489 | |Portogallo| 419 | |Romania | 699 | |Russia| 629 | |Spain | 199 | |Svizzera | 221 | |U.S.A | 199 | |UK| 199 | |Venezula | 699 | |Canada | 199 | +--+---+ Con Scatto alla risposta di Lire 250 per il primo minuto per visualizzare la tabella, impostare il carattere Courier TUTTE LE TARIFFE ELENCATE SONO TASSE COMPRESE Cordiali saluti ISCRIZIONE - Per iscrizione al servzio invia un messaggio a : mailto:[EMAIL PROTECTED]?Subject=iscrizione ed sarete contattati +--IL CONCETTO DI DIRECTlINE-+ || | |Per ciascun nuovo membro entrato a far parte| |del club grazie a tua segnalazione con | |click di mouse guadagnerai una royalty mensile | |pari al 5% dell'importo della sua bolletta | |telefonica. Detto guadagno avverrà OGNI MESE| |e per OGNI CLIENTE cui avrai fatto conoscere al | |club| ++ +FREE FAX-+ | | | FREEFAX~FREEFAX~ FREEFAX~FREEFAX~FREEFAX| | | | Il Club offre FreeFax ogni | | mese per un importo pari al 20% della vostra bolletta | | telefonica del mese precedente. | | Vi ricordiamo che: | | Il credito viene calcolato ogni mese esclusivamente | | in base al traffico telefonico generato nel mese precedente.| | Il credito non è cumulabile con quelli dei mesi successivi, | | quindi se il credito a cui si ha diritto non viene esaurito | | entro la fine del mese lo stesso va perduto.| | Il credito può essere utilizzato solo per trasmissioni fax | | nazionali. Se l'utilizzo di FreeFax nel mese supera il | | credito a cui si ha diritto, la differenza verrà fatturata | | sul conto del cliente. | | | +-+ °° ° DirectLine° ° NUMERO VERDE 800 791405 ° ° NUMERO VERDE 800 791006 ° ° mailto:[EMAIL PROTECTED] ° °°
Re: -CURRENT broken in gnu/usr.bin/perl/perl
On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote: Just glanced through cvs-all; didn't see commits more recent than my last CVSup: CVSup started from cvsup14.freebsd.org at Tue May 1 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 1 03:55:45 PDT 2001 Did you do another buildworld between these CVSup's? CVSup started from cvsup14.freebsd.org at Wed May 2 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 2 03:53:01 PDT 2001 The suspected commit is [EMAIL PROTECTED] It looks like the recent BSDPAN change has a problem - I am looking into it. The error occurred during stage 4: make dependencies: === gnu/usr.bin/perl/libperl === gnu/usr.bin/perl/perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line syntax error at lib/SelfLoader.pm line 69, at EOF Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17. Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37. BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37. Compilation failed in require at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Hmm SelfLoader.pm was last modified: m133[3] ls -l SelfLoader.pm -rw-rw-r-- 1 david wheel 12043 Jun 25 2000 SelfLoader.pm It's at revision 1.1 Hmmm..., Cheers, +Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT broken in gnu/usr.bin/perl/perl
Date: Wed, 2 May 2001 18:28:18 +0200 From: Anton Berezin [EMAIL PROTECTED] CVSup started from cvsup14.freebsd.org at Tue May 1 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 1 03:55:45 PDT 2001 Did you do another buildworld between these CVSup's? CVSup started from cvsup14.freebsd.org at Wed May 2 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 2 03:53:01 PDT 2001 Yes. Built OK; seemed to run OK (though I mostly run -STABLE on the box). The suspected commit is [EMAIL PROTECTED] It looks like the recent BSDPAN change has a problem - I am looking into it. OK; thanks! Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
BlackOffers.com Newsletters
Title: BlackOffers.com - Newsletters for the African American Subscribe to our free newsletters and get the latest information you need to know! BlackOffers.com exclusive newsletters targets African Americans online looking for the latest information relating to the black experience. Although not all content is black related, we bring it to you from a black perspective. Enter your email and select from our newsletters below. YOUR E-MAIL: Inspirational Motivations Contests & Sweepstakes Black History New Black Web Sites Black Headlines Doing Business Online Free Offers Specials & Promotions Click here for information about the Newsletters Visit these other fine black destinations: Blackstocks.com Gospelcity.com BlackWebPortal.com Blackplanet.com Important Notes: 1. There is no cost to join, all lists are free. 2. Your privacy is guaranteed. Your information will never be sold to any third parties. 3. Easy process to unsubscribe. 4. Newsletters are sent in rich media html format. Home About Us Partner Contact Us Copyright 2001, BlackOffers.com www.blackoffers.com [EMAIL PROTECTED] ---To be unsubscribed from the BlackOffers.com Newsletters mailing list, simply click on the link below:Unsubscribe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
isdn stops working when load increases
hello, world\n I've seen some recent mails related to rtprio oddity which seemed to also affect the isdnd. My -current is cvsupped May 1st (and survived; I've still got a fully populated root fs :-) However, as soon as I do a find / or buildworld or some other commands increasing the load significantly (about 1 or more), isdnd seems to take a nap. No more packets transmitted. If I suspend the running programs, isdnd awakes and continues. Is anybody else observing the same behavior? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) 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: HEADS UP! Breakage in Perl/BSDPAN
On Wed, May 02, 2001 at 11:26:49PM +0200, Mark Murray wrote: 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.) But for those who built world in the above timeframe, it is still necessary to apply the patch: this is one of the unfortunate cases where the state of currently installed perl modules affects the buildworld. \Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT broken in gnu/usr.bin/perl/perl
On Wed, May 02, 2001 at 06:28:18PM +0200, Anton Berezin wrote: On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote: It looks like the recent BSDPAN change has a problem - I am looking into it. The error occurred during stage 4: make dependencies: === gnu/usr.bin/perl/libperl === gnu/usr.bin/perl/perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line syntax error at lib/SelfLoader.pm line 69, at EOF Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17. Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37. BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37. Compilation failed in require at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 The fix has been committed. Please also see a HEADS UP message on this list. Thanks, David, for reporting this. +Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
PATCH: partial fix for broken make release...
The make release stuff is broken, at least in 4.3, and possibly
before that.
There are several obviously broken things:
o The libssh stuff is not installed, and it is not built
during a make release; I don't know why that is; the
workaround is to wait for it to bomb out, and then
manuall copy /usr/obj/usr/src/secure/lib/libssh/lib*.a
into your ${CHROOTDIR}/usr/obj, and do a make rerelease
to restart things (without this, the pam_ssh module
build fails).
o The files jade_1.2.1-13.diff.gz and pdf_sec.ps are not
available from any of the listed mirros in the ports
hierarchy, so they can not be correctly installed, and
a doc build can not complete. The workaround is to
let the above fail, and then:
cd ${CHROOT}/usr/ports/distfiles
GOTO=ftp://sunsite.doc.ic.ac.uk/Mirrors/FreeBSD/ports/distfiles;
fetch ${GOTO}/jade_1.2.1-13.diff.gc
fetch ${GOTO}/pdf_sec.ps
Then restart again... but this time:
make rerelease RELEASENOUPDATE=Y ...
o If you set KERNCONF to a non-default value (GENERIC is
the default value), then sysinstall can't find it to
install it during the installation process; the attached
patch works for RELENG_4, and would have to be reflected
into /usr/src/release AND /usr/src/usr.sbin/sysinstall
for -current.
Can someone at least apply the patch to RELENG_4???
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Index: Makefile
===
RCS file: /home/cvs/FreeBSD/src/release/Makefile,v
retrieving revision 1.536.2.41
diff -u -r1.536.2.41 Makefile
--- Makefile2001/04/14 22:29:49 1.536.2.41
+++ Makefile2001/05/02 22:04:14
@@ -268,6 +268,7 @@
echo #!/bin/sh ${CHROOTDIR}/mk
echo set -ex ${CHROOTDIR}/mk
echo _RELTARGET=\$${1:-doRELEASE} ${CHROOTDIR}/mk
+ echo export KERNCONF=${KERNCONF} ${CHROOTDIR}/mk
echo export CFLAGS='-O -pipe' ${CHROOTDIR}/mk
echo export NO_X=YES ${CHROOTDIR}/mk
echo export DISTRIBUTIONS=\${DISTRIBUTIONS}\ ${CHROOTDIR}/mk
Index: sysinstall/Makefile
===
RCS file: /home/cvs/FreeBSD/src/release/sysinstall/Attic/Makefile,v
retrieving revision 1.92.2.10
diff -u -r1.92.2.10 Makefile
--- sysinstall/Makefile 2001/03/12 12:10:28 1.92.2.10
+++ sysinstall/Makefile 2001/05/02 22:06:52
@@ -17,7 +17,7 @@
system.c tape.c tcpip.c termcap.c ufs.c usb.c user.c variable.c \
wizard.c keymap.h
-CFLAGS+= -Wall -I${.CURDIR}/../../gnu/lib/libdialog -I${.OBJDIR}
+CFLAGS+= -Wall -I${.CURDIR}/../../gnu/lib/libdialog -I${.OBJDIR}
+-DKERNCONF=\${KERNCONF}\
.if ${MACHINE} == pc98
CFLAGS+= -DPC98
.endif
Index: sysinstall/install.c
===
RCS file: /home/cvs/FreeBSD/src/release/sysinstall/Attic/install.c,v
retrieving revision 1.268.2.22
diff -u -r1.268.2.22 install.c
--- sysinstall/install.c2001/03/12 22:50:04 1.268.2.22
+++ sysinstall/install.c2001/05/02 22:20:06
@@ -750,7 +750,11 @@
if (RunningAsInit) {
/* Fix up kernel first */
if (!file_readable(/kernel)) {
+#ifdef KERNCONF
+ char *generic_kernel = /kernel. KERNCONF;
+#else
char *generic_kernel = /kernel.GENERIC;
+#endif
if (file_readable(generic_kernel)) {
if (vsystem(cp -p %s /kernel, generic_kernel)) {
msgConfirm(Unable to copy /kernel into place!);
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: partial fix for broken make release...
If memory serves me right, Terry Lambert wrote:
o The files jade_1.2.1-13.diff.gz and pdf_sec.ps are not
available from any of the listed mirros in the ports
hierarchy, so they can not be correctly installed, and
a doc build can not complete. The workaround is to
let the above fail, and then:
Yes. Ran into this when testing RELNOTESng. G.
cd ${CHROOT}/usr/ports/distfiles
GOTO=ftp://sunsite.doc.ic.ac.uk/Mirrors/FreeBSD/ports/distfiles;
fetch ${GOTO}/jade_1.2.1-13.diff.gc
s/gc/gz
fetch ${GOTO}/pdf_sec.ps
Then restart again... but this time:
make rerelease RELEASENOUPDATE=Y ...
Another way to do this is to fetch the files into /usr/ports/distfiles
and then do the release (this works for all distfiles, not just the
unfetchable ones). Part of the release process copies /usr/ports/
distfiles to ${CHROOT}/usr/ports/distfiles. In other words:
# Do this once
cd /usr/ports/distfiles
GOTO=ftp://sunsite.doc.ic.ac.uk/Mirros/FreeBSD/ports/distfiles
fetch ${GOTO}/jade_1.2.1-13.diff.gz
fetch ${GOTO}/pdf_sec.ps
# make release works normally
Cheers,
Bruce.
PGP signature
Re: PATCH: partial fix for broken make release...
From: Terry Lambert [EMAIL PROTECTED]
Subject: PATCH: partial fix for broken make release...
Date: Wed, 2 May 2001 22:00:37 + (GMT)
The make release stuff is broken, at least in 4.3, and possibly
before that.
There are several obviously broken things:
o The libssh stuff is not installed, and it is not built
That would be a failure in make world, not make release.
o The files jade_1.2.1-13.diff.gz and pdf_sec.ps are not
available from any of the listed mirros in the ports
That would be a failure in the ports collection, not make release.
I don't make both observations to be pedantic, but to simply make it
clear that the correct fixes need to happen somewhere else.
o If you set KERNCONF to a non-default value (GENERIC is
the default value), then sysinstall can't find it to
I'm not clear as to why you'd want to? GENERIC is the best kernel for
creating generally useable releases, but I imagine you have some other
reason for chosing a specific configuration for which I also expect
you're copying the config file into ${CHROOTDIR}/usr/src/sys/${ARCH}/conf
from somewhere else? I can't see how this change by itself makes what
appears to be the desired functionality a reality.
- Jordan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: partial fix for broken make release...
On 02-May-01 Jordan Hubbard wrote:
From: Terry Lambert [EMAIL PROTECTED]
Subject: PATCH: partial fix for broken make release...
Date: Wed, 2 May 2001 22:00:37 + (GMT)
The make release stuff is broken, at least in 4.3, and possibly
before that.
There are several obviously broken things:
oThe libssh stuff is not installed, and it is not built
That would be a failure in make world, not make release.
He probably doesn't have src-crypto or cvs-crypto in his cvsup file. *shrug*
Works fine here and worked fine for the 4.3 release build.
oThe files jade_1.2.1-13.diff.gz and pdf_sec.ps are not
available from any of the listed mirros in the ports
That would be a failure in the ports collection, not make release.
Yes. Haven't seen this locally though, but I may have these files prefetched
to /usr/docdistfiles on the local snap building machine.
oIf you set KERNCONF to a non-default value (GENERIC is
the default value), then sysinstall can't find it to
I'm not clear as to why you'd want to? GENERIC is the best kernel for
creating generally useable releases, but I imagine you have some other
reason for chosing a specific configuration for which I also expect
you're copying the config file into ${CHROOTDIR}/usr/src/sys/${ARCH}/conf
from somewhere else? I can't see how this change by itself makes what
appears to be the desired functionality a reality.
You could use LOCAL_PATCHES to do it if your patch created a new config file.
This would be appropriate if you were rolling an internal release using your
own kernel config. In that case his patches make sense.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RFD: SRA telnet PAM patch
The problem noted was that telnetd was allowing root logins. This patch doesn'tt
directly address that, but by making SRA use PAM the hope is that it will be
easier to have policy changes take place with PAM rather than all over
the place.
Suggestions on either how to imrpove this patch or what should be done
to bar root logins are welcome.
Index: src/etc/pam.conf
===
RCS file: /home/ncvs/src/etc/pam.conf,v
retrieving revision 1.13
diff -u -r1.13 pam.conf
--- src/etc/pam.conf2001/04/06 05:52:53 1.13
+++ src/etc/pam.conf2001/05/02 19:26:35
@@ -86,6 +86,10 @@
# csshd is for challenge-based authentication with sshd (TIS auth, etc.)
csshd authrequiredpam_skey.so
+# SRA telnet. Non-SRA telnet uses 'login'.
+telnetdauthrequiredpam_unix.so try_first_pass
+telnetdaccount requiredpam_unix.so
+
# Don't break startx
xserverauthrequiredpam_permit.so
Index: crypto/telnet/libtelnet/sra.c
===
RCS file: /home/ncvs/src/crypto/telnet/libtelnet/sra.c,v
retrieving revision 1.1.2.1
diff -u -r1.1.2.1 sra.c
--- crypto/telnet/libtelnet/sra.c 2000/09/20 02:32:05 1.1.2.1
+++ crypto/telnet/libtelnet/sra.c 2001/05/02 19:26:36
@@ -13,6 +13,10 @@
#include string.h
#endif
+#if !defined(NOPAM)
+#include security/pam_appl.h
+#endif
+
#include auth.h
#include misc.h
#include encrypt.h
@@ -447,6 +451,7 @@
return (save);
}
+#ifdef NOPAM
char *crypt();
int check_user(name, pass)
@@ -474,7 +479,135 @@
}
return(0);
}
+#else
+
+/*
+ * The following is stolen from ftpd, which stole it from the imap-uw
+ * PAM module and login.c. It is needed because we can't really
+ * converse with the user, having already gone to the trouble of
+ * getting their username and password through an encrypted channel.
+ */
+
+#define COPY_STRING(s) (s ? strdup(s):NULL)
+
+struct cred_t {
+ const char *uname;
+ const char *pass;
+};
+typedef struct cred_t cred_t;
+
+auth_conv(int num_msg, const struct pam_message **msg,
+ struct pam_response **resp, void *appdata)
+{
+ int i;
+ cred_t *cred = (cred_t *) appdata;
+ struct pam_response *reply =
+ malloc(sizeof(struct pam_response) * num_msg);
+
+ for (i = 0; i num_msg; i++) {
+ switch (msg[i]-msg_style) {
+ case PAM_PROMPT_ECHO_ON:/* assume want user name */
+ reply[i].resp_retcode = PAM_SUCCESS;
+ reply[i].resp = COPY_STRING(cred-uname);
+ /* PAM frees resp. */
+ break;
+ case PAM_PROMPT_ECHO_OFF: /* assume want password */
+ reply[i].resp_retcode = PAM_SUCCESS;
+ reply[i].resp = COPY_STRING(cred-pass);
+ /* PAM frees resp. */
+ break;
+ case PAM_TEXT_INFO:
+ case PAM_ERROR_MSG:
+ reply[i].resp_retcode = PAM_SUCCESS;
+ reply[i].resp = NULL;
+ break;
+ default:/* unknown message style */
+ free(reply);
+ return PAM_CONV_ERR;
+ }
+ }
+
+ *resp = reply;
+ return PAM_SUCCESS;
+}
+
+/*
+ * The PAM version as a side effect may put a new username in *user.
+ */
+int check_user(const char *name, const char *pass)
+{
+ pam_handle_t *pamh = NULL;
+ const char *tmpl_user;
+ const void *item;
+ int rval;
+ int e;
+ cred_t auth_cred = { name, pass };
+ struct pam_conv conv = { auth_conv, auth_cred };
+
+ e = pam_start(telnetd, name, conv, pamh);
+ if (e != PAM_SUCCESS) {
+ syslog(LOG_ERR, pam_start: %s, pam_strerror(pamh, e));
+ return 0;
+ }
+
+#if 0 /* Where can we find this value? */
+ e = pam_set_item(pamh, PAM_RHOST, remotehost);
+ if (e != PAM_SUCCESS) {
+ syslog(LOG_ERR, pam_set_item(PAM_RHOST): %s,
+ pam_strerror(pamh, e));
+ return 0;
+ }
+#endif
+
+ e = pam_authenticate(pamh, 0);
+ switch (e) {
+ case PAM_SUCCESS:
+ /*
+* With PAM we support the concept of a template
+* user. The user enters a login name which is
+* authenticated by PAM, usually via a remote service
+* such as RADIUS or TACACS+. If authentication
+* succeeds, a different but related template name
+* is used for setting the credentials, shell, and
+* home directory. The name the user enters need only
+* exist on the remote authentication server, but the
+
Re: PATCH: partial fix for broken make release...
] On 02-May-01 Jordan Hubbard wrote:
] From: Terry Lambert [EMAIL PROTECTED]
] The make release stuff is broken, at least in 4.3, and possibly
] before that.
]
] There are several obviously broken things:
]
] oThe libssh stuff is not installed, and it is not built
]
] That would be a failure in make world, not make release.
]
] He probably doesn't have src-crypto or cvs-crypto in his cvsup file.
] *shrug* Works fine here and worked fine for the 4.3 release build.
I have src-crypto and cvs-crypto; the _ONLY_ thing that breaks is
the pam_ssh, when it goes to link against libssh, which is not
a shared object, and is not an installed target as a result of
make release.
A make world works perfectly fine, and builds everything, including
the pam_ssh, just fine. Examining the /usr/obj and the CHROOT
version of /usr/obj indicates that the difference is that the
libssh isn't built in the chroot case, and is referenced via a
relative path, instead of being referenced from where it _is_ built.
Copying _just_ those libraries allows the pam_ssh build to complete
successfully, and nothing else uses them.
] oThe files jade_1.2.1-13.diff.gz and pdf_sec.ps are not
] available from any of the listed mirros in the ports
]
] That would be a failure in the ports collection, not make release.
]
] Yes. Haven't seen this locally though, but I may have these files
] prefetched to /usr/docdistfiles on the local snap building machine.
The main problem here is that none of the mirrors listed in the
ports have them, and the FreeBSD FTP server is presently in
limbo or pushing up daisies, depending on who you ask.
Copying them into the local /usr/ports/distfiles works (as was
alluded to in Bruce A. Mah's message), and is a better workaround
than waiting for the failure and restarting things, but is a much
less useful thing than correcting the ports for these things to
point to mirrors that work...
] oIf you set KERNCONF to a non-default value (GENERIC is
] the default value), then sysinstall can't find it to
]
] I'm not clear as to why you'd want to? GENERIC is the best kernel for
] creating generally useable releases, but I imagine you have some other
] reason for chosing a specific configuration for which I also expect
] you're copying the config file into ${CHROOTDIR}/usr/src/sys/${ARCH}/conf
] from somewhere else? I can't see how this change by itself makes what
] appears to be the desired functionality a reality.
]
] You could use LOCAL_PATCHES to do it if your patch created a new config
] file. This would be appropriate if you were rolling an internal release
] using your own kernel config. In that case his patches make sense.
Exactly what I'm doing: I'm _not_ rolling a boxed set of CDROMs, I'm
rolling an internal release using my own kernel config, which I want
to be installed by default as a result of an upgrade procedure, so
that I can upgrade machines from a coaster after I've burnt it and
verified that it passes acceptance testing.
Actually, the boxed set of CDROMs thing is really hard to do
entirely correctly, since the ports build process is so arcane,
which seems to be because the ports themselves are not DESTDIR
clean, so they have to be built serially.
There's also the tools directory, which I guess is copied in
magically, because some of the CDROM distribution is built on
(bletch!) DOS, instead of being 100% FreeBSD hosted.
To elaborate on Jordan's guess, I'm actually _replacing_ the entire
/usr/src/sys directory (and using a LOCAL_SCRIPT to do the same to
the /usr/src/sys directory in the CHROOT environment at the right
time during the build process.
If I were truly a grumpy guy, I'd insist that the cvs checkout of
the kernel sources be capable of using a different repository and
a different tag.
My next challenge will be to get my personal packages to show up
as options in sysinstall, and to make their installation default
for a particular installation set name...
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: PATCH: partial fix for broken make release...
On 03-May-01 Terry Lambert wrote:
A make world works perfectly fine, and builds everything, including
the pam_ssh, just fine. Examining the /usr/obj and the CHROOT
version of /usr/obj indicates that the difference is that the
libssh isn't built in the chroot case, and is referenced via a
relative path, instead of being referenced from where it _is_ built.
Copying _just_ those libraries allows the pam_ssh build to complete
successfully, and nothing else uses them.
make release does a make world in the chroot:
rerelease release:
...
.if make(release)
echo (cd etc; make distrib-dirs distribution) ${CHROOTDIR}/mk
echo make ${WORLD_FLAGS} world \\ ${CHROOTDIR}/mk
.endif
...
chroot ${CHROOTDIR} /mk
I haven't ever seen this before. Are you using any other customizations
besides LOCAL_SCRIPT? Are you specifying NO_CRYPTO or something?
] Yes. Haven't seen this locally though, but I may have these files
] prefetched to /usr/docdistfiles on the local snap building machine.
The main problem here is that none of the mirrors listed in the
ports have them, and the FreeBSD FTP server is presently in
limbo or pushing up daisies, depending on who you ask.
Well, then as Jordan stated, the ports need to be fixed. The actual release
process itself is not broken in this respect, however.
There's also the tools directory, which I guess is copied in
magically, because some of the CDROM distribution is built on
(bletch!) DOS, instead of being 100% FreeBSD hosted.
AFAIK, it's just copied off of the previous CD-ROM each time. I don't think
it's been updated in quite some time. :) DOS is not used though. I think that
the tools/ subdir on the CD is considered a WC/BSDi addon though, not part of
the base system.
If I were truly a grumpy guy, I'd insist that the cvs checkout of
the kernel sources be capable of using a different repository and
a different tag.
That's what LOCAL_SCRIPT is for in this case. make release isn't really
designed to patch together various source collections, it's designed to build a
release from one source collection.
My next challenge will be to get my personal packages to show up
as options in sysinstall, and to make their installation default
for a particular installation set name...
Just add the appropriate lines to the INDEX file and they will show up fine.
If you actually add ports directories for them to /usr/ports and rebuild the
INDEX (via 'make index') it will DTRT. Note that you don't need all of ports/
to do this, just ports/Mk and ports/tlambert (or whatever) and a suitable
modified list of directories in ports/Makefile.
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
Power Users Use the Power to Serve! - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Free Online Virtual Tennis Game
Hello: Please enjoy the free, new Virtual Tennis Game at www.maxpages.com/magian10s/VirtualTennis?ace. The entire family will enjoy it. Morris King, Jr. Director MAGIAN WORLD CLASS TENNIS www.magian10s.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
The fxp driver is broken in a lot of places.
For example, in fxp_intr():
for (txp = sc-cbl_first; sc-tx_queued
(txp-cb_status FXP_CB_STATUS_C) != 0;
txp = txp-next) {
if (txp-mb_head != NULL) {
m_freem(txp-mb_head);
txp-mb_head = NULL;
}
sc-tx_queued--;
}
...notice the for loop doesn't check to see if txp = txp-next
ends up being NULL? You can get this, if you put your system
under extreme load.
If you can repeat the problem with another card, it's a real
problem, otherwise it's probably just FXP driver brain damage...
Terry Lambert
[EMAIL PROTECTED]
---
Any opinions in this posting are my own and not those of my present
or previous employers.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: panic in fxp driver
In article local.mail.freebsd-current/[EMAIL PROTECTED] you
write:
The fxp driver is broken in a lot of places.
For example, in fxp_intr():
for (txp = sc-cbl_first; sc-tx_queued
(txp-cb_status FXP_CB_STATUS_C) != 0;
txp = txp-next) {
if (txp-mb_head != NULL) {
m_freem(txp-mb_head);
txp-mb_head = NULL;
}
sc-tx_queued--;
}
...notice the for loop doesn't check to see if txp = txp-next
ends up being NULL? You can get this, if you put your system
under extreme load.
I would be quite interested in knowing just how you manage
to accomplish that, given that all the transmit control buffers
are arranged in a circular linked list:
fxp_init(void *xsc)
{
...
for (i = 0; i FXP_NTXCB; i++) {
...
txp[i].next = txp[(i + 1) FXP_TXCB_MASK];
}
I would suggest actually examining the rest of the code to see
how it works before making erroneous proclamations based on the
myopic examination of a single statement.
--
Jonathan
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: HEADS UP! bad bug in -current.
On Tue, 1 May 2001, Jordan Hubbard wrote: Say, FreeBSD is usually pretty safe, even in CURRENT. Has something near this magnitude of Really Bad Stuffage snuck into the codebase before? No, it's not common, and it generally takes a Dane swinging something sharp to inflict quite this much damage on our user base. ;-) Obviously I haven't been playing in the right bits of the system, I'll have to start hacking the low-level stuff in FFS some more... I tend not to cause permanent damage to file systems, sadly. I think we can all take lessons from phk here -- he achieves a level of destructiveness that makes even the pro's marvel in wonder. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
You've Been Removed!
This message is to confirm the removal of your email address: [EMAIL PROTECTED] from the BlackOffers.com Newsletters Subscribe Me mailing list. We're sorry to see you go! If you feel you have received this notice in error, please visit the BlackOffers.com Newsletters Subscribe Me mailing list at our website: http://www.mybmail.com to add yourself automatically, or click on the link below to automatically re-subscribe yourself: http://mybmail.com/cgi-bin/info/s.pl?a=1l=16e=current=:freebsd.org Thank you, BlackOffers.com Newsletters To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
