This section includes some core configuration changes, like adjusting what account is used to perform sensitive operations, and getting proper Internet access. Other changes, like displaying the host name, may be less critical for security and functionality, but can be a really good idea. (Doing that reduces the chances of accidentally doing something on a different machine than intended.)

Handle user accounts
See: initial changes to user accounts.
The next steps: Rationale
Rationale behind step order

There are multiple steps that make sense to do next. One is to focus on post-reboot assignment survivability. enabling full networking to the local link should be done before either of the other options described here, which is allowing remote access or network traffic forwarding.

Some of those can be done in any order. post-reboot assignment survivability makes sense if there is little time available before temporary loss of access to the computer, although there may be some benefit or requirement to doing some of those steps after the other tasks.

(Some of this text is lengthier than desired, and may be moved to another page, condensed/re-worded, or removed entirely.) Handling configuration to affect post-reboot has now been merged in with earlier documentation, and there is a "Reboot test" section.

Older text: Rationale

There are numerous next steps to perform. The step to perform next may vary based on some various factors:

  • If a person is running low on time, before access to a system is likely to be lost, then one of the most important steps is to make a device able to re-obtain the settings that are working so far. For instance, a person may be planning to take a break from this project, perhaps because they are using a computer lab that will soon be closing for the rest of the day. It is also possible that such people may not be guaranteed to have convenient access to the same computer the next time that they decide to make some further progress. In this scenario, saving a device's IP addresses may seem like a higher priority than performing some other actions which might also be temporary in nature, and lost.
  • enabling full networking to the local link may adjust the network design, so it should be done before the next steps
  • If a person simply wants to have a device be able to communicate with a remote network link as soon as possible, then adjusting network settings may be a higher priority. To obtain this goal, network traffic forwarding may be the priority item.
  • A person might wish to set up some preferred “remote access” software, like being able to use SSH to get a “remote access” “command line shell” prompt. This may be a higher priority if a person does not want to fuss with using a local display. For instance, a physical system may require using a keyboard and/or monitor which may be less convenient or comfortable, so removing the requirement to using that hardware may be nice. For a virtual machine, using the “local” display might have some disadvantages, like inferior support for “copy and paste”, or the need to go through steps to set up tunneling for VNC network traffic. If a person expects to be able to run the computer for additional hours, then gaining this short term benefit sooner may be probable to be a higher priority than getting things working in the long term. The steps for this are in a section about allowing remote access.

The whole point of this “rationale” section is to point out that there are various approaches, and this guide's sense of priorities may not match everybody's priorities.

Of those, one reason sounds quite likely to be a significantly compelling priority for many people, which is having the device survive the reboot process. There are reasons why that section wasn't listed first. That step involves setting some values that might get changed, and testing the process by rebooting a device. A reboot may be needed later, anyway. (For instance, after adjusting an OpenBSD kernel to support a hardware clock set to the local time, the kernel must be restarted for this to take effect.) If the step gets taken early, to solidify some settings, then the step may just be needed again later, to make sure that other settings are in place, sufficiently. By trying to delay that step, the guide is hoping to minimize a bit of extra work for people who do have the necessary resources (like the ability to have the computer keep running until additional time is spent working on it).

In a highly structured training environment, an instructor of a class might choose to have students do things in a particular order. (This might even be something that the instructor chooses to change.) In cases where a leader is not providing specific instructions about which order to do things, this guide encourages people to complete these sections in whatever order makes sense.

A person may find that they use this guide multiple times, and their sense of priorities are different when they are working on this guide at another time. That's fine.

Currently, this guide is written to do the following tasks, in the following order.

However, as explained in the “rationale” section, if people have a reason to have a different priority done first, then, by all means, do that. Just know that if you check out that guide too early, then there may be some advice that doesn't apply yet. Go ahead and just save the settings that do make sense to save, and plan to re-visit the guide later. (Plan to make some notes about what was done early, which may make things easier when trying to not accidentally skip some step(s) in a later pass.)

The way that this guide was written, those tasks are presented in that order. However, this guide is hereby acknowledging that some people may wish to do things in a different order, perhaps based on time constraints. Probably, the most likely scenario will be that people who are low on time right now will want to spend time having the current configuration steps survive the reboot process. Some people might care more about enabling network traffic forwarding, more than allowing a system to get a remote access shell prompt. If you have reasons to desire a different order, feel free to look at those options in any order.

In a highly structured training environment, an instructor of a class might choose to have students do things in a particular order. (This might even be something that the instructor chooses to change.) In cases where a leader is not providing specific instructions about which order to do things, this guide encourages people to complete these sections in whatever order makes sense.

A key reason that all this was communicated is to note that there is some very real flexibility about the order that some of these things are done. A person may find that they use this guide multiple times, and their sense of priorities are different when they are working on this guide at another time. As a result, actions may get done in a different order. This guide is trying to point out: that is totally fine.

The next steps

(As noted in the rationale that was just provided, there may be some flexibility in which order to perform these steps. If this guide is part of an organized project, such as a course of formal instruction, then it may be worthwhile to check of the project's directions specify which of these tasks to perform next.)

Proceed to do the following steps.

enabling full networking to the local link
Rationale

Sometimes, software may use a method of networking which is quite likely to work with minimal configuration, but which might have some noteworthy limitations. For example, Qemu defaults to using a form of NAT which permits TCP/IPv4 and UDP/IPv4, but does not permit other IPv4 traffic like ICMP/IPv4, and which does not support any other communications including IPv6. In general, usage of NAT is also known to cause some issues, like FTP not working as hoped.

In the opinion of the author of this text, this is one of the longer and more tedious parts of the whole process. However, getting this task out of the way is sensible to do at this point. If changes are going to be made, it makes sense to get those changes made soon, before investing further efforts into other things that might rely on the design of the system's networking.

So, go ahead and get this done right away.

See: enabling full networking to the local link.

Allow remote access

This covers the next set of early steps: creating a user, and enabling remote access. This includes remote access from the LAN. Note that forwarding traffic, so that Internet communications, is not part of the section on allowing remote access.

  • Log into the virtual machine.
    • The goal is going to be to have the physical machine SSH into the virtual machine.
  • See: allow remote access.
Network communications

Enabling network traffic forwarding: regular communication with the Internet requires that traffic gets routed, and that may not be happening if forwarding does not occur. Having this being broken can affect outgoing network traffic, including replies to connections that start with incoming connections.

Once forwarding is enabled, you should be able to communiate with every IP address on the physical machine. However, two-way communications might not be able to be established when the traffic needs to go through the firewall to another device. This might be particularly unlikely to work with IPv4. If the physical device has an IPv4 public address, then NAT is the typical solution. Details are covered by Enable Network Communications/Traffic Handling for Virtual Machines.

post-reboot assignment survivability
See: post-reboot assignment survivability