Re: man reads /etc/rc.conf?

1999-11-10 Thread A . Leidinger

On  9 Nov, Archie Cobbs wrote:
 [EMAIL PROTECTED] writes:
 (101) netchild@ttyp2  man -k adadadad
 cat: /etc/isdn/connect.parameters: Permission denied
 adadadad: nothing appropriate

 (102) netchild@ttyp2  grep cat /etc/rc.conf.local
 spppconfig_isp0="`cat /etc/isdn/connect.parameters`"

 Is this just my system or is man really reading rc.conf(.local)?
 
 ktrace(1) would tell for sure..

/usr/bin/apropos contains:
---snip---
# If possible check global system configuration file for additional
# man locales installed
if [ -r /etc/defaults/rc.conf ] ; then
. /etc/defaults/rc.conf
elif [ -r /etc/rc.conf ] ; then
. /etc/rc.conf
fi
---snip---

and /etc/defaults/rc.conf:
---snip---
man_locales="NO"# space separated list of man locales (or NO)
---snip---

Do we have to live with this or is it subject to change (it gives me a
bad taste to have rc.conf sourced everytime apropos is used)? What about
making it an environment variable (just set it in login.conf) or
enhancing /etc/manpath.config (BTW: everithing is named *.conf except
manpath.config)?

Bye,
Alexander.

-- 
   I believe the technical term is "Oops!"

http://netchild.home.pages.de  A.Leidinger+Home @ WJPServer.CS.Uni-SB.de
  Key fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: man reads /etc/rc.conf?

1999-11-10 Thread Oliver Fromme

[EMAIL PROTECTED] wrote in list.freebsd-current: you wrote (9 Nov 
1999 21:13:42 +0100):
  (101) netchild@ttyp2  man -k adadadad
  cat: /etc/isdn/connect.parameters: Permission denied
  adadadad: nothing appropriate
  
  (102) netchild@ttyp2  grep cat /etc/rc.conf.local
  spppconfig_isp0="`cat /etc/isdn/connect.parameters`"

Using command substitution in /etc/rc.conf{,.local} is NOT
officially supported.  I think it should have always been
clear that there should _only_ be plain variable assignments.
That's probably just because you never know which programs
try to read them.

  Is this just my system or is man really reading rc.conf(.local)?

I think that's perfectly legal.

Regards
   Oliver

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:[EMAIL PROTECTED])

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
 (Terry Pratchett)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



PC-Card ejection(suspend) with 4-current

1999-11-10 Thread MIHIRA Sanpei Yoshiro

Warner Losh [EMAIL PROTECTED] wrote:
Card ejection (including suspend) doesn't work, which I'll try to fix
at some point, but I might not get around to fixing that before new
pccard work begins.  I think it would be easy to mostly fix (like the
old code mostly worked) with more thought on how to do this (see -arch
for a message related tot his problem).

  I think FreeBSD-4-current does not support PC-Card suspend yet.
  I read and diffed old code and current code.  But I did not find
out anything

  Does someone create patch for this problem?

# or we need to rewrite and maintain pccard code(/sys/dev/pccard)?

Thanks in advance

MIHIRA Sanpei Yoshiro
Yokohama, Japan.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: man reads /etc/rc.conf?

1999-11-10 Thread Alexander Leidinger

On 10 Nov, Oliver Fromme wrote:

 Using command substitution in /etc/rc.conf{,.local} is NOT
 officially supported.  I think it should have always been
 clear that there should _only_ be plain variable assignments.

But with i4b you have to specify a username-password pair in rc.conf
(spppconfig_isp0) and I didn´t want to show it to every user (rc.conf is
u+rw,g+r,o+r for reasons you mention).

 That's probably just because you never know which programs
 try to read them.

Ok, so we (root of machine xxx) have either a security hole
(dial-in-passwd visible to everyone) or we have to forget the
recommended way of doing it.

   Is this just my system or is man really reading rc.conf(.local)?
 
 I think that's perfectly legal.

Yes, but is it necessary?

Bye,
Alexander.

-- 
 Columbus had a fourth ship. It sailed over the edge.

http://netchild.home.pages.de  A.Leidinger+Home @ WJPServer.CS.Uni-SB.de
  Key fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: man reads /etc/rc.conf?

1999-11-10 Thread Daniel C. Sobral

[EMAIL PROTECTED] wrote:
 
  (101) netchild@ttyp2  man -k adadadad
  cat: /etc/isdn/connect.parameters: Permission denied
  adadadad: nothing appropriate
 
  (102) netchild@ttyp2  grep cat /etc/rc.conf.local
  spppconfig_isp0="`cat /etc/isdn/connect.parameters`"
   ^^^
Calling programs from any of the rc.conf files is considered evil
and it's looked down on.

 /usr/bin/apropos contains:
 ---snip---
 # If possible check global system configuration file for additional
 # man locales installed
 if [ -r /etc/defaults/rc.conf ] ; then
 . /etc/defaults/rc.conf
 elif [ -r /etc/rc.conf ] ; then
 . /etc/rc.conf
 fi
 ---snip---
 
 and /etc/defaults/rc.conf:
 ---snip---
 man_locales="NO"# space separated list of man locales (or NO)
 ---snip---
 
 Do we have to live with this or is it subject to change (it gives me a
 bad taste to have rc.conf sourced everytime apropos is used)? What about
 making it an environment variable (just set it in login.conf) or
 enhancing /etc/manpath.config (BTW: everithing is named *.conf except
 manpath.config)?

Apropos is not the fastest of the programs. Sourcing rc.conf most
likely takes a very small time compared to it's total execution
time.

--
Daniel C. Sobral(8-DCS)
[EMAIL PROTECTED]
[EMAIL PROTECTED]

What y'all wanna do?
Wanna be hackers? Code crackers? Slackers
Wastin' time with all the chatroom yakkers?


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: HPT366 and FreeBSD-CURRENT ?

1999-11-10 Thread Søren Schmidt

It seems Alexandr Listopad wrote:
 Hello!
 What about subj?
 
 Did FreeBSD support HPT366 in the CURRENT???

Yes it does.

 And if "yes" then what shall I do for it???

Use the ata driver.

 If I boot from floppies - then error and reboot after 15sec, and don't
 find this drive on IDE... what shall I do???

Uhm, I'm not sure I get the meaning here, is that for an install ??
If so the new ata driver isn't use in GENERIC just yet, you could
however test out the boot floppies I've put on ftp.freebsd.dk/pub/


-Søren


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: man reads /etc/rc.conf?

1999-11-10 Thread patl

On 10-Nov-99 at 06:59, Alexander Leidinger ([EMAIL PROTECTED])
wrote:  On 10 Nov, Oliver Fromme wrote:
 
  Using command substitution in /etc/rc.conf{,.local} is NOT
  officially supported.  I think it should have always been
  clear that there should _only_ be plain variable assignments.
 
 But with i4b you have to specify a username-password pair in rc.conf
 (spppconfig_isp0) and I didn´t want to show it to every user (rc.conf is
 u+rw,g+r,o+r for reasons you mention).
 
  That's probably just because you never know which programs
  try to read them.
 
 Ok, so we (root of machine xxx) have either a security hole
 (dial-in-passwd visible to everyone) or we have to forget the
 recommended way of doing it.

It looks to me as though the recommended way of doing it needs to
be changed.  How about putting the sppp setup in a separate script
in /usr/local/etc/rc.d ?  Or, put the script in /etc/isdn and add
that directory to the local_startups variable in rc.conf ?

Is this just my system or is man really reading rc.conf(.local)?
  
  I think that's perfectly legal.
 
 Yes, but is it necessary?

The whole rc setup isn't 'necessary'.  But it's damned useful
and convienient.  And so is the ability for arbitrary programs
and scripts to read and easily parse rc.conf to obtain system
wide defaults.


-Pat


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Nov 9 Snapshot boot floppy failure

1999-11-10 Thread Forrest Aldrich

Just tried installing a 4.0-current system from Nov 9
snapshot, on a DELL 6350, 3 18g drives, 512m RAM,

Got Signal Trap 12 while in kernel mode.  This happened
(each time) after it probed the CD drive.

I've installed previous 4.0 snaps on this platform without
incident.

FYI.



_F




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: No buffer space available errors

1999-11-10 Thread Bill Marquette

On Wed, 10 Nov 1999, Doug Ambrisko wrote:
 On one out of 8 machines, I ran into this problem.  My network is running
 at 100BaseTX.  I noticed that ifconfig showed OACTIVE flag set and I
 was running in autosense mode.  So I setup the media to 100BaseTX and now
 it works okay.
 
 My guess is the autosense gets confused sometimes.

Doug, thanks for the tip, I'll give that a try as I haven't been forcing
either card to 10Mbit or TP connections.  I have added to the mystery
however and this is aggravatingly puzzling.

In my previous message I had mentioned that walking away fromt he console
for any length of time would cause the machine to generate the "No buffer
space" errors.  Since then I've turned off my screensaver (Matrix from
KDE) and the system has stabilized completely; well almost completely.  I
can still duplicate the buffer situation and I've still seen it occur when
doing fairly high bandwidth (for cable, not for ethernet) file transfers.
If I can manage to bring the xfer rate up to around 100K/sec total between
inbound and outbound I experience the "Out of buffer" messages within a
couple minutes.  netstat -m doesn't show anything unusual.  I am going to
try removing both NMBCLUSTERS and NBUF from my config and just use a
maxusers of 128 and see how that goes.

--Bill




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: man reads /etc/rc.conf?

1999-11-10 Thread Alexander Leidinger

On 10 Nov, [EMAIL PROTECTED] wrote:

 Ok, so we (root of machine xxx) have either a security hole
 (dial-in-passwd visible to everyone) or we have to forget the
 recommended way of doing it.
 
 It looks to me as though the recommended way of doing it needs to
 be changed.  How about putting the sppp setup in a separate script
 in /usr/local/etc/rc.d ?  Or, put the script in /etc/isdn and add
 that directory to the local_startups variable in rc.conf ?

There´s already rc.isdn, we just have to find a name for the config file
(I´ve no problem to do it in my setup, I just want to have a official
way to close this security hole).

 Is this just my system or is man really reading rc.conf(.local)?
 I think that's perfectly legal.
 Yes, but is it necessary?
 
 The whole rc setup isn't 'necessary'.  But it's damned useful
 and convienient.  And so is the ability for arbitrary programs
 and scripts to read and easily parse rc.conf to obtain system
 wide defaults.

Sorry, I didn´t object to the rc setup, I just want to know why we
didn´t use manpath.config (yes, "man_locales" isn´t realy a
path-specifier, but it´s relatet to man  localized man-pages which are
stored in ´ManPathElement´/LocalePart/).
And I didn´t say it has to be changed (but we have to change the startup
of i4b).

Bye,
Alexander.

-- 
 Dead men tell no tales, unless you're in forensics.

http://netchild.home.pages.de  A.Leidinger+Home @ WJPServer.CS.Uni-SB.de
  Key fingerprint = 7423 F3E6 3A7E B334 A9CC  B10A 1F5F 130A A638 6E7E



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: HPT366 and FreeBSD-CURRENT ?

1999-11-10 Thread Vincent Poy

Greetings,

Just so everyone knows, the latest BIOSes for ABIT motherboards
and ABIT Controller cards with the HPT366 Controller as well as MS Drivers
can be found at:

http://140.113.153.55/stuff/ide_card/HighPoint/HPT366/index-e.htm


Cheers,
Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED]      __  
Unix Networking Operations - FreeBSD-Real Unix for Free / / / / |  / |[__  ]
GaiaNet Corporation - M  C Estate / / / /  | /  | __] ]  
Beverly Hills, California USA 90210   / / / / / |/ / | __] ]
HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Nov 9 Snapshot boot floppy failure (FOLLOW UP)

1999-11-10 Thread Forrest Aldrich

I backed to Nov 01 snapshot and the install went fine;
however it appears it's not writing out partition information
correctly.   We performed 3 installs, and went over each
step judiciously, and when you reboot after the install,
it complains about invalid parition information.



At 12:26 PM 11/10/99 -0500, Forrest Aldrich wrote:
Just tried installing a 4.0-current system from Nov 9
snapshot, on a DELL 6350, 3 18g drives, 512m RAM,

Got Signal Trap 12 while in kernel mode.  This happened
(each time) after it probed the CD drive.

I've installed previous 4.0 snaps on this platform without
incident.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: PC-Card ejection(suspend) with 4-current

1999-11-10 Thread Warner Losh

In message [EMAIL PROTECTED] MIHIRA
Sanpei Yoshiro-san writes: 
:   I think FreeBSD-4-current does not support PC-Card suspend yet.

Yes.  That's correct.  I broke it when I did my last batch of newbus
code.

:   I read and diffed old code and current code.  But I did not find
: out anything
:
:   Does someone create patch for this problem?

No yet.  I slightly rearranged the order and timing of events in the
eject (and suspend) paths of the code.  Effectively, I've managed to
make the device go away from a hardware point of view before I've
removed the device from the software tree and stopped delivering
interrupts to it, so it gets an interrupt once the hardware is gone.
I've diagnosed it this far, but haven't looked at the code to find out
why it is doing this or how to fix it.  I basically screwed up Nate's
efforts which made the suspend code 99% safe... :-(

I would welcome with open arms patches to fix this problem...

: # or we need to rewrite and maintain pccard code(/sys/dev/pccard)?

That's the real answer.  Anybody willing to help, please let me know.
I have probe/attach code for the pcic code (in /sys/dev/pcic) going,
but I've not hooked up the pccard stuff to it.  My work on this is
on hold for the moment until my Sony VAIO gets back from Sony...
Hopefully by Friday when I head off for the weekend...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: PC-Card ejection(suspend) with 4-current

1999-11-10 Thread Christopher Masto

On Wed, Nov 10, 1999 at 03:05:28PM -0700, Warner Losh wrote:
 : # or we need to rewrite and maintain pccard code(/sys/dev/pccard)?
 
 That's the real answer.  Anybody willing to help, please let me know.
 I have probe/attach code for the pcic code (in /sys/dev/pcic) going,
 but I've not hooked up the pccard stuff to it.  My work on this is
 on hold for the moment until my Sony VAIO gets back from Sony...
 Hopefully by Friday when I head off for the weekend...

I'm willing to try/test anything, but as I am stuck with enormous
amounts of work for the rest of the year, I can only spend minimal
time actually touching the code.

I'd love to see this fixed, though.  It's an incredible annoyance to
have to shut my laptop off instead of suspending.

As for the arguments about "safe" removal, let's not let the quest for
the perfect shed kill this; if the device has to be disabled before
removing it, so be it.. but right now it's not possible to remove a
pccard at all.
-- 
Christopher Masto Senior Network Monkey  NetMonger Communications
[EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net

Free yourself, free your machine, free the daemon -- http://www.freebsd.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: PC-Card ejection(suspend) with 4-current

1999-11-10 Thread Warner Losh

In message [EMAIL PROTECTED] Christopher Masto writes:
: I'd love to see this fixed, though.  It's an incredible annoyance to
: have to shut my laptop off instead of suspending.

Agreed.

: As for the arguments about "safe" removal, let's not let the quest for
: the perfect shed kill this; if the device has to be disabled before
: removing it, so be it.. but right now it's not possible to remove a
: pccard at all.

I think all that's required is moving a device_delete_child() call or
three...

Warner


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



subscribe

1999-11-10 Thread gllewis

subscribe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message



Re: Make release troubles

1999-11-10 Thread Annelise Anderson

There are a couple of things you can do if your make release
fails while trying to make the docs.

You could use "on demand" dialing for ppp so that it connects only
when it needs to (and hangs up after some period of inactivity) so
you're not connected for so long.  Making these ports is the only
part of a make release that requires fetching files.

You could also have the make release continue more or less where it
left off.  You do *not* want to start it over by typing "make release" 
in /usr/src/release, as this will delete what's already been done.
But you can chroot to the directory where the release is being built
and run the file "mk" in that directory.  This is a shell script 
that is created when you run "make release" in /usr/src/release, and
once the chroot directive is reached in the Makefile in /usr/src/release,
only what's in the chroot directory structure is relevant.  Running
"mk" from this directory should allow things to continue where they
left off, because this script incorporates the variables you decided
upon when you edited the Makefile in /usr/src/release and runs
the :doRELEASE target in Makefile in $CHROOTDIR/usr/src/release,
which records ("touch release.1", for example) what's been done.

An alternative is to define a target in /usr/src/release/Makefile
called (e.g.) release.0, and have it simply chroot to the directory
where you're building the release and run mk there.  You can then
define in mk any target you want to build in the Makefile in
$CHROOTDIR/usr/src/release, and then put this target in the 
Makefile.  This means you can continue where you left off by
typing "make release.0" in /usr/src/release.

By this time the ports distfiles will already have been copied to
$CHROOTDIR/usr/ports/distfiles, and anything in the /usr/ports/distfiles
directory or wherever you tell it to get the distfiles (/usr/ports/
distfiles.release in your case) will not be found.  If you need to
add a distfile, you need to put it in $CHROOTDIR/usr/ports/distfiles.  

A possible strategy before beginning the make release is to move the
existing /usr/ports/distfiles to a hold location, do "make install"
in /usr/ports/textproc/docproj, and hope that you in this way get all
the distfiles you need for the release.  You might have to deinstall
first so that it does go through the whole build process and gets all
the dependencies.  If you do this, you want to make sure your version
of the ports tree in /usr/ports is the same as the version you want
to build in "make release."  I personally think these little ports
like tidy are troublesome because the version numbers change so often;
so probably the best approach is to have an open connection during
the build of doc.1 so it can get anything you haven't yet gotten.

Annelise



On Sun, 7 Nov 1999, Marc Schneiders wrote:

 I have studied the Makefile. 
 I have searched the archives of the lists. 
 I have put the files necessary for the ports build for docproj during
 the make in a separate directory (/usr/ports/distfiles.release), 
 with no extra files there. 
 I have set this in the Makefile. Nevertheless this is what happened:
 
 touch release.2
 Making docs...
 ===  Extracting for docproj-1.1 
 [...]
 [...]
 [...]
 ===   Registering installation for sgmlformat-1.7
 ===   Returning to build of docproj-1.1
 ===   docproj-1.1 depends on executable: sgmlnorm - found
 ===   docproj-1.1 depends on executable: jade - found
 ===   docproj-1.1 depends on executable: tidy - not found
 ===Verifying install for tidy in /usr/ports/www/tidy
 ===  Extracting for tidy-0.9.99.1
  Checksum OK for tidy27sep99.tgz.  
 
 Here it just stopped (and had been waiting for 9 hours...). No error
 message, nothing. Machine was responding OK. No kernel messages, no
 messages. Nothing peculiar in top etc. So I tried something weird (in
 my eyes anyway) and kill -HUPped the PID. It continued. Great, well
 for a moment.
 
 ===  Patching for tidy-0.9.99.1
 ===  Applying FreeBSD patches for tidy-0.9.99.1
 ===  Configuring for tidy-0.9.99.1
 ===  Building for tidy-0.9.99.1
 cc -O -pipe -D__USE_MISC -c attrs.c
 cc -O -pipe -D__USE_MISC -c istack.c
 cc -O -pipe -D__USE_MISC -c parser.c
 cc -O -pipe -D__USE_MISC -c tags.c
 cc -O -pipe -D__USE_MISC -c entities.c
 cc -O -pipe -D__USE_MISC -c lexer.c
 cc -O -pipe -D__USE_MISC -c pprint.c
 cc -O -pipe -D__USE_MISC -c clean.c
 cc -O -pipe -D__USE_MISC -c localize.c
 cc -O -pipe -D__USE_MISC -c config.c
 cc -O -pipe -D__USE_MISC -c tidy.c
 cc -O -pipe -D__USE_MISC -o tidy  attrs.o istack.o
 parser.otags.o  entities.o  lexer.o pprint.o
 clean.o  localize.o  config.o tidy.o -lc 
   
 ===  Installing for tidy-0.9.99.1
 install -c -s -o root -g wheel -m 555
 /usr/ports/www/tidy/work/tidy27sep99/tidy /usr/local/bin/tidy
 ===   Installing documentation for tidy-0.9.99.1
 ===   Generating temporary packing list
 ===   Registering installation for tidy-0.9.99.1
 ===