Physical Host Usage

Start using a physical host.

Here is the currently recommended process:

Physical connectivity

Presumably, the physical environment checks made sure that things are physically working.

Place machine into correct network layout. For instance, if this is a multi-NIC system that is intended to be used as a firewall, create network connections that cause network traffic to go through this system, if such a layout is feasible to implement at this time. (The ###network layout may show some details about sample diagrams of network layouts. For instance, a network may be based on using a switch that sends traffic to a single mutli-NIC system.)

See also: “Configuring the physical host machine/environment” from theta.htm

OS installation

Currently, the only detail provided here is a reference to these resources:

Post OS installation

Here are some notes. This was previously not considered part of the guide, as additional “polish” (reviewing the content for quality, and making improvements) was deemed necessary. It has now been improved somewhat, and may be a bit more worthwhile.

This section may vary quite a bit based on what operating system is being used. For that reason, it was initially not even really considered to be part of this guide. This section may be one that is particularly prone to being helped by additional resources, such as instructions left by a classroom instructor, or other support systems.

  • Secure the system.
    • Identify TCP ports and UDP ports (see: checking TCP ports and UDP ports
    • Be familiar with what starts up. (Details may be added here at a later time. If you're quite concerned about this, system startup process may have details.)
    • Be familiar with the operating system's post-installation introduction.
    • There may be additional steps to security an operating system. The specific details can vary between operating systems, so a general guide may not be able to cover all aspects of every system (without becoming a lot less generalized of a guide).
    • Furthermore, this guide is currently not providing details about some steps that may be related to security the system. Some topics, which might not be thoroughly covered by this guide, include:

      • physically security the physical system, so that somebody doesn't just walk away with the system without needing to physically break a security mechanism, or at least being acknowledged by a security guard
      • Having user accounts be sufficiently locked down
      • installing protection software (“anti-virus”/“anti-malware” software, host-based firewall)

      There may be other steps that should be done too, even if they aren't necessarily focused on security. For example, ensure that any necessary information (like how to log in) has been sufficiently documented.

      This guide covers many of these topics, in more detail, for the virtual machines that get created. The guide is kind of hoping that the “physical” system is reasonably secure, and so this guide isn't going into a lot of details about how to make that happen. Doing so would be spending quite a bit of time on a topic that may often be unnecessary, which is why this guide isn't covering that in much detail here.

      Note that if the physical system actually isn't suitably secure, that likely compromises the security of virtual machines running on the system, permitting vulnerabilities that could be rather devestating in severity. So, although this guide doesn't go into a lot of details about such topics, do make sure that such topics are suitably handled if this physical system will be handling any data that is actually important to keep confidential/accurate.

At this point, the next step may often depend on how the computer will regularly be used. For many computers that are designed to be a server, the expectation is that a person will be able to remotely control the machine. Setting up the ability to use remote access now may be a very high priority, since successful completion of that task can remove the dependency of certain requirements. Requirements that disappear may include having a connected keyboard and (realistically) a monitor and (really optional) a rodent. Enabling remote access may also enable a person to use a more comfortable interface, such as a graphical interface on a remote system that provides convenient method to perform an ability like “copy and paste”. If the “remote access” method is more convenient than the interface that the system uses for a local user, then setting up remote access soon will simply make sense.

This will also involve setting up networking. So, as an example, this means that an IP address will need to be assigned.

  • If help is needed, network assignment is covered by network addressing. Specifically, automatic addressing might be easiest, although some setup is require for some types of automatic address assignment to work as intended. For that reason, manual network addressing may be easier and quicker to get to work in the short term.

Once that is functional, make sure that the functionality will continue after the system reboots.

After getting some basic networking functional (such as networking to the switch on the LAN), another desirable action may be to get additional networking functional (e.g.: Internet access). Start by trying to connect to somewhere directly from the machine. Once that is operational, another common step may be to enable traffic forwarding (so the LAN can connect to an IP address on another NIC, and to an IP address in the same subnet as that NIC). Routing may need to be handled. One way to handle routing is to use NAT; that technique is particularly common for IPv4 connections.

Getting these things working are generally good to pursue before trying to use any external DNS servers.

Throughout this time, troubleshooting DNS should start with making sure that the necessary IP communications are working.

Again: once all that works, reboot. It is easy to try to get things working by changing a setting, and then not adjust the system's startup process to automatically re-create the working situation.

Hardware checking

Make sure that all important hardware works. Some hardware might not be tested, such as an microphone audio input jack/port (if nobody is expected to be using the microphone on the system), or some other connector that is not expected to be used (perhaps because nobody plans to ever use any hardware that would fit into that connector). For unimportant systems, checking every single USB port might be overkill (as often systems have been known to come with a few USB ports, and maybe a few more, or possibly even a few more!) Although, if the computer's performance is important (such as if the computer will be given to an important supervisor), taking some time to perform such testing may be more useful.

Check the system for hardware which has been detected, but which is not supported by current software drivers. Detecting hardware may have info helpful for handling hardware which hasn't been detected.

Handling hardware that isn't working yet
OpenBSD
Completely undetected devices

OpenBSD Manual Page: Introduction to Section 4: Device Drivers notes, “When the resultant system is booted, the autoconfiguration facilities in the system probe for the device and, if found, enable the software support for it. If a device does not respond at autoconfiguration time it is not accessible at any time afterwards. To enable a device which did not autoconfigure, the system will have to be rebooted.” (This seems somewhat unlikely: if a USB device was powered off, and didn't respond when the system starts up, then it could probably be powered on and then be detected. However, presumably that documentation is probably accurate for devices that are built into the motherboard, and most internal devices that aren't designed to be turned off and on.) This documentation indicates that if a device isn't getting detected during hardware probes, then there is no standard way to work around the problem. The device needs to be responsive to hardware probes, in which case it is likely to be showing up in the dmesg.

Handling “not configured” devices
Checking for “not configured” devices

Per OpenBSD: Generic info about device “not configured” message, a message of “not configured” indicates that hardware is not being actively supported. So, check for such a message.

Knowing where the boot messages gets stored can be helpful. Here is an example of checking for such a message in OpenBSD:

grep -i "not configured" /var/run/dmesg.boot

In case anything was detected after being booted, you may wish to try this as well:

dmesg | grep -i "not configured"

If devices have been detected, but are not configured, you may wish to check the following:

  • If the device seems like it should be supported by one of the device drivers, but it isn't working, check http://firmware.openbsd.org (which may simply redirect to the http://firmware.openbsd.org/firmware directory), which contains files for the current version of OpenBSD and older versions. If a file related to that device driver exists, that is almost certainly the problem if that situation hasn't been addressed since OpenBSD has been installed. The -a option to fw_update may be helpful. If networking isn't functional, figure out some way to get the data onto the computer, and then use the -p option. If this resolves the problem, note that the best solution is generally for the hardware vendor to provide functional drivers that comply with the licensing requirements necessary to be included with the such operating systems.
  • Additional information that may be useful can include:
Microsoft Windows

See if there's anything with undesirable values:

Not installed:
WMIC /NAMESPACE:\\ROOT\CIMV2 PATH Win32_PNPEntity WHERE Status=11

Installation errors:

WMIC /NAMESPACE:\\ROOT\CIMV2 PATH Win32_PNPEntity WHERE Status=12

The following should pick up “Status=Degraded” or “Status=Error”:

WMIC /NAMESPACE:\\ROOT\CIMV2 PATH Win32_PNPEntity WHERE "Status<>'OK' AND Status<>''" GET Caption,Description,Name,Service,Status

The following should pick up another possible problem:

WMIC /NAMESPACE:\\ROOT\CIMV2 PATH Win32_PNPEntity WHERE "ConfigManagerErrorCode<>'0'" GET Caption,ConfigManagerErrorCode,Description,Name,Service
WMIC /NAMESPACE:\\ROOT\CIMV2 PATH Win32_PNPEntity WHERE "Availability<>'OK' AND Availability<>''" GET Availability,Caption,Description,Name,Service

If you need more information about a device, there is some available. For instnace:

WMIC /NAMESPACE:\\ROOT\CIMV2 PATH Win32_PNPEntity GET Caption,Description,DeviceID,HardwareID,Manufacturer,PNPDeviceID,Name,Service /FORMAT:LIST

or, for even more info:

WMIC /NAMESPACE:\\ROOT\CIMV2 PATH Win32_PNPEntity GET Caption,Description,DeviceID,HardwareID,Manufacturer,PNPDeviceID,Name,Service

(Note: The manufacturer listed is the manufacturer of the device driver, and not necessarily the manufacturer of a device. For example, “Microsoft” may be listed as the manufacturer of many device drivers that are bundled with Microsoft Windows. To figure out the manufacturer of the device, check out the PNPDeviceID, and see Detecting hardware for the “Plug 'n Play info” section.)

(Microsoft forums about using Win32_PnPEntity with WMI)

Report to operating system releasers. (If applicable. Microsoft probably doesn't care. The OpenBSD team seems to like at least some reports.)

Making a virtual machine: section called “Setting up a physical machine” may have additional information like hardware testing. Note: that is not part of this guide; it is part of an older guide.