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
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
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
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
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
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
-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
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
"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
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
-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
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
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
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
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
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
[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.
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
#
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
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
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
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
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
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.
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
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
#
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
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
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,
"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
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
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
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
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
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
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
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
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
38 matches
Mail list logo
