On Fri, Jun 18, 1999 at 11:07:39AM -0700, Studded wrote:
# No action on this in -current for a few days, so let's try
# hackers. In response to some suggestions I tried raising the number of
# nfsiod's to 20 (the max) and increasing the sysctl cache value to 10,
# still no joy.
#
Skipped
Does anybody know what /usr/src/lib/libss/ is? There isn't a manpage for
it, and viewing the source I still can't figure out what it is other than
it came from MIT (Athena).
--
-- David(obr...@nuxi.com -or- obr...@freebsd.org)
To Unsubscribe: send mail to majord...@freebsd.org
with
Guess what... I've got a disk where the partition table and the disklabel has
mysteriously disappeared! Oops.
I've reconstructed the partition table, and now need to partition the disklabel.
If I mount /dev/wd2s1c I get the root (/) partition back, although the size
is obviously bogus in the
on another note, LIBWRAP_INTERNAL looks like it must be defined for
internal services to be wrapped, yet it is not defined during freebsd's
compile -- only LIBWRAP is. yet freebsd's inetd man page says that internal
services may be wrapped. since it is not currently so by default, perhaps
On Sun, 20 Jun 1999 17:49:59 MST, Aaron Smith wrote:
unfortunately incoming telnet was still denied. at first i tried
HUPping inetd to reread the hosts.allow, but after looking at the
source it appears to re-read its information each time hosts_access is
called. has anyone else had problems
Hi,
I would like to set up a packet filter which could be dynamically
updated if some special events occur. (like someone joining a multicast
group)
I tried bpf but I can't put variables in the filter, only constants.
With a variable I get : initializer for insns[5].k is not constant
Do you
There was a bug in inetd in which ment that if you HUPed inetd it could
get confuesed about the name of the services. This is probably what you
are seeing. Sheldon has just committed a fix for this.
The wrapping of internal services isn't quite working properly yet. Sheldon
has committed a
Thomas Good t...@nrnet.org writes:
Many conf tasks remain non-trivial as compared to BSD or Linux due
to inexpertise on SCO's end...as the red Sytem Admin Handbook once
stated (Neveth, Snyder et al.) SCO Unix* is `perverse'.
Nemeth, Snyder, Seebass, Hein.
DES
--
Dag-Erling Smorgrav -
this might ease life to those who want to replace ipfw with ipfilter
for dummynet or similar things, if nothing else.
Thank you, Luigi. Could you please help me with some basics?
...
what i do in dummynet is to queue the packet (wheter it comes from
ip_input() or ip_output() makes no
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David and I would like to see finished off.
It's just that we'd like it
Josef Karthauser wrote:
Guess what... I've got a disk where the partition table and the disklabel has
mysteriously disappeared! Oops.
I've reconstructed the partition table, and now need to partition the
disklabel.
Wow, you're probably the first person ever to do that, unlucky you.
On 21 Jun 1999, Dag-Erling Smorgrav wrote:
Thomas Good t...@nrnet.org writes:
Many conf tasks remain non-trivial as compared to BSD or Linux due
to inexpertise on SCO's end...as the red Sytem Admin Handbook once
stated (Neveth, Snyder et al.) SCO Unix* is `perverse'.
Nemeth, Snyder,
Thomas Good t...@nrnet.org writes:
The part that compares system initialisation is especially useful.
I use both getty and ttymon and the book does a good job comparing
the two strategies...I wish they'd do a new edition. I like
Aeleen Frisch (SP? ;-)
You got that one right :)
In message 19990621110303.a7...@walton.maths.tcd.ie, David Malone writes:
wrapped (and it isn't possible to wrap tcp nowait services even with tcdp).
Is that what you meant to say, or am I getting confused? Did you mean udp,
or wait?
Of course - I ment tcp wait services.
David.
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David and I would like to see finished off.
I got one person who
On Mon, 21 Jun 1999 14:13:49 +0100, David Malone wrote:
I got one person who suggested a flag in inetd.conf which could disable
wrapping for a service. This seems like quite a good idea if we can come
up with an acceptable syntax for the flag.
What I have in mind is a -w option. Specified
On Mon, Jun 21, 1999 at 02:13:49PM +0100, David Malone wrote:
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David
I notice that v1.10 is up in -current...does this patch still apply?
Dennis
At 06:58 PM 6/19/99 +0200, Robert Nordier wrote:
Dennis wrote:
F1: FreeBSD
F2: LINUX
F3: FreeBSD
F3 is a non-bootable file system...is there a way to get the boot manager
to only display F1 and F2?
At the
On Mon, Jun 21, 1999 at 02:26:35PM +0100, Dom Mitchell wrote:
inetd.conf is one of those things, like newsyslog.conf which is long
past due for an overhaul...
Some would say the same for inetd. Without wanting to start a flame war,
tcpserver (part of the sysutils/ucspi-tcp port) has some
I notice that v1.10 is up in -current...does this patch still apply?
Dennis
v1.10 is just a variation on this patch, with support for dynamic
configuration using boot0cfg(8) rather than by way of a build option.
For instance
boot0cfg -m 0xd da0
will cause the second partition to be
Shaun Jurrens wrote:
Studded, you might try to look at /usr/share/doc/handbook/nfs.html. It might
help to use a high quality network card and maybe track the traffic between
the boxes to see if the mentioned packet problems show up.
It's an Intel motherboard with an Intel Pro 100
Sheldon Hearn wrote:
On Mon, 21 Jun 1999 14:13:49 +0100, David Malone wrote:
I got one person who suggested a flag in inetd.conf which could disable
wrapping for a service. This seems like quite a good idea if we can come
up with an acceptable syntax for the flag.
What I have in mind
Since y'all are discussing inetd.conf, here is something else to
consider.
Doug
Original Message
Subject: Re: misc/11796: Bad lines in 3.2-RELEASE inetd.conf
Date: Wed, 16 Jun 1999 12:55:43 -0700 (PDT)
From: Studded stud...@gorean.org
To: Dag-Erling Smorgrav
On Mon, 21 Jun 1999 07:58:58 MST, Doug wrote:
When exactly was it made the default? Prior to 3.2-Release, or after?
It's never (ok, rarely) too late to undo a bad decision. If the change
happened after the latest -Release, by all means, back it out.
Cvsweb says it happened
On Mon, 21 Jun 1999 08:02:14 MST, Doug wrote:
The service-name entry is the name of a valid service in the file
/etc/services. For ``internal'' services (discussed below), the
service name must be the official name of the service (that is, the first
entry in /etc/services).
Read the
A copy of my reply has been bounced to freebsd-gnats-submit, since the
address in the forwarded headers was misspelled.
Ciao,
Sheldon.
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
On Mon, 21 Jun 1999, Sheldon Hearn wrote:
On Mon, 21 Jun 1999 08:02:14 MST, Doug wrote:
The service-name entry is the name of a valid service in the file
/etc/services. For ``internal'' services (discussed below), the
service name must be the official name of the service (that is,
On Mon, 21 Jun 1999 11:12:26 MST, Doug wrote:
Can you point out exactly what part of the man page that you are
referring to that contradicts what the inetd man page says? Have you
checked the actual code for inetd to verify that it will work with
services aliases?
Certainly. From
Doug d...@gorean.org writes:
In my experience, and in the experience of the PR poster it *is*
necessary to use the canonical name of the service, however if you can
check the code, test it thoroughly and determine that inetd works
perfectly well with aliases, then feel free to change the
On Mon, 21 Jun 1999, Sheldon Hearn wrote:
On Mon, 21 Jun 1999 11:12:26 MST, Doug wrote:
Can you point out exactly what part of the man page that you are
referring to that contradicts what the inetd man page says? Have you
checked the actual code for inetd to verify that it will work
Doug d...@gorean.org writes:
You are really really missing my point here, so I will state it
again. If you have carefully examined the code for *every* case of *every*
internal service, and you have tested it thoroughly, and you are 100% sure
that the man page is in error, change the man
On Mon, 21 Jun 1999 11:42:46 MST, Doug wrote:
[...] there is an outstanding PR that shows it
doesn't work for everybody, and there is absolutely no justification for
leaving an example in the conf file that conflicts with the man page.
Doug, I'm annoyed that you ignored the most important
On 21 Jun 1999, Dag-Erling Smorgrav wrote:
Doug d...@gorean.org writes:
You are really really missing my point here, so I will state it
again. If you have carefully examined the code for *every* case of *every*
internal service, and you have tested it thoroughly, and you are 100% sure
By the way, I'd recommend all -CURRENT users, after making world, make a
new copy of pidentd. The code to grovel through the kernel to find socket
info is MUCH less sickening now, so identd is less of a performance hit
and less likely to fail due to race conditions.
Brian Fundakowski Feldman
On Mon, 21 Jun 1999, Sheldon Hearn wrote:
On Mon, 21 Jun 1999 11:42:46 MST, Doug wrote:
[...] there is an outstanding PR that shows it
doesn't work for everybody, and there is absolutely no justification for
leaving an example in the conf file that conflicts with the man page.
* David O'Brien (obr...@nuxi.com) [990621 10:38]:
Does anybody know what /usr/src/lib/libss/ is? There isn't a manpage for
it, and viewing the source I still can't figure out what it is other than
it came from MIT (Athena).
Apparantly David it came from the SIPB at MIT and more specifically
Doug d...@gorean.org writes:
It doesn't work with the conf file that came with the system, but
it does work if I change the conf file to match the documentation is
pretty good content in my book. Obviously he doesn't include information
on how to repeat the problem in a verifiable way,
Hi,
I asked this question on freebsd-questions a couple of weeks ago, got a
couple of answers and then I was away from work for a couple of weeks.
One answer that I got suggested that I ask this forum, so here goes:
I have a standard Dell Poweredge 2300 running FreeBSD 3.1.
When running cvsup
I've heard about something similar (a consistent crash in crfree during
cvsup), and don't know the reason, but an upgrade to 3.2 solved the
problem.
On Mon, 21 Jun 1999, Kevin Quinlan (UK) wrote:
Hi,
I asked this question on freebsd-questions a couple of weeks ago, got a
couple of answers
On 21-Jun-99 David Malone wrote:
Folks, public feedback on the following portion of David's mail would be
much appreciated. Since resolution of UDP wrapping would bring about the
execution of the we want tcpd campaign, it's obviously something that
both David and I would like to see finished
On 21 Jun 1999, Dag-Erling Smorgrav wrote:
Doug d...@gorean.org writes:
It doesn't work with the conf file that came with the system, but
it does work if I change the conf file to match the documentation is
pretty good content in my book. Obviously he doesn't include information
on
There are several sorts of messages that get logged by the kernel where it
would be Really Nice if the messages were timestamped.
If syslogd is up and running (and the data gets stored before the system
dies) there is a good chance that syslogd will timestamp the messages.
One way to do this
If syslogd is up and running (and the data gets stored before the system
dies) there is a good chance that syslogd will timestamp the messages.
I don't think this would be a good idea. Syslogd does a fine job of
adding timestamps; there aren't any really relevant cases in which
having
Apparently there are places that log via dmesg instead of via syslog.
The primary intention here is to have the messages that are in the dmesg
output have timestamps.
And I have had crashes/panics where the syslog information just didn't get
out in time (but I might be mistaken on this one).
Apparently there are places that log via dmesg instead of via syslog.
No.
The primary intention here is to have the messages that are in the dmesg
output have timestamps.
No.
And I have had crashes/panics where the syslog information just didn't get
out in time (but I might be mistaken
Apparently there are places that log via dmesg instead of via syslog.
No.
I should have been clearer here; anything that writes to the kernel
message buffer is also passed to syslog.
The primary intention here is to have the messages that are in the dmesg
output have timestamps.
Apparently there are places that log via dmesg instead of via syslog.
No.
Perhaps I'm missing something. I know that the messages I get via nfs_msg
in nfs_socket.c I haven't been seeing in my syslogs, and when they show up
in the dmesg output they are not timestamped.
Somebody was
I just checked - I have kern.debug in my syslog.conf, so it's clear that
these messages are either not being logged via syslog (either that or I
have been missing them in my logs - possible, but I doubt it).
H
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe
Sheldon Hearn wrote:
On Wed, 09 Jun 1999 23:14:47 EST, Dan Nelson wrote:
Install the linux_devel port and resign yourself to building Linux
executables whenever you have to talk to Oracle.
We've _just_ been through this whole nightmare and resigned ourselves to
using a Sparc for talking
Apparently there are places that log via dmesg instead of via syslog.
No.
Perhaps I'm missing something. I know that the messages I get via nfs_msg
in nfs_socket.c I haven't been seeing in my syslogs, and when they show up
in the dmesg output they are not timestamped.
Somebody
50 matches
Mail list logo
