kernel access control.
Provide ugidfw, a utility to manage the ruleset provided by
mac_bsdextended. Similar to ipfw, only for uids/gids and files.
Obtained from: TrustedBSD Project
Sponsored by: DARPA, NAI Labs
sense. Since portmap/rpcbind is in /usr/sbin it doesn't make any sense for
nfsd and mountd to be in /sbin.
For the record, NetBSD has them in /usr/sbin while OpenBSD has them in /sbin
PR: bin/30972
Reviewed by: jake (mentor)
native inb/outb etc, and alpha has libio. ia64 doesn't have any yet.
move pppctl to the NOLIBC_R section (libc_r is not possible on ia64 in
its present form due to assumptions about setjmp/longjmp magic)
crypto bits installed and/or NOCRYPTO/NO_OPENSSL is defined. This unfortunately
meants that usr.bin/chkey, usr.bin/newkey and usr.sbin/keyserv have also to
be disconnected.
IMO it is merely a workaround, the proper solution is to move libmp to
src/crypto where it belongs and use libgmp for the cryptoless builds instead.
Missed by: dd
With a small disk being 20GB these days, chances are pretty good that
an ailing sector will not be read while still being recoverable by
the drive.
Diskcheck daemon will read disks in the background at a low rate and
that way give the diskdrive a chance to detect and correct soft read
errors before they become hard errors.
Idea by: phk
Written by: ben
This driver supports PCI Xr-based and ISA Xem Digiboard cards.
dgm will go away soon if there are no problems reported. For now,
configuring dgm into your kernel warns that you should be using
digi. This driver is probably close to supporting Xi, Xe and Xeve
cards, but I wouldn't expect them to work properly (hardware
donations welcome).
The digi_* pseudo-drivers are not drivers themselves but contain
the BIOS and FEP/OS binaries for various digiboard cards and are
auto-loaded and auto-unloaded by the digi driver at initialisation
time. They *may* be configured into the kernel, but waste a lot
of space if they are. They're intended to be left as modules.
The digictl program is (mainly) used to re-initialise cards that
have external port modules attached such as the PC/Xem.
associated changes that had to happen to make this possible as well as
bugs fixed along the way.
Bring in required TLI library routines to support this.
Since we don't support TLI we've essentially copied what NetBSD
has done, adding a thin layer to emulate direct the TLI calls
into BSD socket calls.
This is mostly from Sun's tirpc release that was made in 1994,
however some fixes were backported from the 1999 release (supposedly
only made available after this porting effort was underway).
The submitter has agreed to continue on and bring us up to the
1999 release.
Several key features are introduced with this update:
Client calls are thread safe. (1999 code has server side thread
safe)
Updated, a more modern interface.
Many userland updates were done to bring the code up to par with
the recent RPC API.
There is an update to the pthreads library, a function
pthread_main_np() was added to emulate a function of Sun's threads
library.
While we're at it, bring in NetBSD's lockd, it's been far too
long of a wait.
New rpcbind(8) replaces portmap(8) (supporting communication over
an authenticated Unix-domain socket, and by default only allowing
set and unset requests over that channel). It's much more secure
than the old portmapper.
Umount(8), mountd(8), mount_nfs(8), nfsd(8) have also been upgraded
to support TI-RPC and to support IPV6.
Umount(8) is also fixed to unmount pathnames longer than 80 chars,
which are currently truncated by the Kernel statfs structure.
Submitted by: Martin Blapp <mb@imp.ch>
Manpage review: ru
Secure RPC implemented by: wpaul
attributes (recently committed). Using extattrctl, the extended attribute
service may be started and stopped for specific file systems; specific
attributes may be enabled or disabled, and the backing file for each
attribute configured. Also, backing files may be initialized.
Reviewed by: adrian, bp, freebsd-fs, the unthanked masses
Obtained from: TrustedBSD
kernel IPv6 multicast routing support.
pim6 dense mode daemon
pim6 sparse mode daemon
netstat support of IPv6 multicast routing statistics
Merging to the current and testing with other existing multicast routers
is done by Tatsuya Jinmei <jinmei@kame.net>, who writes and maintainances
the base code in KAME distribution.
Make world check and kernel build check was also successful.
NICs. (Finally!) The PCMCIA, ISA and PCI varieties are all supported,
though only the ISA and PCI ones will work on the alpha for now.
PCCARD, ISA and PCI attachments are all provided. Also provided an
ancontrol(8) utility for configuring the NIC, man pages, and updated
pccard.conf.sample. ISA cards are supported in both ISA PnP and hard-wired
mode, although you must configure the kernel explicitly to support the
hardwired mode since you have to know the I/O address and port ahead
of time.
Special thanks to Doug Ambrisko for doing the initial newbus hackery
and getting it to work in infrastructure mode.
pr_input() routines prototype is also changed to support IPSEC and IPV6
chained protocol headers.
Reviewed by: freebsd-arch, cvs-committers
Obtained from: KAME project
Been in production for 3 years now. Gives Instant Frame relay to if_sr
and if_ar drivers, and PPPOE support soon. See:
ftp://ftp.whistle.com/pub/archie/netgraph/index.html
for on-line manual pages.
Reviewed by: Doug Rabson (dfr@freebsd.org)
Obtained from: Whistle CVS tree
adapter (and some workalikes). Also add man pages and a wicontrol
utility to manipulate some of the card parameters.
This driver was written using information gleaned from the Lucent HCF Light
library, though it does not use any of the HCF Light code itself, mainly
because it's contaminated by the GPL (but also because it's pretty gross).
The HCF Light lacks certain featurs from the full (but proprietary) HCF
library, including 802.11 frame encapsulation support, however it has
just enough register information about the Hermes chip to allow someone
with enough spare time and energy to implement a proper driver. (I would
have prefered getting my hands on the Hermes manual, but that's proprietary
too. For those who are wondering, the Linux driver uses the proprietary
HCF library, but it's provided in object code form only.)
Note that I do not have access to a WavePOINT access point, so I have
only been able to test ad-hoc mode. The wicontrol utility can turn on
BSS mode, but I don't know for certain that the NIC will associate with
an access point correctly. Testers are encouraged to send their results
to me so that I can find out if I screwed up or not.
This is a seriously beefed up chroot kind of thing. The process
is jailed along the same lines as a chroot does it, but with
additional tough restrictions imposed on what the superuser can do.
For all I know, it is safe to hand over the root bit inside a
prison to the customer living in that prison, this is what
it was developed for in fact: "real virtual servers".
Each prison has an ip number associated with it, which all IP
communications will be coerced to use and each prison has its own
hostname.
Needless to say, you need more RAM this way, but the advantage is
that each customer can run their own particular version of apache
and not stomp on the toes of their neighbors.
It generally does what one would expect, but setting up a jail
still takes a little knowledge.
A few notes:
I have no scripts for setting up a jail, don't ask me for them.
The IP number should be an alias on one of the interfaces.
mount a /proc in each jail, it will make ps more useable.
/proc/<pid>/status tells the hostname of the prison for
jailed processes.
Quotas are only sensible if you have a mountpoint per prison.
There are no privisions for stopping resource-hogging.
Some "#ifdef INET" and similar may be missing (send patches!)
If somebody wants to take it from here and develop it into
more of a "virtual machine" they should be most welcome!
Tools, comments, patches & documentation most welcome.
Have fun...
Sponsored by: http://www.rndassociates.com/
Run for almost a year by: http://www.servetheweb.com/
ISDN4BSD is the work of our brand-new comitter: Hellmuth Michaelis,
who has done a tremendous amount of work to bring us this far.
There are still some outstanding issues and files to bring into
the tree, and for now it will be needed to pick up all the extra
docs from the isdn4bsd release.
It is probably also a very good idea to subscribe to the isdn@freebsd.org
mailing list before you try this out.
These files correspond to release "beta Version 0.70.00 / December
1998" from Hellmuth.
===================================
HARP | Host ATM Research Platform
===================================
HARP 3
What is this stuff?
-------------------
The Advanced Networking Group (ANG) at the Minnesota Supercomputer Center,
Inc. (MSCI), as part of its work on the MAGIC Gigabit Testbed, developed
the Host ATM Research Platform (HARP) software, which allows IP hosts to
communicate over ATM networks using standard protocols. It is intended to
be a high-quality platform for IP/ATM research.
HARP provides a way for IP hosts to connect to ATM networks. It supports
standard methods of communication using IP over ATM. A host's standard IP
software sends and receives datagrams via a HARP ATM interface. HARP provides
functionality similar to (and typically replaces) vendor-provided ATM device
driver software.
HARP includes full source code, making it possible for researchers to
experiment with different approaches to running IP over ATM. HARP is
self-contained; it requires no other licenses or commercial software packages.
HARP implements support for the IETF Classical IP model for using IP over ATM
networks, including:
o IETF ATMARP address resolution client
o IETF ATMARP address resolution server
o IETF SCSP/ATMARP server
o UNI 3.1 and 3.0 signalling protocols
o Fore Systems's SPANS signalling protocol
What's supported
----------------
The following are supported by HARP 3:
o ATM Host Interfaces
- FORE Systems, Inc. SBA-200 and SBA-200E ATM SBus Adapters
- FORE Systems, Inc. PCA-200E ATM PCI Adapters
- Efficient Networks, Inc. ENI-155p ATM PCI Adapters
o ATM Signalling Protocols
- The ATM Forum UNI 3.1 signalling protocol
- The ATM Forum UNI 3.0 signalling protocol
- The ATM Forum ILMI address registration
- FORE Systems's proprietary SPANS signalling protocol
- Permanent Virtual Channels (PVCs)
o IETF "Classical IP and ARP over ATM" model
- RFC 1483, "Multiprotocol Encapsulation over ATM Adaptation Layer 5"
- RFC 1577, "Classical IP and ARP over ATM"
- RFC 1626, "Default IP MTU for use over ATM AAL5"
- RFC 1755, "ATM Signaling Support for IP over ATM"
- RFC 2225, "Classical IP and ARP over ATM"
- RFC 2334, "Server Cache Synchronization Protocol (SCSP)"
- Internet Draft draft-ietf-ion-scsp-atmarp-00.txt,
"A Distributed ATMARP Service Using SCSP"
o ATM Sockets interface
- The file atm-sockets.txt contains further information
What's not supported
--------------------
The following major features of the above list are not currently supported:
o UNI point-to-multipoint support
o Driver support for Traffic Control/Quality of Service
o SPANS multicast and MPP support
o SPANS signalling using Efficient adapters
This software was developed under the sponsorship of the Defense Advanced
Research Projects Agency (DARPA).
Reviewed (lightly) by: phk
Submitted by: Network Computing Services, Inc.
is reason enough to make the compilation & installation of sendmail an
make.conf option. I know that you hate negative options Bruce.
PR: 6284
Reviewed by: phk
Submitted by: Adrian Colley <aecolley@world.std.com>
This puts it on the same footing as cvsup. It's been suggested on
numerous occasions that I shouldn't have imported it in the first place,
and now that sup has outlived it's usefulness..... Boom!
This will make a number of things easier in the future, as well as (finally!)
avoiding the Id-smashing problem which has plagued developers for so long.
Boy, I'm glad we're not using sup anymore. This update would have been
insane otherwise.
that this is a superset of cdplay, and perhaps it's time to send cdplay
into the bit bucket if this works well. According to the docs, it has
a friendlier command structure, command line interface etc.
Submitted by: Serge Vakulenko <vak@cronyx.ru>
