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)
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
'base' dist rename.
- Rework struct dist to allow for different types of dists. There are
currently three types of dists: DT_TARBALL, the traditonal gzipped and
split tar file; DT_PACKAGE, a package; and DT_SUBDIST, a meta-dist in
the tree that has its own array of dists as its contents. For example,
the 'base' dist is a DT_TARBALL dist, the 'perl' dist is a DT_PACKAGE
dist, and the 'src' dist is a DT_SUBDIST dist with its own dist table
that contains 'sbase', 'ssys', etc.
- Add helper macros for defining array entries for the different types of
dists to try and make the statically defined dist table in dist.c more
readable.
- Split the logic to deal with a DT_TARBALL dist out of distExtract()
and into its own distExtractTarball() function. distExtract() now
calls other functions to extract each dist.
- Tweak the percentage complete calculation in distExtractTarball() to
do the multiply prior to the divide so it doesn't have to use floating
point.
- Axe the installPackage() function along with the special handling for
the perl and XFree86 dists in distExtractAll() since distExtract()
handles package dists directly now.
- Add back in subdists for the X packages based on the split up packages
that XFree86-4 uses that as closely map to the X dists we used with
X 3.3.x.
- Lots of things like distSetX() and the X dist masks are no longer
#ifndef X_AS_PKG since we use them in both cases now.
- Make the entire installFixupXFree() function #ifndef X_AS_PKG, we only
call it in that case anyways, and it's not suitable for the X_AS_PKG
case.
- Add in X dist menus for the X_AS_PKG case.
Approved by: re
editor, in order to support specifying UFS2 as a newfs option.
(1) Support three different newfs types: NEWFS_UFS, NEWFS_MSDOS, and
NEWFS_CUSTOM. Don't mix up the arguments to them: you can't use
soft updates on an msdos file system.
(2) Distinguish adding new arguments to the newfs command line from
replacing it. Permit the addition of new arguments by the user for
NEWFS_UFS. If we entirely replace the command line provided by
sysinstall, call it NEWFS_CUSTOM. 'N' will now add additional
arguments; 'Z' will opt to replace the newfs command line entirely,
but will prompt the user with their current command line as a
starting point.
(3) Construct the newfs command line dynamically based on the options
provided by the user at label-time. Right now, this means selecting
UFS1 vs. UFS2, and the soft updates flag. Drop in some variables
to support ACLs and MAC Multilabel in the future also, but don't
expose them now.
This provides sysinstall with the ability to do more "in band" editing
of the newfs command line, so we can provide more support for the user,
but doesn't sacrifice the ability to entirely specify the newfs command
line of the user is willing to give up on the cushiness factor. It
also makes it easier for us to specify defaults in the future, and
define conditional behavior based on user configuration selections.
For now, we default to UFS1, and permit UFS2 to be used as the root
only on non-i386 systems.
While I was there, I dropped the default fragment and block sizes,
since newfs has much more sensible defaults now.
Reviewed by: jhb, marcel
Approved by: re
ia64 bits from: marcel
o Mount the EFI file system as msdosfs and not ufs as it's a FAT
file system. Introduce Mount_msdos() for this to go side-by-side
with Mount().
o Also, since mounting is performed as a command (which means it's
queued, sorted, lost, found and executed), we cannot create a
directory on the file system by calling mkdir. We must make sure
the mkdir happens after the mount. Introduce Mkdir_command() to
allow mkdir operations to be queued, sorted, lost, found and
executed as well.
Approved by: re (jhb, rwatson)
of an explicit list of architecture defines.
- Tweak the message prior to the label editor in the !WITH_SLICES case to
make it slightly less awkward since this is the first dialog we see after
starting an install.
- Only offer to customize syscons settings if WITH_SYSCONS.
- Offer to enable Linux compat if WITH_LINUX. Before we only did this for
i386.
- On the alpha, offer to enable OSF/1 compat after asking about Linux
compat.
- Only offer to configure moused(8) if WITH_MICE is defined.
Tested on: i386, alpha, sparc64
Approved by: re
of the EFI file system. This makes the EFI partition non-optional.
I don't think that the links are actually correct, given that all
the mount points are under /mnt when sysinstall is run as init.
(ie a non-upgrade). Thus: I think I need to go in once more, but
at least this doesn't get lost...
partitions marked as being of type efi. This change adds code to
1. actually run the newfs command at mount time (install.c),
2. display the newfs state on screen (label.c)
3. allow toggling of the newfs state (label.c)
Even though newfs(8)-ing FAT partitions can be of use on i386
machines in general, it has been opted to minimize impact for
now.
With this change there's no a priori difference between EFI and
FAT partitions. With this change and the corresponding change to
libdisk, we can create EFI partitions, just like regular FAT
partitions.
something applies to. So change #ifndef to an explicit list of defines.
* Treate sparc64 and ia64 as 64-bit platforms, which means larger roots.
* sparc64 should halt back to the firmware, not reset.
* sparc64 doesn't need to play MS-DOS/BIOS partition crap games.
Reviewed by: jake
so know we have proper PKG registration and dependency information.
This is a WIP for 5.0 DP #1, so it is still rough around the edges and
does not GC the old XFree86 3.3.6 handling stuff that should be GC'ed.
Sponsored by: FreeBSD Mall, Inc.
block sizees larger than 8192 bytes have been resolved, as per the
following deltas:
rev 1.34 src/sys/boot/i386/boot2/boot2.c
rev 1.5 src/sys/boot/alpha/boot1/sys.c
filesystem using a block size of 8192. Since this seems unlikely to
be fixed soon (specifically in time for 4.5-RELEASE on the RELENG_4
branch), fall back to the old default block and frag sizes of 8192 and
1024 in sysinstall on the alpha.
Reported by: jhb
16384/2048.
Following recent discussions on the -arch mailing list, involving dillon
and mckusick, this change parallels the one made over a decade ago when
the default was bumped up from 4096/512.
This should provide significant performance improvements for most
folks, less significant performance losses for a few folks and
wasted space lost to large fragments for many folks.
For discussion, please see the following thread in the -arch archive:
Subject: Using a larger block size on large filesystems
The discussion ceases to be relevant when the issue of partitioning
schemes is raised.
have a USB mouse. Here's the deal on how this works: USB mouse have
moused run for them automatically by usbd so we don't need to setup moused
for them. We do need to setup moused for other mice though, so if the
user has a USB mouse, we don't need to do anything. Hence the wording
"Do you have a non-USB mouse installed?" for the question. The question
can be reworded as "Do you have a PS/2 or Serial mouse installed?" instead
if that is preferred.
sysinstall will automatically expand the previous partition to take up
the freed up space. So you can 'D'elete /home and /usr will get the
combined space, or you can 'D'elete /tmp and /var will get the combined space.
This gives the user, developer, or lay person a huge amount of flexibility
in constructing partitions from an 'A'uto base. It takes only 3 or 4
keystrokes to achieve virtually any combination of having or not having
a /tmp and/or /home after doing an 'A'uto create.
Change 'A'uto creation of /var/tmp to 'A'uto creation /tmp, which should
be less controversial.
MFC after: 6 days
defaults both in regards to the size of the partitions that are created
and in regards to safety and functional separation.
Still TODO: extend the previous partition to cover a deleted partition
if the previous partiton was auto-created, and supply some sort of
solution for /tmp.
Reviewed by: Just about everyone
Approved by: Nobody except maybe my pet mouse fred
Obtained from: God, so complain to HIM
MFC after: 1 week
1) Use devfs to mount filesystems. If mounting devfs is fail,
fallback to old code.
2) When fscking filesystems, use 'fsck_ffs' explicitly. As a
result, we no longer need 'fsck' the wrapper program.
Reviewed by: jkh
Since userconfig feature is implemented by tweaking variables (hint.*)
with loader(8), we can put back an equivalent feature. Maybe the first
step for this is to commit yokota-san's patch (add userconfig command
for loader).
Approved by: jkh
and RTSOL in sysinstall. If the respective TRY_FOO variable is set to
"YES" then it will be tried without prompting the user.
However, if the TRY_FOO variable is set to "NO" then the user will not
be prompted for a choice. This is the correct behavior, since we want
people to be able to script sysinstall in either case.
However, the default TRY_FOO variable has been "NO" since 1999. This
is incorrect, and when the logic was corrected in tcpip.c this has the
effect of never giving the user a choice to use DHCP or IPv6. The
value should be undefined until it is set by a script or by the user.
Submitted by: Randy Pratt, Chern Lee, many others.
the name for the moderate security profile is "moderate", not
"medium", so update this one reference to it as "medium".
This is a 4.4-RELEASE MFC candidate.
MFC after: 2 days
by providing the opportunity to edit inetd.conf during the system
installation process. The following modifications were made:
(1) Expand the Anonymous FTP description dialog to indicate that inetd
and ftpd must be enabled before it can be used.
(2) Introduce a new configInetd() pair of dialogs, the first describing
inetd, giving a couple of examples of services that require it, and
hinting at potential risk, then asking the user if they wish to
enable it. The second indicates that inetd.conf must be configured
to enabled specific services, and asks if the user would like to
load inetd.conf into the editor to modify it. Add this
configuration action to the index.
There are some further improvements that might be considered:
(1) Provide a more inetd.conf-specific configuration tool that speaks
inetd.conf(5). However, this is made difficult by the "yet another
configuration format" nature of inetd.conf, as well as its use of
commenting to disable services, rather than an in-syntax way to
disable a service without commenting it out. Submissions here
would probably be welcome.
(2) There's some overlap between settings in the somewhat obtuse
Security Profile mechanism and other settings, including the inetd
setting, and NFS server configuration. As features become
individually tunable, they should probably be removed from the
security profile mechanism. Otherwise, somewhat counter-intuitively,
sysinstall (in practice) queries multiple times whether inetd, nfsd,
etc, should be enabled/disabled. A possible future direction might
be to drive profiles not by degree of paranoia, rather, the set
of services desired. Or simply to remove the Security Profile
mechanism and resort to feature-driven configuration.
Reviewed by: imp, chris, jake, nate, -arch, -stable
