Make the default setting YES for now to get some experience with it.
Note: If people starts seeing disk errors because of this then it
should not be backed.
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
about non-existent mount directories (which would come
into existence after the real mount has occured) when just
testing for if there are any NFS filesystems in /etc/fstab.
PR: bin/26597
Submitted by: Dmitry Morozovsky <marck@rinet.ru>
MFC after: 3 days
systems were repo-copied from sys/miscfs to sys/fs.
- Renamed the following file systems and their modules:
fdesc -> fdescfs, portal -> portalfs, union -> unionfs.
- Renamed corresponding kernel options:
FDESC -> FDESCFS, PORTAL -> PORTALFS, UNION -> UNIONFS.
- Install header files for the above file systems.
- Removed bogus -I${.CURDIR}/../../sys CFLAGS from userland
Makefiles.
is not set. This allows admins to create a per-machine configuration file
while leaving the freebsd.mc template pristine. Provide a rule to create
`hostname`.mc from freebsd.mc if it doesn't exist.
PR: misc/26299
MFC after: 8 days
fsck checking. Applying these changes (typically via mergemaster)
will cause your system to start running background checks on all
your soft update enabled filesystems (provided that you have
a kernel with the required functionality, e.g., one built since
the end of April). Please report any and all problems to
mckusick@mckusick.com (not mckusick@freebsd.org which I read
infrequently). See the comment above the fsck command in /etc/rc
for instructions on how to disable background checking should it
cause you too much trouble.
Several FAQs:
1) Can I reboot before the background checks are done?
Ans) Yes, when the system restarts the checks will pick up
where they left off.
2) Can a crash during checking corrupt my filesystem?
Ans) No, recovered resources are returned to the system using soft
updates which ensure that the freeing is done in a safe order.
3) How will I know if any background checks are being done?
Ans) Filesystems that are to be checked in background will be listed
as `DEFER FOR BACKGROUND CHECKING' at the usual fsck check time
during system startup.
4) What happens to the output of the background checks?
Ans) It is sent to syslog `daemon' facility log level `notice'.
5) When will this feature be available in the 4.X kernel?
Ans) Never. It is much too radical and extensive a change to be
MFC'ed. Besides, it needs many months of experience and
tuning before it is ready for widespread use.
6) What happens if a background fsck fails (i.e., fsck finds
errors that would normally require a manual fsck)?
Ans) The filesystem will be marked as needing a manual fsck.
At the next system reboot, the check will be done in
foreground and the usual actions taken (usually a failure
to go multi-user until fsck has been run by hand on the
affected filesystem).
the null mount, we currently create a temporary mfs on /tmp, copy
/etc to /tmp, then mount /etc as mfs and copy everything back from
/tmp, then delete the /tmp mfs.
The patch eliminates the temporary /tmp mfs and the subsequent
copying and simply populates the /etc mfs by copying from
/conf/default/etc. This requires that /conf/default/etc contain a
complete copy of all the /etc stuff instead of just overrides. I
don't think that is too much of an extra step in setting up a
diskless environment.
* Provide the ability to make /tmp a memory filesystem independent
of /var. This removes the requirement that /tmp be a symlink to
/var/tmp and this makes the diskless code work with the default
filesystem layout. If a seperate /tmp memory filesystem is
created, the 'tmpsize' environment variable is used to determine
its size (default to 10 Meg).
* Reduce diffs between the -current and -stable versions of these
files to a bare minimum. Only the definition of the shell
function 'mount_md' is different.
Not Objected to by: -arch@, -small@
MFC after: 2 days
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.
o create a simple wrapper function mount_md that makes it easy to
move from mount_mfs.
# NOTE: you will need to MAKEDEV md[0123] in order for this to work.
Reviewed by: bsd, keichii
/dev/log like this: if [ ! -h /dev/log ];
The man page for test(1) says that the -h switch is depracated and that
users should NOT rely on it being available. It suggest the -L switch instead.
They both do the same thing: check for the existence of the symbolic link.
PR: 26596
Submitted by: mikem <mike_makonnen@yahoo.com>
BSDPAN is the collection of modules that provides tighter than ever
integration of Perl into BSD Unix.
Currently, BSDPAN does the following:
o makes p5- FreeBSD ports PREFIX-clean;
o registers Perl modules in the FreeBSD package database with a
package name derived from the module name.
The name is of the form: bsdpan-ModuleName-V.VV.
Anyone interested in where BSDPAN is developing should read Anton's
message to the ports mailling list:
Message-ID: <20010105040828.A26011@heechee.tobez.org>
Submitted by: Anton Berezin <tobez@tobez.org>
default first, then network-specific files, then host-specific files.
I think this was the original intent, as Matt indicated the previous
code appeared to be a bug.
out of sync. A similar change was made by itojun on the OpenBSD tree
a few weeks ago. This should stop people disabling one server and
forgetting the other one (eg: ftp and/or telnet)
NO_MAKEDEV_INSTALL and NO_MAKEDEV_RUN. The former implying the latter.
The names imply what they do. The last commit by DES based on a PR defeated
the original idea behind NO_MAKEDEV, which was not to run MAKEDEV, but to do
the installation of MAKEDEV. This should satisfy both parties on the MAKEDEV
challenge.
Note that "right" in this case is not universally recognized, but
NTP-practittioners as opposed to theoretians generally agree that
getting "inside the window" using ntpdate is TRTTD on PC hardware.
PR: 25514
Submitted by: Chris Johnson <cjohnson-pr@palomine.net>
The PAM_FAIL_CHECK and PAM_END macros in su.c came from the util-linux
package's PAM patches to the BSD login.c
Submitted by: "David J. MacKenzie" <djm@web.us.uu.net>
very specific scenarios, and now that we have had net.inet.tcp.blackhole for
quite some time there is really no reason to use it any more.
(second of three commits)
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
Xircom CreditCard Netwave cnw
Intel PRO/Wireless 2011 (PRISM II) wi
3COM 3CRWE737A (PRISM II) wi
Note: I've had some reports that the latter two cards work, but I've not
been able to get them to work for me.
enable all harvesting options by default since having them on for
devices not present doesn't hurt anything. Leave them on by default
since for the most part they are not producing noticable slowdown,
and are about to get a lot more efficient.
Re-order part of the cheesy entropy process in preparation for
its complete removal.
during the boot process. We're turning it on by default, based on the
actual presence of a configured ethernet card, and/or ppp/tun devices.
Of course, it's easy to disable in rc.conf.
1) blackholes.mail-abuse.org is the same as FEATURE(dnsbl), so specifying
it in the "Other DNS based black hole lists" section leads to confusion of
specifying it twice.
2) Formatting issues. If error diagnostic not enclosed in double quotes,
varius visual artefacts appearse like 1) no space after ; and 2) redundant
space after ? (in CGI request), so I add quotes where needed.
3) FEATURE(dnsbl) directly use error code 550 by default, so I made other
dnsbl variants use the same error code too.
4) Comment relays.* list as "open relays" list, just "other" word is not
explain enough.
Submitted by: ache
and Pentium II, III and IV processors (p2, p3, p4), as well as 'mmx' and
'3dnow' MACHINE_CPU tags as appropriate. In the near future this will
be used to control various ports which have MMX/3dNow optimizations,
instead of the ad-hoc methods currently used.
Reviewed by: peter
libssl, for example), and hide it behind a make.conf option,
WANT_OPENSSL_MANPAGES, instead of having it commented out. We still can't
install these by default because of clobbering of a number of system
manpages with the same name, but they're there for people who want them.
* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
after we pull in /etc/make.conf. We need to do it afterwards so we can
react to the user setting of the:
* CPUTYPE variable, which contains the CPU type which the user wants to
optimize for. For example, if you want your binaries to only run on an
i686-class machine (or higher), set this to i686. If you want to support
running binaries on a variety of CPU generations, set this to the lowest
common denominator. Supported values are listed in make.conf.
* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
(hopefully) correct unordered list of CPU types which should be used on
that CPU. For example, an AMD k6 CPU wants any of the following:
k6 k5 i586 i486 i386
This is still an unordered list so the client makefile logic is simple -
client makefiles need to test for the various elements of the set in
decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
The various MACHINE_CPU lists are believed to be correct, but should be
checked.
* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc). Release
builders and developers of third-party software need to make sure not to
enable CPU-specific optimization when generating code intended to be
portable. We probably need to move to an /etc/world.conf to allow the
optimization stuff to be applied separately to world/kernel and external
compilations, but it's not any worse a problem than it was before.
* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.
* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
(only i386, alpha and ia64 first, since those are the minimally-working
ports. Other architecture porters, please feel free to add the relevant
gunk for your platform).
Reviewed by: jhb, obrien
+ Add support for the new SENDMAIL_MC make.conf knob
+ Add the ability to build .cf files from .mc files
+ Generalize map rebuilding
+ Add the ability to rebuild the aliases file
+ Add the ability to stop, start, and restart sendmail
PR: bin/13759, bin/19897, bin/24397
users should be configuring via m4 now. If set, use m4 to create the .cf
file. Also, if either SENDMAIL_MC or SENDMAIL_CF is set, 'make install' or
'make distribution' in src/etc/sendmail/ will install the appropriate .cf as
/etc/mail/sendmail.cf. This fixes some mergemaster problems.
PR: conf/13016
Makefile to the etc/sendmail Makefile to be consistent with all of the
other /var file creations. In doing so, change the Makefile target from
etc-sendmail.cf to distribution as it installs more than just the sendmail.cf.
pass udp from any 53 to ${oip}
allows an attacker to access ANY local port by simply binding his local
side to 53. The state keeping mechanism is the correct way to allow DNS
replies to go back to their source.
through the use of a new build directive, MACHINE_CPU, which contains a
list of the CPU generations/features for which optimizations are desired.
This feature will be extended to cover the ports tree in the future.
Currently OpenSSL provides optimizations for i386, i586 and i686-class
CPUs. Currently it has not been tested on an i386 or i486.
Teach make(1) to provide sensible defaults for MACHINE_CPU if it is not
defined (namely, the lowest common denominator CPU we support for each
architecture). Currently this is i386 for the i386 architecture and ev4
for the alpha. sys.mk also sets the variable as a last resort for
consistency with MACHINE_ARCH and bootstrapping from very old versions of
make.
Benchmarks show a significant speed increase even in the i386 case, with
additional improvements for i586 and i686 systems. For maximum performance
define MACHINE_CPU=i686 i586 i386 in /etc/make.conf.
Based on a patch submitted by: Mike Silbersack <silby@silby.com>
Reviewed by: current
trigger happy and turn off sendmail_enable entirely (instead of setting
sendmail_flags to -q30m instead). I have seen boxes with things like daily
run reports that have sat in mailq for 5 months. Since /usr/sbin/sendmail
is actually mailwrapper, this should be safe for the other plugins that
provide the sendmail calling interface.
