Re: telnet -a the default
On Sat, Apr 28, 2001 at 01:15:06PM -0700, Nick Sayer wrote: > Ruslan Ermilov wrote: > > > On Sat, Apr 28, 2001 at 09:34:22AM -0700, Nick Sayer wrote: > > > >> Ruslan Ermilov wrote: > >> > >> > >>> On Sat, Apr 28, 2001 at 08:45:48AM -0700, Nick Sayer wrote: > >>> > >>> > Ruslan Ermilov wrote: > > > > > Hi! > > > > Any reason why revisions 1.6 and 1.7 of crypto/telnet/telnet/main.c > > are not propagated to usr.bin/telnet/main.c? > > Well, because it's meaningless without having encryption compiled in. > All of the authentication methods require encryption. > > >>> > >>> Sorry, I meant making -a the default. > >>> > >>> > >>> Cheers, > >> > >> Again, making -a the default is meaningless without crypto. > >> > > > > I just found it inconvenient to supply -K to telnet(1) every time > > now, and you know that secure/ telnet is installed by default. > > > > Could you please then tell me why -a was made the default for > > crypto telnet(1), and why it is meaningless without crypto? > > I didn't make -a the default for telnet, but I did MFC it just so that > both branches would have the same sources. > > -a without an authentication method ends up just giving you a login: > prompt from the other end. It's functionally no different than just > doing it the old fashioned way. > Assar, What is the reason why -a was made the default for crypto/ telnet? Is it the prerequisite for "auto-negotiation of encrypt and decrypt" committed in crypto/telnet/telnet/main.c,v 1.6 or could it be made optional? Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age 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=1&l=16&e=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
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
Re: panic in fxp driver
In article [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: 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
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: 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
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 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
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"...
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
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: -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
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
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
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
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 #endif +#if !defined(NOPAM) +#include +#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 +
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
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
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
-CURRENT broken in gnu/usr.bin/perl/perl
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 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 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..., 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
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: 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
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