Age | Commit message (Collapse) | Author |
|
pointed by miod@
|
|
|
|
|
|
|
|
|
|
caveats from their v.1 SRM.
|
|
authoritative source of information.
|
|
|
|
|
|
the Makefile to provide this value. Makes the generation of all the
installation notes easier.
|
|
|
|
|
|
|
|
Every system has a name, and thus generated keys with that
name, even if there is no currently configured network.
So, ask for a system hostname before configuring the network.
Eliminate /tmp/myname and just keep hostname set to the lastest name
and FQDN.
Construct /etc/myname from hostname as configuration data is being
saved. Construct /etc/hosts (preserving the informative leading comment
from the /etc/hosts file in etcXX.tgx) at the same time.
Construct an appropriate /etc/hosts file even if the network is not
configured.
During upgrade, if the user enables the network using the existing
configuration, don't ask about the domain name - just use the
configured one.
Take care to handle existing /etc/myname files which do not necessarily
have a FQDN.
Originally problem with hostname handling pointed out by beck@.
ok deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
them in the installed system.
ok deraadt@. (which I forgot to mention for the last commit).
|
|
devices, to allow ask_which() to be used for interface configuration.
Rework network interface configuration logic to use ask_which() instead
of local code. This
1) May fix the problem noted by David Norman, where the prompts are
somehow broken, since no such problems have been noted with the
ask_which() code.
2) Shrinks the install output by a few lines.
3) Makes the install script smaller and clearer.
4) Makes interface configuration consistant with other 'device'
configurations.
5) Makes it impossible for a user to configure an interface more than
once.
Add the interface name to the 'IP address (or dhcp)' question. This
makes it more informative, especially if a '!' or '!foo' shell escape
has been used and overwritten the list of interfaces and the display of
the name of the one being configured.
|
|
|
|
1) If the user escapes to a shell with '!' or executes a command with
'!foo' at a prompt then repeat the prompt when the shell or command
returns.
2) If ask_which() is passed an empty list of devices , then set resp to
'done' and return. Replaces a couple of checks before calling
ask_which(). Also emit a message about the lack of devices.
3) In ask_which(), delete any trailing blank which rmel() may have
appended to the device list. Replaces a check before calling
ask_which().
4) Remove an unneeded blank line before the 'invalid choice' message
from ask_which().
5) Make the first disk device the default answer when asking for which
disk contains install sets.
A few code/verbiage nits:
1) make _a a local in cutlast().
2) use normal ': ${_defdev:=done}' idiom instead of an or condition in
ask_which.
3) Eliminate an unnecessary blank line/paragraph by putting 3(!)
sentences into a single paragraph when describing process of selecting
install sets.
4) Eliminate another unnecessary blank line between the list of
possible install sources and the question about which one to use.
5) Eliminate another unnecessary blank line before the 'Extract
more sets?' question
6) Eliminate a double blank line after the sanity check error
messages.
ok deraadt@.
|
|
ok deraadt@ millert@
|
|
|
|
|
|
|
|
by implementing the rules:
Only '/' is neither nodev nor nosuid. i.e. it can obviously *always*
contain devices or setuid programs.
Every other mounted filesystem is nodev. If the user chooses to mount
/dev as a separate filesystem, then on the user's head be it.
The only directories that install puts suid binaries into (as of 3.2)
are:
/sbin
/usr/bin
/usr/sbin
/usr/libexec
/usr/libexec/auth
/usr/X11R6/bin
and ports and users can do who knows what to /usr/local and sub
directories thereof.
So try to ensure that only filesystems that are mounted at or above
these directories can contain suid programs. In the case of
/usr/libexec, give blanket permission for subdirectories.
Note that if *all* the above are split into separate filesystems the
install process will attempt a couple of cross-device links when
installing base32.tgz, and fail.
ok deraadt@.
|
|
|
|
|
|
separating items.
This allows a compaction of the displayed lines for device selection.
Customize the device selection routine so the actual device type is
shown (disk or CD-ROM). Rename ask_fordev to ask_which so the
invocations (with device type) read better.
|
|
|
|
|
|
|
|
|
|
$ROOTDEV and ${ROOTDISK}b can be used for swap. Also shortens output
generated during (successful) install.
Fix problem with upgrade on systems with many disk devices by
automatically creating devices encountered during the fsck'ing of fstab
filesystems. Problem noted by Dethlef Madsen and Nick Nauwelaerts.
Adjust some verbiage in i386 install.md to make it more consistant.
Reformat welcome message to make sure all lines are <80 characters wide.
Minor cleanups.
|
|
output produced when the user opts to have the install script use the
entire disk for OpenBSD.
ok deraadt@.
|
|
|
|
|
|
|
|
|
|
the install example will easily fit on the CD insert at some
reasonable font size. Reword many messages and questions for same
reason.
In addition:
1) Add '...done.' to match 'Installing boot block...'
2) During install, after asking which is the root disk, start
initializing it immediately rather than asking again which disk to
work on.
3) Move munged fstab filesystem mounting to *before* network
initialization so that if you bail out during network initialization
and restart you do not have to go through disk initialization again.
Also puts fsck and mount messages close to each other rather than
spitting out the latter just before root password questions.
4) Make 'usr/obj' nosuid,nodev by default, /home nodev by default.
5) For network interfaces only show the complete list of media options
if the user indicates they want to change the default.
6) Move the question about the ftp server supporting passive ftp to
*after* selecting the ftp server where it is more 'rational' and can
easily be made more concise.
7) Don't bother umount'ing filesystems or stopping the dhclient after
a successful install/upgrade. The next step is a reboot after all.
Some minor code tweaks and comment cleanup while in the area.
Tested in recent snapshots. Suggested by & ok deraadt@.
|
|
|
|
|
|
|
|
|
|
|
|
|