RE: patch for test: /etc/shells -> /usr/local/etc/shells
On 26-Jan-01 Steve O'Hara-Smith wrote:
> Hi,
>
> Following some recent comments on the evil ways of ports have of
> writing in /etc on install -
This assumes that everyone uses /usr/local for ${LOCALBASE}, which is
not a good assumption to make. If you want to do this right, then ports
should modify ${LOCALBASE}/etc/shells, and a couple of things should
happen:
1) All parsing of /etc/shells should move off into libutil under a
suitable API.
2) The implementation of this API should allow for multiple files that it
checks. One way might be to add a '.include' keyword or something so
that /etc/shells could have '.include /usr/local/etc/shells' that the
admin could adjust should he/she choose to change ${LOCALBASE} to
something other than /usr/local.
This is more work than your patch, but this patch doesn't really solve
the problem, it merely moves it. It also breaks for ${LOCALBASE}
!= /usr/local, so I don't think it should go in.
My $.02.
--
John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: > 4GB with NFS?
> On Thu, Jan 25, 2001 at 02:18:01PM -0800, Matthew Jacob wrote: > > An update on this > > > > If the server is Solaris, neither NetBSD nor FreeBSD (i386 or alpha) have a > > problem (as clients). > > > > The problem is therefore in some interaction between this server (see > > http://www.traakan.com- sorta like a NetApp) and *BSD. Hmm!!! > > > Did you check *BSD uses NFSv3 with this server ? Other than believing what it says on the server and and doing it manually, no. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: > 4GB with NFS?
On Thu, Jan 25, 2001 at 02:18:01PM -0800, Matthew Jacob wrote: > An update on this > > If the server is Solaris, neither NetBSD nor FreeBSD (i386 or alpha) have a > problem (as clients). > > The problem is therefore in some interaction between this server (see > http://www.traakan.com- sorta like a NetApp) and *BSD. Hmm!!! Did you check *BSD uses NFSv3 with this server ? -- Manuel Bouyer <[EMAIL PROTECTED]> -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
Louis A. Mamakos <[EMAIL PROTECTED]> types: > I think that /etc/X11 which came along with the XFree86 4 port is a > step in the right direction, too. Frankly, I'd rather have an /etc/local > than /usr/local/etc for that sort configuration data so that it's in > one place, and backed up along with the rest of the hosts's configuration. Other things seem to be moving in the direction of putting default values (that are updated with the system) in /etc/defaults, and local changes in /etc. That would suggest /etc/defaults/shells for the shells installed as part of the base system, and /etc/shells for shells added later, whether from ports or elsewhere. And I want the shed crimson with cream trim. http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
> Perhaps /etc/shells is the least of all evils here. I think there's way too much paranoia about software systems putting stuff into /etc. It intended to contain host-specific configuration data I think there's value in having this configuration data in one or very few places so you're not chasing stuff all over the file system. I think that /etc/X11 which came along with the XFree86 4 port is a step in the right direction, too. Frankly, I'd rather have an /etc/local than /usr/local/etc for that sort configuration data so that it's in one place, and backed up along with the rest of the hosts's configuration. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch for test: /etc/shells -> /usr/local/etc/shells
On Fri, 26 Jan 2001 16:21:01 -0500 (EST) Garrett Wollman <[EMAIL PROTECTED]> wrote: GW> < said: GW> GW> > The patch below (against 4-stable but it will probably apply easily GW> > to -current) moves /etc/shells to /usr/local/etc/shells. GW> GW> Bad idea. No base component (never mind libc!) should hard-code a GW> pathname in /usr/local. I'll consider it flamed to death then :) It was intended to prevent port installs having to write in /etc without having to change libc/gen, roken and sendmail which I rather suspect is also a bad thing to do. Perhaps /etc/shells is the least of all evils here. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for test: /etc/shells -> /usr/local/etc/shells
< said: > The patch below (against 4-stable but it will probably apply easily > to -current) moves /etc/shells to /usr/local/etc/shells. Bad idea. No base component (never mind libc!) should hard-code a pathname in /usr/local. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch for test: /etc/shells -> /usr/local/etc/shells
Hi,
Following some recent comments on the evil ways of ports have of
writing in /etc on install -
The patch below (against 4-stable but it will probably apply easily
to -current) moves /etc/shells to /usr/local/etc/shells. It should include
the removal of /usr/src/etc/shells but "cvs diff -N -u ..." did not do what
I exepected :(
After installworld you will have to move /etc/shells to /usr/local/etc
by hand or only the default shells will be known.
To follow (if this is not flamed to death), bsd.ports.mk patch to
automate maintenance of /usr/local/etc/shells during port install, and (of
course) documentation patches (I have a grep).
I am running on this and it works as expected with and without
/usr/local/etc/shells installed and with /etc/shells removed. It needs
more hammering than I can give it to be sure it is safe in all conditions
hence this mail.
Index: include/paths.h
===
RCS file: /home/ncvs/src/include/paths.h,v
retrieving revision 1.9.6.1
diff -u -r1.9.6.1 paths.h
--- include/paths.h 2000/12/11 01:03:16 1.9.6.1
+++ include/paths.h 2001/01/26 07:00:24
@@ -60,7 +60,7 @@
#define_PATH_MEM "/dev/mem"
#define_PATH_NOLOGIN "/var/run/nologin"
#define_PATH_SENDMAIL "/usr/sbin/sendmail"
-#define_PATH_SHELLS"/etc/shells"
+#define_PATH_SHELLS"/usr/local/etc/shells"
#define_PATH_TTY "/dev/tty"
#define_PATH_UNIX "don't use _PATH_UNIX"
#define_PATH_VI"/usr/bin/vi"
Index: etc/Makefile
===
RCS file: /home/ncvs/src/etc/Makefile,v
retrieving revision 1.219.2.9
diff -u -r1.219.2.9 Makefile
--- etc/Makefile2000/11/01 07:21:45 1.219.2.9
+++ etc/Makefile2001/01/26 07:04:28
@@ -13,7 +13,7 @@
printcap profile protocols \
rc rc.atm rc.devfs rc.diskless1 rc.diskless2 rc.firewall rc.firewall6 \
rc.isdn rc.network rc.network6 rc.pccard rc.serial rc.shutdown \
- rc.sysctl remote rpc security services shells syslog.conf usbd.conf \
+ rc.sysctl remote rpc security services syslog.conf usbd.conf \
etc.${MACHINE_ARCH}/disktab \
etc.${MACHINE_ARCH}/rc.${MACHINE_ARCH} \
etc.${MACHINE_ARCH}/ttys \
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
PCI changes break HP Docking Station
Hi,
I plugged my HP Omnibook 4150 into my dock for the first time in a couple
months only to discover that I couldn't attach any of the PCI devices in
it. I'm running -current as of sometime in the last week or so. I traced
the problem to the new PCI code comitted six weeks ago. Specificaly:
- Make the PCI-PCI bridge code a little more paranoid about valid
I/O and memory decodes.
It looks like the new code is too paranoid. The following patch lets me
attach devices in the dock though it's obviously bogus. You can find a
kernel config, verbose dmesg output, pciconf -l -v output, and acpidump
output at:
http://www.one-eyed-alien.net/~brooks/FreeBSD/dock/
Please let me know if you need anything more from me to help debug this.
Thanks,
Brooks
--
Any statement of the form "X is the one, true Y" is FALSE.
Index: pci_pci.c
===
RCS file: /home/ncvs/src/sys/dev/pci/pci_pci.c,v
retrieving revision 1.3
diff -u -r1.3 pci_pci.c
--- pci_pci.c 2000/12/13 01:25:11 1.3
+++ pci_pci.c 2001/01/26 19:56:40
@@ -283,10 +283,10 @@
case SYS_RES_IOPORT:
if ((start < sc->iobase) || (end > sc->iolimit)) {
device_printf(dev, "device %s%d requested unsupported I/O range
0x%lx-0x%lx"
- " (decoding 0x%x-0x%x)\n",
+ " (decoding 0x%x-0x%x) IGNORED\n",
device_get_name(child), device_get_unit(child), start,
end,
sc->iobase, sc->iolimit);
- return(NULL);
+ /* return(NULL); */
}
if (bootverbose)
device_printf(sc->dev, "device %s%d requested decoded I/O range
0x%lx-0x%lx\n",
@@ -303,10 +303,10 @@
if (((start < sc->membase) || (end > sc->memlimit)) &&
((start < sc->pmembase) || (end > sc->pmemlimit))) {
device_printf(dev, "device %s%d requested unsupported memory range
0x%lx-0x%lx"
- " (decoding 0x%x-0x%x, 0x%x-0x%x)\n",
+ " (decoding 0x%x-0x%x, 0x%x-0x%x) IGNORED\n",
device_get_name(child), device_get_unit(child), start,
end,
sc->membase, sc->memlimit, sc->pmembase, sc->pmemlimit);
- return(NULL);
+ /* return(NULL); */
}
if (bootverbose)
device_printf(sc->dev, "device %s%d requested decoded memory range
0x%lx-0x%lx\n",
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails
John Hay wrote: > > If you have current source, just recompile rpcgen and try again. Something > like: > > cd /usr/src/usr.bin/rpcgen > make all install clean > > should do it. Then you can return to your regular make world. > > John That did end up working. Thanks. I just wanted to mention it publicly, since I didn't see a mention of it in the list archives. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails
> > } -- > } >>> stage 4: populating /usr/obj/usr/src/i386/usr/include > } -- > > [snip] > > } ===> rpcsvc > } rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > } rpcgen: cannot find any C preprocessor (cpp) > > I have seen exactly this and reported it a week ago. No one seemed to have > noticed though. :\ > If you have current source, just recompile rpcgen and try again. Something like: cd /usr/src/usr.bin/rpcgen make all install clean should do it. Then you can return to your regular make world. John -- John Hay -- [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails
This has been happening for sometime. It seems to happen when you upgrade a recent 5.0-SNAPSHOT (not a 4-STABLE install). I believe that David O'Brien is aware of this. He was working on it - I wonder if it slipped away :) Tom Veldhouse [EMAIL PROTECTED] - Original Message - From: "Nick Sayer" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 26, 2001 9:42 AM Subject: buildworld fails > -- > >>> stage 4: populating /usr/obj/usr/src/i386/usr/include > -- > cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bi n LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/u sr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes > cd /usr/src/include;make -B all install > creating osreldate.h from newvers.sh > setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh;echo "$COPYRIGHT" > osreldate.h;echo \#'undef __FreeBSD_version' >> osreldate.h;echo \#'define __FreeBSD_version' $RELDATE >> osreldate.h > ===> rpcsvc > rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h > rpcgen: cannot find any C preprocessor (cpp) > *** Error code 1 > > Stop in /usr/src/include/rpcsvc. > *** Error code 1 > > Stop in /usr/src/include. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: buildworld fails
Nick Sayer <[EMAIL PROTECTED]> wrote: } -- } >>> stage 4: populating /usr/obj/usr/src/i386/usr/include } -- [snip] } ===> rpcsvc } rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h } rpcgen: cannot find any C preprocessor (cpp) I have seen exactly this and reported it a week ago. No one seemed to have noticed though. :\ -Patrick Patrick L. Hartling | Research Assistant, VRAC [EMAIL PROTECTED] | 2624 Howe Hall -- (515)294-4916 http://www.137.org/patrick/ | http://www.vrac.iastate.edu/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld fails
-- >>> stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj COMPILER_PATH=/usr/obj/usr/src/i386/usr/libexec:/usr/obj/usr/src/i386/usr/bin LIBRARY_PATH=/usr/obj/usr/src/i386/usr/lib:/usr/obj/usr/src/i386/usr/lib OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec PERL5LIB=/usr/obj/usr/src/i386/usr/libdata/perl/5.6.0 DESTDIR=/usr/obj/usr/src/i386 INSTALL="sh /usr/src/tools/install.sh" PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks includes cd /usr/src/include;make -B all install creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh;echo "$COPYRIGHT" > osreldate.h;echo \#'undef __FreeBSD_version' >> osreldate.h; echo \#'define __FreeBSD_version' $RELDATE >> osreldate.h ===> rpcsvc rpcgen -C -h -DWANT_NFS3 /usr/src/include/rpcsvc/key_prot.x -o key_prot.h rpcgen: cannot find any C preprocessor (cpp) *** Error code 1 Stop in /usr/src/include/rpcsvc. *** Error code 1 Stop in /usr/src/include. *** Error code 1 Stop in /usr/src. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
> I'd be happy to (I like a challenge) but I still require access to the > standards for that. So my question still stands, does BSDi have IEEE > subscriptions for FreeBSD developers to use, or are there any other ways > for me to aquire (legally of course) the standards I need without having to > shell out the 1K US$ myself. You can probably find good sources of informations around on the net. Cisco comes immediately to my mind, 3Com and redbooks.com are also very likely to have. I'd also check ethereal sources, where packet-bpdu.c includes most of what you need to start interpreting packets you receive, and send new ones (well, you also need llcsaps.h and oui.h). Speaking of 802.1G (BCP) you should look at RFC2878... wait, checking on that again, I just found out that this is THE document for bridging, so start from that ;-) Also, RFC 1638 documents the old STP protocol. Even though I could find nothing more in RFCs, a quick tcpdump confirmed that most STP involves broadcasts to 01-80-c2-00-00-00. > I'd probably go for the Cisco defaults. And there are lots of netgraph > nodes with settings you can change. So I'd consider being able to change > the values pretty much a given. =) Ok. As I said, I know quite well bridging from my Cisco certifications days, but no experience with netgraph ;-) > > Duly noted. I recall reading that 802.1Q extends the 802.1D standardble to > understand VLANs, but that most implementations still use a single STP > instance. Cisco of course uses multiple instances (did I read this on a > Cisco related site? n =) ). Yes, implementation dependant. > > >Having said that, while I am not able to help in writing code (no time to > >learn netgraph, sorry), I will be more than happy to test it, having a > >home network comprising a -current box with 4 ethernet ports and 3 or 4 > >differents brands / models of hubs/switches. > > I'll drop you a line when the time comes. Ok. Please keep me updated. Bye, Andrea -- 0 and 1. Now what could be so hard about that? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
> > > There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer > > to have that, but I don't have the 1K US$ to shell out for that. > > Does BSDi have IEEE subscriptions for FreeBSD developers to use? > >Please also consider implementing 802.1G, which is for bridging over PPP >(BCP I think?). I think a lot of us remember the times when remote bridging >was more common than routing ;-) I'd be happy to (I like a challenge) but I still require access to the standards for that. So my question still stands, does BSDi have IEEE subscriptions for FreeBSD developers to use, or are there any other ways for me to aquire (legally of course) the standards I need without having to shell out the 1K US$ myself. > > This results in the blocking of redundant ports so that loops are > > eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml > > for a good overview that's pretty in depth. > >Any Cisco documentation will go into depth explaining the tradeoffs in >deciding the timing for the various state (STP is, in the end, a state >automaton) depending on the exact topology. You should be careful when >deciding defaults, and you should implement a way to adjust them. I'd probably go for the Cisco defaults. And there are lots of netgraph nodes with settings you can change. So I'd consider being able to change the values pretty much a given. =) >Also, FreeBSD has support for 802.1q VLAN tagging. Having 802.1q trunks in >your network means you (usually) have more than 1 instance of STP. >Furthermore, >this means that even if you don't care about 802.1q, you should be prepared to >receive BPDU-like backets which are NOT part of the 802.1d exchange (unless my >mind is playing tricks on me, that is). Of course you can choose not to handle >all of this but then the implementation would be less useful in the real >world. Duly noted. I recall reading that 802.1Q extends the 802.1D standardble to understand VLANs, but that most implementations still use a single STP instance. Cisco of course uses multiple instances (did I read this on a Cisco related site? n =) ). >Having said that, while I am not able to help in writing code (no time to >learn netgraph, sorry), I will be more than happy to test it, having a >home network comprising a -current box with 4 ethernet ports and 3 or 4 >differents brands / models of hubs/switches. I'll drop you a line when the time comes. DocWilco To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
(no subject)
subscrive [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: status of bridge code
On Thu, Jan 25, 2001 at 12:19:16PM +0100, Rogier R. Mulhuijzen wrote: > At 09:37 25-1-01 -0800, Archie Cobbs wrote: > >Rogier R. Mulhuijzen writes: > > > But from my list of wishes I'd say the first 3 are gone. All that's > > left is > > > spanning tree. I'm probably going to need this pretty soon, so once more > > > I'm asking if anyone is working on it. If not I'll start on it. > > > >Do you have references for how to do this? As I understand it, there > >are special Ethernet addresses that are "for bridges only -- do not > >forward" that are used to construct the spanning tree, etc. What is > >the "standard" algorithm used by bridges, etc.? > > There's a Spanning Tree Protocol (STP) defined by IEEE 802.1D. I'd prefer > to have that, but I don't have the 1K US$ to shell out for that. > Does BSDi have IEEE subscriptions for FreeBSD developers to use? Please also consider implementing 802.1G, which is for bridging over PPP (BCP I think?). I think a lot of us remember the times when remote bridging was more common than routing ;-) > First of all bridges might have their own MACs that fall into a certain > range, but STP does not depend on that. The "do not forward" is deducted > from the protocol type. There is an ethernet protocol called BPDU (Bridge > Protocol Data Unit) that each bridge sends and receives, but is not > forwarded by any of them. These BDPUs are used to elect root bridge and > determine root ports and designated ports. > > This results in the blocking of redundant ports so that loops are > eliminated. See http://www.knowcisco.com/content/1578700949/pt02ch06.shtml > for a good overview that's pretty in depth. Any Cisco documentation will go into depth explaining the tradeoffs in deciding the timing for the various state (STP is, in the end, a state automaton) depending on the exact topology. You should be careful when deciding defaults, and you should implement a way to adjust them. Also, FreeBSD has support for 802.1q VLAN tagging. Having 802.1q trunks in your network means you (usually) have more than 1 instance of STP. Furthermore, this means that even if you don't care about 802.1q, you should be prepared to receive BPDU-like backets which are NOT part of the 802.1d exchange (unless my mind is playing tricks on me, that is). Of course you can choose not to handle all of this but then the implementation would be less useful in the real world. Having said that, while I am not able to help in writing code (no time to learn netgraph, sorry), I will be more than happy to test it, having a home network comprising a -current box with 4 ethernet ports and 3 or 4 differents brands / models of hubs/switches. Bye, Andrea -- There's no place like ~ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Suscribe
suscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
