<feed xmlns='http://www.w3.org/2005/Atom'>
<title>src/usr.sbin/sysinstall/help, branch release/6.0.0_cvs</title>
<subtitle>FreeBSD source tree</subtitle>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/'/>
<entry>
<title>Join the 21st century: Cryptography is no longer an optional component</title>
<updated>2004-08-06T07:27:08+00:00</updated>
<author>
<name>Colin Percival</name>
<email>cperciva@FreeBSD.org</email>
</author>
<published>2004-08-06T07:27:08+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=d37df47d3104331743c4d05ebba3f996f5a2308a'/>
<id>d37df47d3104331743c4d05ebba3f996f5a2308a</id>
<content type='text'>
of releases.  The -DNOCRYPT build option still exists for anyone who
really wants to build non-cryptographic binaries, but the "crypto"
release distribution is now part of "base", and anyone installing from a
release will get cryptographic binaries.

Approved by:	re (scottl), markm
Discussed on:	freebsd-current, in late April 2004
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
of releases.  The -DNOCRYPT build option still exists for anyone who
really wants to build non-cryptographic binaries, but the "crypto"
release distribution is now part of "base", and anyone installing from a
release will get cryptographic binaries.

Approved by:	re (scottl), markm
Discussed on:	freebsd-current, in late April 2004
</pre>
</div>
</content>
</entry>
<entry>
<title>Re-linewrap help file on securelevels in sysinstall: sysinstall is</title>
<updated>2003-12-16T22:55:28+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2003-12-16T22:55:28+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=1d1daa2f0023d3dbbdd866e5bbe838b3c85f961b'/>
<id>1d1daa2f0023d3dbbdd866e5bbe838b3c85f961b</id>
<content type='text'>
mostly used on 80x25 displays, and the actual window is about ten
characters narrower than that, resulting in the need for horizontal
scrolling.  No functional change.

RELENG_5_2 candidate.
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
mostly used on 80x25 displays, and the actual window is about ten
characters narrower than that, resulting in the need for horizontal
scrolling.  No functional change.

RELENG_5_2 candidate.
</pre>
</div>
</content>
</entry>
<entry>
<title>Add a Securelevel sub-menu to the Security configuration menu,</title>
<updated>2003-11-29T21:44:51+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2003-11-29T21:44:51+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4b51d758d5d8c59b73e2a9379875223a41ba9cb7'/>
<id>4b51d758d5d8c59b73e2a9379875223a41ba9cb7</id>
<content type='text'>
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)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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)
</pre>
</div>
</content>
</entry>
<entry>
<title>Remove security profiles from sysinstall.  Currently, security profile</title>
<updated>2003-11-28T18:47:45+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2003-11-28T18:47:45+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=7fba2041a7e4b7d4d9f89024a63282c608c67dc2'/>
<id>7fba2041a7e4b7d4d9f89024a63282c608c67dc2</id>
<content type='text'>
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)
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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)
</pre>
</div>
</content>
</entry>
<entry>
<title>Don't use UFS2 by default during the install process on PC98, as the</title>
<updated>2003-04-21T20:57:20+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2003-04-21T20:57:20+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=b5abb6e6b0cca9441fdaa3f866d7ce2836f92c5e'/>
<id>b5abb6e6b0cca9441fdaa3f866d7ce2836f92c5e</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>Throw the switch--change to UFS2 as our default file system format for</title>
<updated>2003-04-20T14:08:05+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2003-04-20T14:08:05+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=b459937e0c1f6af682e795636a45129b451a1962'/>
<id>b459937e0c1f6af682e795636a45129b451a1962</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>If you don't create a /usr filesystem, / will need 200MB.</title>
<updated>2003-01-13T21:57:07+00:00</updated>
<author>
<name>Jun Kuriyama</name>
<email>kuriyama@FreeBSD.org</email>
</author>
<published>2003-01-13T21:57:07+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=6dcbe61c90c26532c8e0fb73a99c470ba4e286ef'/>
<id>6dcbe61c90c26532c8e0fb73a99c470ba4e286ef</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Update ROOT_MIN_SIZE for i386 to 118MB (and other ROOT_*_SIZE).</title>
<updated>2002-12-15T12:05:00+00:00</updated>
<author>
<name>Jun Kuriyama</name>
<email>kuriyama@FreeBSD.org</email>
</author>
<published>2002-12-15T12:05:00+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=b3e8a7eb8f5a19dbaed21877e06aa52fd854845d'/>
<id>b3e8a7eb8f5a19dbaed21877e06aa52fd854845d</id>
<content type='text'>
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
</pre>
</div>
</content>
</entry>
<entry>
<title>Reformulate how sysinstall handles file system options in the label</title>
<updated>2002-12-03T22:25:47+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2002-12-03T22:25:47+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=bf1e70b2302d1305f5350092ec9c125b4c2905d0'/>
<id>bf1e70b2302d1305f5350092ec9c125b4c2905d0</id>
<content type='text'>
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
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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
</pre>
</div>
</content>
</entry>
<entry>
<title>o Expand the text describing the Security options menu.</title>
<updated>2001-12-21T19:51:44+00:00</updated>
<author>
<name>Robert Watson</name>
<email>rwatson@FreeBSD.org</email>
</author>
<published>2001-12-21T19:51:44+00:00</published>
<link rel='alternate' type='text/html' href='http://cgit.freebsd.org/src/commit/?id=4d0032bde9c08eb1783595f71cede60b22522d78'/>
<id>4d0032bde9c08eb1783595f71cede60b22522d78</id>
<content type='text'>
o Move nfs_reserved_port_only out of security profiles (where it was
  set somewhat improperly) to the Security options menu directly.
  Previously, the variable was set to true for Moderate, but not for
  Extreme, which is at best inconsistent.
o Update the Security Profiles help file to remove reference to the
  NFS reserved port.

o Note that the kernel currently defaults the sysctl to '0', but
  sysinstall has changed it to '1' as a default as of late; however,
  rc.conf sets the value to NO as the default.  This change brings
  them relatively into sync.

Sponsored by:	DARPA, NAI Labs
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
o Move nfs_reserved_port_only out of security profiles (where it was
  set somewhat improperly) to the Security options menu directly.
  Previously, the variable was set to true for Moderate, but not for
  Extreme, which is at best inconsistent.
o Update the Security Profiles help file to remove reference to the
  NFS reserved port.

o Note that the kernel currently defaults the sysctl to '0', but
  sysinstall has changed it to '1' as a default as of late; however,
  rc.conf sets the value to NO as the default.  This change brings
  them relatively into sync.

Sponsored by:	DARPA, NAI Labs
</pre>
</div>
</content>
</entry>
</feed>
