Re: rc.d startup scripts
Fine, you can quote historical context to argue against doing something similar to SVR4 init. I, however, see nothing wrong with making it easier to manage the daemons. Of course, that does not necessarily need to go in the rc.d scripts. This is as it should be.. "rc" files (and directories) are (in my opinion) meant to hold required configuration and startup information, NOT stuff that sends SIGHUP to Apache. Gated got it right - add a simple program (gdc) that does the extra stuff. If we could get the ports maintainers to supply a script that does the extra stuff and install it as part of the port, that could be a mild inducement on the behalf of FreeBSD. I dunno how many times I've typed "ps ax|grep dumbproc ... kill somepid dumbproc" or something like that. "restart dumbproc" would be easier, and unique enough that there wouldn't be any major naming collisions. Create system-wide "restart", "start", and "stop" scripts that the ports maintainers could plug into for those functions... Mebbe not a bad idea for half of the base system programs as well -- wouldn't change the BSD way of doing things, but would add some extra ease-of-use... Just make SURE that people don't start calling "restart lpd" from script files, as that could break things when it comes to porting to other BSD variants. mike To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ed driver broken in today's -CURRENT?
I've just built a new kernel, based on a cvsup at 2030 UTC on 6 May, and since then *some* Ethernet transactions don't work. I've checked that it's not just a dead card: the previous kernel works fine. I have the funny situation that I can send fine, and I can traceroute to the box, but I can't ping. NFS also objects strenuously: 18:36:47.508811 panic.lemis.com freebie.lemis.com: icmp: echo request 18:36:47.508946 freebie.lemis.com panic.lemis.com: icmp: echo reply 18:36:48.512540 panic.lemis.com freebie.lemis.com: icmp: echo request 18:36:48.512669 freebie.lemis.com panic.lemis.com: icmp: echo reply 18:36:49.522568 panic.lemis.com freebie.lemis.com: icmp: echo request 18:36:49.522691 freebie.lemis.com panic.lemis.com: icmp: echo reply 18:36:50.532531 panic.lemis.com freebie.lemis.com: icmp: echo request 18:36:50.532664 freebie.lemis.com panic.lemis.com: icmp: echo reply 18:36:51.542504 panic.lemis.com freebie.lemis.com: icmp: echo request 18:36:51.542636 freebie.lemis.com panic.lemis.com: icmp: echo reply The above all looks good, but panic doesn't see the reply. 18:36:58.933420 freebie.lemis.com panic.lemis.com: icmp: echo request 18:36:59.953879 freebie.lemis.com panic.lemis.com: icmp: echo request 18:37:00.973929 freebie.lemis.com panic.lemis.com: icmp: echo request 18:37:01.993996 freebie.lemis.com panic.lemis.com: icmp: echo request 18:37:03.014053 freebie.lemis.com panic.lemis.com: icmp: echo request 18:37:04.034119 freebie.lemis.com panic.lemis.com: icmp: echo request panic seems to see nothing. 18:37:07.857977 freebie.lemis.com.57058 panic.lemis.com.33435: udp 12 [ttl 1] 18:37:07.858318 panic.lemis.com freebie.lemis.com: icmp: panic.lemis.com udp port 33435 unreachable 18:37:07.860258 freebie.lemis.com.57058 panic.lemis.com.33436: udp 12 [ttl 1] 18:37:07.860584 panic.lemis.com freebie.lemis.com: icmp: panic.lemis.com udp port 33436 unreachable 18:37:07.861455 freebie.lemis.com.57058 panic.lemis.com.33437: udp 12 [ttl 1] 18:37:07.861767 panic.lemis.com freebie.lemis.com: icmp: panic.lemis.com udp port 33437 unreachable This works fine! With the same kernel. After rebooting a kernel of a few days ago, panic can ping just fine: 18:39:17.258545 arp who-has panic.lemis.com tell panic.lemis.com 18:39:22.034446 arp who-has freebie.lemis.com tell panic.lemis.com 18:39:22.034543 arp reply freebie.lemis.com is-at 0:80:ad:b7:c9:c7 18:39:22.034875 panic.lemis.com freebie.lemis.com: icmp: echo request 18:39:22.034994 freebie.lemis.com panic.lemis.com: icmp: echo reply 18:39:23.040705 panic.lemis.com freebie.lemis.com: icmp: echo request 18:39:23.040837 freebie.lemis.com panic.lemis.com: icmp: echo reply 18:39:24.050692 panic.lemis.com freebie.lemis.com: icmp: echo request 18:39:24.050815 freebie.lemis.com panic.lemis.com: icmp: echo reply This is a Compex PCI-based NE2000 lookalike. It's on irq 3 (alone). Who gets the pointy hat? Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Undocumented tape devices in pax(1)
Can someone explain to me why pax(1) has (undocumented) switches which select some tape devices, but apparently randomly numbered ones: From tar.h: /* * default device names */ #define DEV_0 "/dev/rmt0" #define DEV_1 "/dev/rmt1" #define DEV_4 "/dev/rmt4" #define DEV_5 "/dev/rmt5" #define DEV_7 "/dev/rmt7" #define DEV_8 "/dev/rmt8" These are selectable through -0, -1, -4, etc. Nevermind the fact that they point to devices which have never existed in FreeBSD, but why on earth wouldn't you want -2, -3, or -6? Anyway, does anyone see the point in leaving these in (changing the devices to /dev/rsa# and documenting their existence), or should I rip them out? Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ed driver broken in today's -CURRENT?
On Sun, May 07, 2000 at 06:44:39PM +0930, Greg Lehey wrote: I've just built a new kernel, based on a cvsup at 2030 UTC on 6 May, and since then *some* Ethernet transactions don't work. I've checked that it's not just a dead card: the previous kernel works fine. I have the funny situation that I can send fine, and I can traceroute to the box, but I can't ping. NFS also objects strenuously: It is not dead card, it is broken TCP, see my similar report in -current, I notice it several hours ago right after TCP changes was commited. -- Andrey A. Chernov [EMAIL PROTECTED] http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ed driver broken in today's -CURRENT?
Eines schoenen Tages schrieb Andrey A. Chernov: On Sun, May 07, 2000 at 06:44:39PM +0930, Greg Lehey wrote: I've just built a new kernel, based on a cvsup at 2030 UTC on 6 May, and since then *some* Ethernet transactions don't work. I've checked that it's not just a dead card: the previous kernel works fine. I have the funny situation that I can send fine, and I can traceroute to the box, but I can't ping. NFS also objects strenuously: It is not dead card, it is broken TCP, see my similar report in -current, I notice it several hours ago right after TCP changes was commited. Same thing here, but the problems have gone to -stabe too. due to a probable tcp breakage i downgraded my machine to 4.0-stable which worked pretty good. with sources as from may 5th kernel boots fine, but tcp seems broken too. I experience a 50% package loss on out home lan. udp seems broken badly. rpc calls and nfs stopped working. i am using the vx driver on a 3com 3c597 EISA board. network card is ok, packet filtering rules have not been altered since the last kernel version. is nobody else seeing this? any clues? regards, oliver -- And remember: "To Infinity And Far Beyond ... Somehow?!" email: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! - Save this lifeform ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ed driver broken in today's -CURRENT?
Eines schoenen Tages schrieb Oliver Schonefeld: [snip] It is not dead card, it is broken TCP, see my similar report in -current, I notice it several hours ago right after TCP changes was commited. Same thing here, but the problems have gone to -stabe too. due to a probable tcp breakage i downgraded my machine to 4.0-stable which worked pretty good. with sources as from may 5th kernel boots fine, but tcp seems broken too. I experience a 50% package loss on out home lan. udp seems broken badly. rpc calls and nfs stopped working. i am using the vx driver on a 3com 3c597 EISA board. network card is ok, packet filtering rules have not been altered since the last kernel version. is nobody else seeing this? any clues? kind of looks like a problem in the delayed checksum calculation. while having a cvsup running and doing some nfs testing with a linux box pinging killed the -stable machine. (no flood pinging, just a normal ping) also nfs to the linux box was just beyond beeing awefully slow ... not even creeping is the reight term. kernel output from crash: delayed m_pullup, m-len: 84 off: 61420 p: 1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0197f14 stack pointer = 0x10:0xc8934e34 frame pointer = 0x10:0xc8934e60 code segemnt= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current procress= 213 (dnetc) interrupt mask = kernel: type 12, code=0 db trace ip_output(c0661e00,c8934ef4,c0661e00,c0661e4a,7) at ip_output+0xba0 ip_output(c0661e00,0,c8934ef4,14,0,0) at ip_output+0x5fb icmp_input(c0661e00,0) at icmp_input+0x716 icmp_input(c0661e00,c0661e00,fbdd809a,,40) at icmp_input+0x697 icmp_input(c0661e00,14,1,c0661e00,fbdd809a) at icmp_input+0x357 ip_input(c0661e00) at ip_input+0x780 ip_input(c01d7beb,0,2f,2f,2f) at ip_input+0x7df crashdump availabale on request. regards, oliver -- And remember: "To Infinity And Far Beyond ... Somehow?!" email: [EMAIL PROTECTED] [EMAIL PROTECTED] Hi! I'm a .signature virus! Copy me in your ~/.signature to help me spread! - Save this lifeform ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ed driver broken in today's -CURRENT?
-On [2507 14:50], Andrey A. Chernov ([EMAIL PROTECTED]) wrote: It is not dead card, it is broken TCP, see my similar report in -current, I notice it several hours ago right after TCP changes was commited. I assume you mean the NewReno commit submitted by Jayanth? -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl And we are drunk with Death... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ed driver broken in today's -CURRENT?
On Sun, May 07, 2000 at 04:15:57PM +0200, Jeroen Ruigrok van der Werven wrote: -On [2507 14:50], Andrey A. Chernov ([EMAIL PROTECTED]) wrote: It is not dead card, it is broken TCP, see my similar report in -current, I notice it several hours ago right after TCP changes was commited. I assume you mean the NewReno commit submitted by Jayanth? It is either NewReno or checksum changes, I not know which one. -- Andrey A. Chernov [EMAIL PROTECTED] http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP becomes very broken just now
"Andrey A. Chernov" [EMAIL PROTECTED] écrivait (wrote) : Some of recent kernel TCP changes cause TCP completely not working, i.e. any network daemon (mountd, sendmail, cfsd) started from "rc" on dialup machine hangs with 3min "Can't connect' timeout and user level "ppp" started than hangs forever even not dialing. Please fix. You can try: sysctl -w net.inet.tcp.newreno=0 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
Kris Kennaway [EMAIL PROTECTED] wrote:
Can someone explain to me why pax(1) has (undocumented) switches which
select some tape devices, but apparently randomly numbered ones:
Note that these switches appear only in pax' tar compatibility
personality, which isn't used in FreeBSD. And the reason they're
there is because old versions of tar had them.
I'm looking at 4.3BSD's usr/src/bin/tar.c right now, and it supports
-[014578] to select the respective "/dev/rmt#" device.
These are selectable through -0, -1, -4, etc. Nevermind the fact that they
point to devices which have never existed in FreeBSD, but why on earth
wouldn't you want -2, -3, or -6?
Historical reasons.
Back in 4.3BSD, bits 0 and 1 of the minor number seem to have
specified the device, bit 2 marked non-rewinding, bit 3 6250bpi
(high density?). That explains rmt[0145] well enough, although
rmt[78] remain unclear.
Anyway, does anyone see the point in leaving these in (changing the
devices to /dev/rsa# and documenting their existence), or should I rip
them out?
OpenBSD only changed "rmt" to "rst" ("rsa" for us), which isn't
particularly useful. Solaris uses 0..7 to select an entry from
/etc/default/tar, which specifies device name, block size, and tape
size.
I guess mapping -[01] to rsa[01], and -[45] to nrsa[01] still makes
about the most sense.
Unless you intend to revive pax' tar personality under FreeBSD
(which would suggest merging in OpenBSD's changes), I'd say just
leave it.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
-On [2506 21:55], Bruce Evans ([EMAIL PROTECTED]) wrote: On Sat, 6 May 2000, Maxim Sobolev wrote: I've just noticed that "sh MAKEDEV acd1" doesn't produce node for acd1 due to incorrect comparasion in the "while" loop. This affecting both 4.0-STABLE and 5.0-CURRENT. With this message I'm attaching short patch which should solve this little problem. This is the intended behaviour. "sh MAKEDEV acdN" is supposed to create N acd devices, numbered from 0 to N-1. This broken behaviour was introduced for cd*, mcd* and scd* in rev.1.171. It has since spread to acd*. Other types of disks are handled correctly. Bah, bah, bah. I am really starting to wonder about this sunburn thing. Can we settle this once and for all in a slightly sane manner? I committed the change so that MAKEDEV acd1 creates acd1 and not just acd0. I personally think this is more consistent with the wd/sa/da/ad numbering scheme and would propose to fix the other cd* entries likewise. Because otherwise somebody other than me will make the same (commit) mistake x days/weeks/months/years into the future. Opinions? -- Jeroen Ruigrok van der Werven Network- and systemadministrator [EMAIL PROTECTED]VIA Net.Works The Netherlands BSD: Technical excellence at its best http://www.via-net-works.nl In this short time of promise, you're a memory... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: TCP becomes very broken just now
Andrey A. Chernov ([EMAIL PROTECTED]) wrote: Some of recent kernel TCP changes cause TCP completely not working, i.e. any network daemon (mountd, sendmail, cfsd) started from "rc" on dialup machine hangs with 3min "Can't connect' timeout and user level "ppp" started than hangs forever even not dialing. Please fix. The problem is in jlemon's latest commit cleaning up the checksum calculations. I would be interested in seeing what netstat -s says for bad checksums.. I came up with this patch, which fixes my i386 machine.. I dont have an alpha to test. http://people.freebsd.org/~ps/cksum.diff -- Paul Saab Technical Yahoo [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] Do You .. uhh .. Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Sat, 6 May 2000, Kris Kennaway wrote:
# I'm strongly suspecting something wrong with the encoding of the
# certificate. Can you grab dumpasn1.c and dumpasn1.cfg from
[snip]
# Then:
#
# dumpasn1 file.der
root@bonsai(/usr/local/etc/apache/ssl.key)# dumpasn1 server.key
0 2D 45: Unknown (Reserved) {
2 2D 45: Unknown (Reserved) {
4 2D 66: Unknown (Reserved) {
6 45 71: [APPLICATION 5]
: 'IN RSA PRIVATE KEY-.MIICXgIBAAKBgQC554Ro+VH0'
: 'dJONqljPBW+C72MDNGNy9eX'
Error: Inconsistent object length, 7 bytes difference.
: }
Error: Inconsistent object length, 30 bytes difference.
: }
Error: Inconsistent object length, 32 bytes difference.
: }
0 warnings, 3 errors.
I get similar errors with server.crt.
-steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Sun, May 07, 2000 at 04:39:16PM +0200, Christian Weisgerber wrote:
OpenBSD only changed "rmt" to "rst" ("rsa" for us)
Just "sa" for us -- "sa" is now a raw device and "rFOO" use is
depreciated.
--
-- David([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
On Sun, May 07, 2000 at 04:59:46PM +0200, Jeroen Ruigrok van der Werven wrote: Can we settle this once and for all in a slightly sane manner? I committed the change so that MAKEDEV acd1 creates acd1 and not just acd0. This is wrong. ``MAKEDEV acd2'' should either create only /dev/acd2*, or /dev/acd[01]*. It would be nice to fix our inconsistency problem. Looking at the 4.4Lite vendor import to find the BSD way would be a good start. -- -- David([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Le 2000-05-07, Mike Nowlin écrivait :
stuff that sends SIGHUP to Apache. Gated got it right - add a simple
program (gdc) that does the extra stuff. If we could get the ports
Bind has that as well with 'ndc', and apache with apachectl.
Such helper scripts are indeed very useful, and it owuld be quite
nice to have them for the standard subsystems -- I found find
it far more convenient to type eg 'amdc restart' instead of
'killall amd . /etc/rc.conf amd -p ${amd_flags}' :)
Thomas.
--
Thomas Quinot ** Département Informatique Réseaux ** [EMAIL PROTECTED]
ENST // 46 rue Barrault // 75634 PARIS CEDEX 13
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Small MAKEDEV bug
[CC culled, -stable removed] David O'Brien wrote: On Sun, May 07, 2000 at 04:59:46PM +0200, Jeroen Ruigrok van der Werven wrote: Can we settle this once and for all in a slightly sane manner? I committed the change so that MAKEDEV acd1 creates acd1 and not just acd0. This is wrong. ``MAKEDEV acd2'' should either create only /dev/acd2*, or /dev/acd[01]*. It would be nice to fix our inconsistency problem. Looking at the 4.4Lite vendor import to find the BSD way would be a good start. Or just settle for a more intuitive solution: MAKEDEV acd2 creates /dev/acd2 MAKEDEV 2 acd creates /dev/acd[01] which would allow for "MAKEDEV 64 da" and "MAKEDEV 256 pty" -- David([EMAIL PROTECTED]) Jeroen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
Steve Price wrote:
On Fri, 5 May 2000, Kris Kennaway wrote:
# I'm suspecting it might be something missing in the ASN.1 encoding of the
# certificate, which netscape requires but IE permits. This would be
# consistent with a missing openssl.cnf file at the time of certificate
# generation. Could one of you try copying the openssl.cnf file from
# crypto/openssl/apps/ to /etc/ssl (editing as appropriate) and see if that
# fixes it (i.e. make a new certificate and test it in the same way)?
It didn't help here. I rebuilt the port and re-installed from
a clean WRKDIR and I get the same error message. If I do a
'make certificate', copy those files over, and try to start
apache it just hangs definitely until I ^C it. After I kill
it I see this in the apache error logs.
[error] mod_ssl: Init: Private key not found (OpenSSL library
error follows)
[error] OpenSSL: error:0D06B078:asn1 encoding routines:ASN1_get_object:
header too long
Methinks it has something to do with key generation as well, but
I'll be darned if I know what.
Ok, here are some silly questions. Did you create a private key for
this server, did you encrypt your cert with it, and is that .key file
pointed to in your httpd.conf config file? SSLCertificateKeyFile is what
you're looking for. http://www.modssl.org/related/ has some really good
resources for this, and their FAQ has step by step instructions for
creating and testing keys and certs that may help you track down where
in the process it's getting lost.
Also, did you install the openssl port, or are you using the openssl
that is part of the base in 4.0+? I vaguely remember you saying that you
were using the port. If so, cd to /usr/local/openssl and cp
openssl.cnf.sample to openssl.cnf.
I'm currently hip deep in certificate generation problems myself, so I
sympathize with your plight there Steve. Kris, I was going to let you
know about the openssl.cnf problem, but I wanted to wait till I had more
data. But, since the cat's out of the bag here, yes, we do need an
openssl.cnf file in /etc/ssl for the system version. I attached a patch
(not that you couldn't have done it yourself...). The only problem with
this is that from the mergemaster standpoint, there is no $FreeBSD/$Id
tag in that file. mm will still work (doing a complete comparison with
diff) but it speeds things up and hides local mods if there is a CVS
tag.
HTH,
Doug
--
"Live free or die"
- State motto of my ancestral homeland, New Hampshire
Do YOU Yahoo!?
Index: Makefile
===
RCS file: /usr/ncvs/src/etc/Makefile,v
retrieving revision 1.221
diff -u -r1.221 Makefile
--- Makefile2000/04/15 16:48:41 1.221
+++ Makefile2000/05/07 19:20:41
@@ -26,6 +26,10 @@
${.CURDIR}/../crypto/openssh/sshd_config
.endif
+.if exists(${.CURDIR}/../crypto) !defined(NO_OPENSSL)
+SSL= ${.CURDIR}/../crypto/openssl/apps/openssl.cnf
+.endif
+
# -rwxr-xr-x root.wheel, for the new cron root.wheel
BIN2= netstart pccard_ether rc.suspend rc.resume
@@ -76,6 +80,10 @@
.if exists(${.CURDIR}/../crypto) !defined(NO_OPENSSH)
(cd ${.CURDIR}; ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 644 ${SSH} \
${DESTDIR}/etc/ssh )
+.endif
+.if exists(${.CURDIR}/../crypto) !defined(NO_OPENSSL)
+ (cd ${.CURDIR}; ${INSTALL} -c -o ${BINOWN} -g ${BINGRP} -m 644 ${SSL} \
+ ${DESTDIR}/etc/ssl )
.endif
.if !defined(NO_MAKEDEV)
(cd ${DESTDIR}/dev; sh MAKEDEV all)
Re: ed driver broken in today's -CURRENT?
On Sun, May 07, 2000 at 04:15:57PM +0200, Jeroen Ruigrok van der Werven wrote: -On [2507 14:50], Andrey A. Chernov ([EMAIL PROTECTED]) wrote: It is not dead card, it is broken TCP, see my similar report in -current, I notice it several hours ago right after TCP changes was commited. I assume you mean the NewReno commit submitted by Jayanth? It is either NewReno or checksum changes, I not know which one. Since there's a sysctl you can use to turn the former off, perhaps it would have been smart to take a few seconds to narrow it down? -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ed driver broken in today's -CURRENT?
On Sun, 7 May 2000, Mike Smith wrote: Since there's a sysctl you can use to turn the former off, perhaps it would have been smart to take a few seconds to narrow it down? Those changes wouldn't have affected ICMP, but we tried that anyway. The problem was that the code changed the expression ~sum 0x to sum == 0x ? sum : ~sum 0x. I had just found and fixed this locally when I noticed Paul Saab committed the same functional fix. Well, it's nice to know that we can get multiple people finding the problem as soon as the symptoms of the breakage are known :) -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: rc.d startup scripts
Will Andrews wrote: Hello, I've noticed an inconsistency among our ports. It seems that not every port that installs rc.d startup scripts includes methods to not only startup, but also shutdown and/or restart, where appropriate. (Sent to -ports for ports hackers' opinions.) Dave already mentioned the right targets, and I agree that it would be nice to have this. I have some sample stuff that I've used for quite a while that I'd be happy to clean up and share as templates. One thing we can do which will improve the situation right off the bat is standardize the code that does the pid-finding, etc. and then source those functions in each control script. Shouldn't this sort of thing be standardized? And maybe a similar method be integrated into /etc/rc for restarting base system daemons? (Sent to -current for src hackers' opinions.) I'm going to reply to the system part of this too, replies to this thread should split off to -current. I have a design in mind for a new rc system that uses scripts with "start, stop, status" operators to both upgrade and downgrade services, where "services" are defined as groups of daemons/programs that work together. For example, "nfs" would be an example of a service, which would be subdivided into client and server, etc. Unfortunately, due to the way work is going right now I haven't been left with any time for big projects of this nature. My plan was to start small with the daemons that don't have a lot of dependencies, then grow the system up through the top. If anyone wants more details about my ideas on this line, just let me know. Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Sun, May 07, 2000 at 04:39:16PM +0200, Christian Weisgerber wrote:
OpenBSD only changed "rmt" to "rst" ("rsa" for us)
Just "sa" for us -- "sa" is now a raw device and "rFOO" use is
depreciated.
We had this argument the other day, and you clearly didn't understand.
We have three devices for each tape drive: rsaX, ersaX and nrsaX.
The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix
for disk devices. Please read the sa(4) manpage prior to its' corruption
by a well-meaning but entirely ignorant committer. (Fixed, btw.)
--
\\ Give a man a fish, and you feed him for a day. \\ Mike Smith
\\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED]
\\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
LINT broken. (in_cksum changes)
Is it only me that ever compiles LINT? The checksum changes went in a few days ago. Please, people, when you move code around or change a function that is used in more than a fixed set of files, compile LINT. If unsure, compile LINT. It's an extra five minutes, but well worth it. linking kernel fil.o: In function `fr_tcpsum': fil.o(.text+0xf47): undefined reference to `in_cksum' ip_fil.o: In function `send_reset': ip_fil.o(.text+0xd7d): undefined reference to `in_cksum' ip_fil.o: In function `ipfr_fastroute': ip_fil.o(.text+0x10f1): undefined reference to `in_cksum' ip_fil.o(.text+0x1316): undefined reference to `in_cksum' ip_fil.o(.text+0x1380): undefined reference to `in_cksum' ip_mroute.o(.text+0x19d6): more undefined references to `in_cksum' follow I just couldn't be bothered to fix it. Nick -- [EMAIL PROTECTED] [EMAIL PROTECTED] USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Sun, 7 May 2000, Doug Barton wrote: # Ok, here are some silly questions. Did you create a private key for # this server, did you encrypt your cert with it, and is that .key file # pointed to in your httpd.conf config file? SSLCertificateKeyFile is what # you're looking for. http://www.modssl.org/related/ has some really good # resources for this, and their FAQ has step by step instructions for # creating and testing keys and certs that may help you track down where # in the process it's getting lost. I did create a key for my server with the following command ssh-keygen -f /etc/ssh/ssh_host_key I didn't encrypt a cert with it. This is on a test box and up until a few days ago the only steps I ever had to take were to install one of the apache13-*ssl ports, crank up apache, and it just worked. Of course this could be where I've gone astray, as it appears this no longer works. :) I've been using the 'Snake Oil' certs that come with these ports up until now, since the box is behind a firewall and not in production yet. # Also, did you install the openssl port, or are you using the openssl # that is part of the base in 4.0+? I vaguely remember you saying that you # were using the port. If so, cd to /usr/local/openssl and cp # openssl.cnf.sample to openssl.cnf. I'm not using the port. I'm using the bits that come with -current (and 4.0 on another box). At Kris' suggestion I did copy over an /etc/ssl/openssl.cnf file but that didn't seem to help with the problem I'm having. :( Thanks. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
On Sun, 7 May 2000, Steve Price wrote: # Then: # # dumpasn1 file.der root@bonsai(/usr/local/etc/apache/ssl.key)# dumpasn1 server.key Nope, this is the .pem-encoded version. You need to decode it to .der using: openssl asn1parse -in server.key -out server.der before running dumpasn1 on it. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: RSA decrypt problems
Steve Price wrote: On Sun, 7 May 2000, Doug Barton wrote: # Ok, here are some silly questions. Did you create a private key for # this server, did you encrypt your cert with it, and is that .key file # pointed to in your httpd.conf config file? SSLCertificateKeyFile is what # you're looking for. http://www.modssl.org/related/ has some really good # resources for this, and their FAQ has step by step instructions for # creating and testing keys and certs that may help you track down where # in the process it's getting lost. I did create a key for my server with the following command ssh-keygen -f /etc/ssh/ssh_host_key ERrr... that's for ssh only. I didn't encrypt a cert with it. This is on a test box and up until a few days ago the only steps I ever had to take were to install one of the apache13-*ssl ports, crank up apache, and it just worked. Of course this could be where I've gone astray, as it appears this no longer works. :) I'm not familiar with those ports, so I can't speak intelligently about them, however I've looked over the mod_ssl stuff, and they have pre-configured a whole certificate authority chain with the snake oil stuff so that you can test your installation of the binary(ies). However, that does you a disservice down the road when you have to do it for real. # Also, did you install the openssl port, or are you using the openssl # that is part of the base in 4.0+? I vaguely remember you saying that you # were using the port. If so, cd to /usr/local/openssl and cp # openssl.cnf.sample to openssl.cnf. I'm not using the port. I'm using the bits that come with -current (and 4.0 on another box). At Kris' suggestion I did copy over an /etc/ssl/openssl.cnf file but that didn't seem to help with the problem I'm having. :( Well, it'll help, but you have to get down the road a bit before you notice how it helps you. :) Take a look at http://www.modssl.org/docs/2.6/ssl_faq.html#ToC28 which describes the process of creating real certificates. If this is to be a "real" secure server that will be visible on the internet, you'll want to follow those instructions pretty much to the letter (assuming you're using mod_ssl, or one of its ports). The way x509 works for secure servers is that you first create a "key" that is your server's unique signature. This is similar to the identity files created with ssh-keygen. Then you create a certificate that contains what is essentially your public key (actually a combination of your certificate's public key and your identity key's public part). You sign this certificate with your server's identity key, then send it to a certificate authority (read, "Verisign") which signs the certificate with its public key. Then you install the doubly signed certificate. The client browser is able to use the information in your certificate to A) confirm with the CA that your certificate really came from you, B) encrypt an offer of a session key/cipher for that session, and C) decrypt your acceptance of that offer. I'm oversimplifying this a bit, hopefully you get the idea. There is more info on the web pages I sent in my previous e-mail. HTH, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
make release failure during ports
fyi... === Creating README.html for tkrat-1.2 === mail/tkrat2 === Creating README.html for tkrat-2.0b9 === mail/wanderlust-emacs Error: Bad value of EMACS_PORT_NAME: emacs. Valid values are: Emacs family: emacs19 mule19 emacs20 XEmacs family: xemacs19 xemacs20 xemacs21 xemacs21-mule *** Error code 1 If no-one pops up with a "I know what's going on" I'll see if I can figure it ou. -John To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
Mike Smith [EMAIL PROTECTED] wrote: The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix for disk devices. I'd like to see some backup for this assertion. Historically, BSD (up to 4.4) used to have mt block device, rewinding nmt block device, non-rewinding rmt character device, rewinding nrmt character device, non-rewinding which leaves little room to doubt. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
Mike Smith [EMAIL PROTECTED] wrote: The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix for disk devices. I'd like to see some backup for this assertion. Historically, BSD (up to 4.4) used to have mt block device, rewinding nmt block device, non-rewinding rmt character device, rewinding nrmt character device, non-rewinding which leaves little room to doubt. Interesting. I've never encountered a tape device to which the buffer cache was applicable, except for the mythical SunOS swap-to-tape story, and the 'r' has always been "rewind" for as long as I can remember. We haven't made non-'r' devices since MAKEDEV rev 1.5. -- \\ Give a man a fish, and you feed him for a day. \\ Mike Smith \\ Tell him he should learn how to fish himself, \\ [EMAIL PROTECTED] \\ and he'll hate you for a lifetime. \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: make release failure during ports
"John W. DeBoskey" wrote: fyi... === Creating README.html for tkrat-1.2 === mail/tkrat2 === Creating README.html for tkrat-2.0b9 === mail/wanderlust-emacs Error: Bad value of EMACS_PORT_NAME: emacs. Valid values are: Emacs family: emacs19 mule19 emacs20 XEmacs family: xemacs19 xemacs20 xemacs21 xemacs21-mule *** Error code 1 If no-one pops up with a "I know what's going on" I'll see if I can figure it ou. -John John, Would this have anything to do with the ports upgrade recently? I notice I get errors trying to make some things, so I've just grabbed the tarball and done the job myself. I've found someimes I get an error: # make install -: You need to define PORTNAME and PORTVERSION instead of PKGNAME. (This port is too old for your bsd.port.mk, please update it to match your bsd.port.mk.) *** Error code 1 Yeah, I've done the cvsup thing several times, but there are still some ports with this error. Should I be pointing them out to port maintainers or is this an on-going fix due to the change? I'm not one claiming "I know what's going on" as you had hoped. I'm just some putz who has had a problem with some ports recently. -Otter ./~sig files available for an additional fee; and NO! I don't Yahoo! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
'pkg_delete m4-1.1/' hangs
Jordan,
I've been experiencing a problem with 'pkg_delete m4-1.1/'
hanging. Attached is a patch that fixes this problem, cleans
the code up a bit (IMHO), and still covers all the corner
cases like 'pkg_delete /var/db/pkg/m4-1.1//./..///' like the
old code did. :)
BTW, it appears pkg_info had a similar affliction so I fixed
it too while I was here.
-steve
Index: delete/main.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/delete/main.c,v
retrieving revision 1.17
diff -u -r1.17 main.c
--- delete/main.c 2000/02/18 07:00:01 1.17
+++ delete/main.c 2000/05/07 23:45:05
@@ -83,24 +83,19 @@
/* Get all the remaining package names, if any */
while (*argv) {
-if ((pkgs_split = rindex(*argv, (int)'/')) != NULL) {
-while (!isalpha(*(pkgs_split + 1))) {
-*pkgs_split = '\0';
-if ((pkgs_split = rindex(*argv, (int) '/')) == NULL)
-pkgs_split = *argv;
-}
-if (pkgs_split != NULL) {
-if (*pkgs_split == '/')
-pkgs_split++;
-*pkgs = pkgs_split;
-pkgs++;
-}
-}
-else {
-*pkgs = *argv;
-pkgs++;
-}
-argv++;
+ while ((pkgs_split = rindex(*argv, (int)'/')) != NULL) {
+ *pkgs_split++ = '\0';
+ /*
+* If character after the '/' is alphanumeric, then we've found the
+* package name. Otherwise we've come across a trailing '/' and
+* need to continue our quest.
+*/
+ if (isalpha(*pkgs_split)) {
+ *argv = pkgs_split;
+ break;
+ }
+ }
+ *pkgs++ = *argv++;
}
/* If no packages, yelp */
Index: info/main.c
===
RCS file: /home/ncvs/src/usr.sbin/pkg_install/info/main.c,v
retrieving revision 1.22
diff -u -r1.22 main.c
--- info/main.c 2000/01/18 01:45:54 1.22
+++ info/main.c 2000/05/07 23:46:31
@@ -144,30 +144,20 @@
Flags = SHOW_COMMENT | SHOW_DESC | SHOW_REQBY;
/* Get all the remaining package names, if any */
-while (*argv)
-{
-if( (pkgs_split = rindex(*argv, (int) '/')) != NULL )
-{
-while( !isalpha(*(pkgs_split+1)) )
-{
-*pkgs_split = '\0';
-if ( (pkgs_split = rindex(*argv, (int) '/')) == NULL)
-pkgs_split = *argv;
-}
-if(pkgs_split != NULL)
-{
-if (*pkgs_split == '/')
-pkgs_split++;
-*pkgs = pkgs_split;
-pkgs++;
-}
-}
-else
-{
-*pkgs = *argv;
-pkgs++;
-}
-argv++;
+while (*argv) {
+ while ((pkgs_split = rindex(*argv, (int)'/')) != NULL) {
+ *pkgs_split++ = '\0';
+ /*
+* If character after the '/' is alphanumeric, then we've found the
+* package name. Otherwise we've come across a trailing '/' and
+* need to continue our quest.
+*/
+ if (isalpha(*pkgs_split)) {
+ *argv = pkgs_split;
+ break;
+ }
+ }
+ *pkgs++ = *argv++;
}
/* If no packages, yelp */
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
On Sunday, 7 May 2000 at 16:48:36 -0700, Mike Smith wrote: Mike Smith [EMAIL PROTECTED] wrote: The 'r' prefix for tape devices is entirely unrelated to the 'r' prefix for disk devices. I'd like to see some backup for this assertion. Historically, BSD (up to 4.4) used to have mt block device, rewinding nmt block device, non-rewinding rmt character device, rewinding nrmt character device, non-rewinding which leaves little room to doubt. Interesting. I've never encountered a tape device to which the buffer cache was applicable, except for the mythical SunOS swap-to-tape story, and the 'r' has always been "rewind" for as long as I can remember. I suspect that's an assumption on your part. I think we've come up with enough man pages to support naddy's statement. We haven't made non-'r' devices since MAKEDEV rev 1.5. For good reasons :-) Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Undocumented tape devices in pax(1)
Greg Lehey [EMAIL PROTECTED] wrote: I suspect that's an assumption on your part. I think we've come up with enough man pages to support naddy's statement. Which, btw, was drawn from inspection of MAKEDEV in the various 4.xBSD releases in the CSRG archives (Kirk's CD set). Personally, I take that as an authoritative source. -- Christian "naddy" Weisgerber [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
FreeBSD 4.0-RELEASE does the gratuitous ARP when ifconfig'ing an alias: fenestro# ifconfig de1 1.2.3.5 alias 18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: arp who-has 1.2.3.5 tell 1.2.3.5 FreeBSD 3.4-STABLE also does: mango# ifconfig xl0 135.197.2.250 netmask 255.255.255.255 alias 18:39:12.509125 0:10:4b:cc:83:5f Broadcast arp 42: arp who-has 135.197.2.250 tell 135.197.2.250 I'm not sure what this says; it's entirely possible that there are conditions under which it doesn't or it fails for some reason. For example, there was a certain failure mode with sending multicast leave messages; the packet would be sent to the chip to be sent and then the multicast filter would be changed causing the chip to reset and lose the packet that's currently being transmitted. Adding an alias shouldn't cause the chip to be reset so that's not likely to be the exact problem, but perhaps something similar is happening. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de Rahul On Sun, 7 May 2000, Bill Fenner wrote: fenestro# ifconfig de1 1.2.3.5 alias 18:35:47.269471 0:40:5:42:d6:de Broadcast arp 42: arp who-has 1.2.3.5 tell 1.2.3.5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de The ARP processing specified in RFC 826 says that if you have an entry for the source IP address you update the hardware address no matter what the opcode is (i.e. you can update your tables due to a request). Every IP stack I've seen implements gratuitous ARP by sending a broadcast request for itself. In normal ARP operation, replies are unicast so conceivably an implementation that doesn't expect a broadcast reply might drop it. Requests are normally broadcasted, and the ARP processing rules cause broadcasted requests to update existing tables, so a broadcasted request is a better choice for a gratuitous arp. tcpdump hides too much information in an attempt to make things look pretty; it doesn't show the fact that the MAC information is included in a gratuitous ARP. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 'pkg_delete m4-1.1/' hangs
On Sun, 7 May 2000, Garrett Wollman wrote: # It wouldn't cover the particular obscure case, but this is the sort of It was a pretty bizarre case, but the old code did cover this. Not saying whether I think it to be correct or not but... :) # thing that SUSv2's basename(3) would be appropriate for. I have an # implementation waiting in the wings Cool. I'd like to see a fix get into RELENG_[34] and HEAD so having a fix that doesn't require a new libc is probably more appropriate for the RELEASE'd branches at least. -steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gratuituous arp for multiple IP addresses
Ok, I stand corrected. Rahul On Sun, 7 May 2000, Bill Fenner wrote: By "gratuituous arp" I was really saying "gratuitous arp reply". The machine needs to send a packet of the type arp reply 1.2.3.5 is-at 0:40:5:42:d6:de The ARP processing specified in RFC 826 says that if you have an entry for the source IP address you update the hardware address no matter what the opcode is (i.e. you can update your tables due to a request). Every IP stack I've seen implements gratuitous ARP by sending a broadcast request for itself. In normal ARP operation, replies are unicast so conceivably an implementation that doesn't expect a broadcast reply might drop it. Requests are normally broadcasted, and the ARP processing rules cause broadcasted requests to update existing tables, so a broadcasted request is a better choice for a gratuitous arp. tcpdump hides too much information in an attempt to make things look pretty; it doesn't show the fact that the MAC information is included in a gratuitous ARP. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
