permitting the administrator to select a securelevel top operate
at. Include a helpfile summarizing some of the information from
init(8). This allows for explicit configuration of securelevels,
which was previously implicit in Security Profile selection.
Currently, there are no checkboxes for the active securelevel,
because sysinstall's facilities for deriving "current settings"
from rc.conf may use only one variable, not two, and I opted for
the simplest approach at this point.
Approved by: re (scottl)
selection is used to drive two configuration parameters:
(1) Default enable/disable for sshd
(2) Default enable/disable for securelevels
Replace this with an explicit choice to enable/disable sshd. A
follow-up commit will add a configuration option to the Security
post-install configuration menu to set the securelevel in rc.conf
explicitly. This should reduce the level of foot-shooting associated
with accidental enabling of securelevels, make the nature and
implications of the securelevel configuration options more explicit,
as well as make the choice to enable/disable sshd more explicit.
Approved by: re (scottl)
a partition size on ia64. It's not true.
o Ask for a mountpoint for EFI partitions as well and check that it
isn't "/".
o On ia64 we may need to add EFI partitions. Make sure we pass the
right arguments to Create_Chunk_DWIM() in that case.
to better deal with the fact that we need an EFI partition and
that we need to have a mountpoint for it.
o When creating a new partition, add EFI to the list of types
the user can select from. This makes it easy to create an EFI.
o Do not include wizard.c on ia64.
o The user cannot create a partition on ia64 that's a multiple of
the cylinder size. We don't have a notion of cyclinders.
o Also allow swap and filesystem partitions outside a freebsd slice.
This is typically the case for GPT.
o Allow chunks of type "whole" to be displayed at the top. This is
to allow a GPT disk to be labeled. We need a slice out of which we
can make partitions, but a GPT disk doesn't have slices. For GPT
disks a chunk of type "whole" can then be used as a placeholder.
(1) Don't modify the configuration of the NFS server as a result of
selecting a profile. We already explicitly prompt for the NFS
server configuration during install, and the user may not get
much advance notice that we're turning it off again. Instead,
use profiles (for better or for worse) only for security tuning.
(2) Don't modify the sendmail setting as part of the security profile:
use the default from /etc/defaults/rc.conf rather than explicitly
specifying. Note that the default in /etc/defaults/rc.conf is
more conservative than the explicit rc.conf entry added by
sysinstall during install, as it does not permit SMTP delivery.
(3) Update "congratulations on your profile" text to reflect these
changes.
Note that security profiles now affect only the securelevel and sshd
settings. My leaning would be to make sshd an explicit configuration
option, move securelevels to the security menu, and drop security
profiles entirely. However, that requires more plumbing of sendmail
than I'm currently willing to invest.
We may want to add a "permit SMTP delivery" question to the install
process.
archaic at this point in time. Pretend nobody runs FreeBSD 1.x anymore
in order to not confuse people needlessly.
Laplink support probably doesn't even work at this point in time anyway...
- Add 'enable_exim="YES"' to rc.conf(5)
- Use the default exim configuration file from the port
- When using sendmail, disable some more scripts that use sendmail specific
parameters
- Have sysinstall tweak mailer.conf(5) substitution
- Use 'N' flag for newsyslog(8)
Submitted by: Oliver Eikemeier <eikemeier@fillmore-labs.com>
Reviewed by: sheldonh, simon
Tested by: myself (trhodes) and submitter
written by Stuart Walsh and Duncan Barclay (with some kibbitzing by
me). I'm checking it in on Stuart's behalf.
The BCM4401 is built into several x86 laptop and desktop systems. For the
moment, I have only enabled it in the x86 kernel config because although
it's a PCI device, I haven't heard of any standalone NICs that use it. If
somebody knows of one, we can easily add it to the other arches.
This driver uses register/structure data gleaned from the Linux
driver released by Broadcom, but does not contain any of the code
from the Linux driver itself. It uses busdma.
rl(4) driver and put it in a new re(4) driver. The re(4) driver shares
the if_rlreg.h file with rl(4) but is a separate module. (Ultimately
I may change this. For now, it's convenient.)
rl(4) has been modified so that it will never attach to an 8139C+
chip, leaving it to re(4) instead. Only re(4) has the PCI IDs to
match the 8169/8169S/8110S gigE chips. if_re.c contains the same
basic code that was originally bolted onto if_rl.c, with the
following updates:
- Added support for jumbo frames. Currently, there seems to be
a limit of approximately 6200 bytes for jumbo frames on transmit.
(This was determined via experimentation.) The 8169S/8110S chips
apparently are limited to 7.5K frames on transmit. This may require
some more work, though the framework to handle jumbo frames on RX
is in place: the re_rxeof() routine will gather up frames than span
multiple 2K clusters into a single mbuf list.
- Fixed bug in re_txeof(): if we reap some of the TX buffers,
but there are still some pending, re-arm the timer before exiting
re_txeof() so that another timeout interrupt will be generated, just
in case re_start() doesn't do it for us.
- Handle the 'link state changed' interrupt
- Fix a detach bug. If re(4) is loaded as a module, and you do
tcpdump -i re0, then you do 'kldunload if_re,' the system will
panic after a few seconds. This happens because ether_ifdetach()
ends up calling the BPF detach code, which notices the interface
is in promiscuous mode and tries to switch promisc mode off while
detaching the BPF listner. This ultimately results in a call
to re_ioctl() (due to SIOCSIFFLAGS), which in turn calls re_init()
to handle the IFF_PROMISC flag change. Unfortunately, calling re_init()
here turns the chip back on and restarts the 1-second timeout loop
that drives re_tick(). By the time the timeout fires, if_re.ko
has been unloaded, which results in a call to invalid code and
blows up the system.
To fix this, I cleared the IFF_UP flag before calling ether_ifdetach(),
which stops the ioctl routine from trying to reset the chip.
- Modified comments in re_rxeof() relating to the difference in
RX descriptor status bit layout between the 8139C+ and the gigE
chips. The layout is different because the frame length field
was expanded from 12 bits to 13, and they got rid of one of the
status bits to make room.
- Add diagnostic code (re_diag()) to test for the case where a user
has installed a broken 32-bit 8169 PCI NIC in a 64-bit slot. Some
NICs have the REQ64# and ACK64# lines connected even though the
board is 32-bit only (in this case, they should be pulled high).
This fools the chip into doing 64-bit DMA transfers even though
there is no 64-bit data path. To detect this, re_diag() puts the
chip into digital loopback mode and sets the receiver to promiscuous
mode, then initiates a single 64-byte packet transmission. The
frame is echoed back to the host, and if the frame contents are
intact, we know DMA is working correctly, otherwise we complain
loudly on the console and abort the device attach. (At the moment,
I don't know of any way to work around the problem other than
physically modifying the board, so until/unless I can think of a
software workaround, this will have do to.)
- Created re(4) man page
- Modified rlphy.c to allow re(4) to attach as well as rl(4).
Note that this code works for the sample 8169/Marvell 88E1000 NIC
that I have, but probably won't work for the 8169S/8110S chips.
RealTek has sent me some sample NICs, but they haven't arrived yet.
I will probably need to add an rlgphy driver to handle the on-board
PHY in the 8169S/8110S (it needs special DSP initialization).
This option adds Postfix and Exim to the list, however, qmail is not added
due to license restrictions.
Collaborated with: Simon L. Nielsen <simon@nitro.dk>
Reviewed by: jhb, re@, -audit.
'use entire disk'. Neither for ia64 while I'm here - it needs a MBR if
its going to use fdisk+disklabel. The ia64 case is mostly academic though
because you'd be creating two partitions (dos + freebsd) rather than
a single freebsd-only partition.
PC98 boot blocks don't support UFS2. We keep newfs(8) defaulting to
UFS2.
Warn users that FreeBSD can only boot from a root file system smaller
than 1.5TB; hopefully this will get fixed by the patches currently
floating around on -CURRENT.
Reviewed by: nyan
ethernet controller. The driver has been tested with the LinkSys
USB200M adapter. I know for a fact that there are other devices out
there with this chip but don't have all the USB vendor/device IDs.
Note: I'm not sure if this will force the driver to end up in the
install kernel image or not. Special magic needs to be done to exclude
it to keep the boot floppies from bloating again, someone please
advise.
FreeBSD 5.1-RELEASE and later:
- newfs(8) will now create UFS2 file systems unless UFS1 is specifically
requested (-O1). To do this, I just twiddled the Oflag default.
- sysinstall(8) will now select UFS2 as the default layout for new
file systems unless specifically requested (use '1' and '2' to change
the file system layout in the disk labeler). To do this, I inverted
the ufs2 flag into a ufs1 flag, since ufs2 is now the default and
ufs1 is the edge case. There's a slight semantic change in the
key behavior: '2' no longer toggles, it changes the selection to UFS2.
This is very similar to a patch David O'Brien sent me at one point, and
that I couldn't find.
Approved by: re (telecon)
Reviewed by: mckusick, phk, bmah
