Building a Network

Introductory Material

Introduction

This guide is meant to provide information on how to quickly set up programs that perform several useful tasks.

Many of the rest of the resources on this site have been designed with the hopes that the information will be fairly generic, and able to apply to many different situations. However, in hind sight, the result is that a lot of reading may be required to even perform some basic tasks.

This guide is meant to hone in on some of the more specific documentation that is available, which will help enable successful deployment with fairly minimal fussing. Some technical steps may be covered by this guide, for now. Hopefully such details will then be able to be moved to a more generic location, when the time is right.

Current status: This guide is going to be focused on OpenBSD, Windows Server 2008, and Windows 7. There is a desire to get information to become more generic fairly soon, but those are the initial targets being focused on.

The OpenBSD guide might still be assuming that the system uses MBR disks. Until the related instructions get sufficiently updated, systems that use EFI may require the user to adapt.

Document everything

Document: names of systems, network addresses, credentials, and any tasks that were done to the machine beyond just installing the operating system. For example, document what software has been installed.

Skeletal document

For now, skipping the following is recommended:

Determine some identifiers (names)

(This isn't necessarily something that needs to be done ahead of time, if just making a simple test network. However, such planning is sensible when deploying actual production systems, so doing this may be good to get into good habits.)

This includes the identifiers of networks: identify the first address of subnets, and the subnet sizes.

LAN IP Skeletal Documentation has a hyperlink to system address usage.

Commonly-used DNS names

Install multiple operating systems

If necessary, create virtual machines. For example, making a virtual machine in Hyper-V is a fairly straight-forward guide.

(For the moment, this guide is skipping the details of recommending specific amounts of RAM or hard drive space.)

For installing an operating system, check for an installation guide related to the specific operating system. Full operating systems lists some various operating systems. As examples, the OpenBSD page has a section called “Installation guide(s)”. If a specific installation guide is not obtainable, check out generic guide to installing operating systems.

A good goal for an aspiring network technician, who wishes to have expertise in multiple platforms, may be to install a free operating system (e.g. OpenBSD), and a copy of Microsoft Windows that end users frequently have installed (e.g. Windows 7 Professional, with Service Pack 1), and a copy of Microsoft Windows Server (e.g. Microsoft Windows Server 2008). By having these two copies of Microsoft Windows, experiences with using an Active Directory domain can be experienced.

Even Microsoft operating systems might be legally downloadable. The Windows Server operating systems may have some sort of trial available (licensed for non-production use, such as test cases and educational purposes): see Microsoft and Compatible/Similar Operating System Code which has references to some resources. If the desired operating system is not available for download to the general public, options may exist for people who have a free account by Microsoft (e.g. Windows Server 2012 trial has done this), or perhaps some other downloading programs (DreamSpark for students of some educational institutions, TechNet subscriptions, etc.) People enrolled in any school should (especially instructors of IT) what resources are offered through the school. People may also want to check if employers offer any sort of account for free downloads.

Post-installation

Check if there are post-installation notes mentioned by the installation guide, or by the section about the specific operating system. For example, Microsoft and Compatible/Similar Operating System Code has a section called “Installation Notes” under the “Windows Server 2008” section.

If there is not a more specific guide, there is a generalized guide at setting up an operating system. However, that guide may be fairly time consuming. Until it is more streamlined, skipping that guide is recommended for situations where time budgets are short (such as a classroom environment). Experience has shown that an actual industry professional took substantial time (perhaps it was about a whole day or even weekend?) to go through (an earlier version of) that more-generalized guide. For those who have the resources (namely time) available, going through that guide is not a bad idea for people who just want to become more exposed to some various technology. (For some classroom environments, this might be a good (optional?) “homework” assignment.)

Get machines communicating with each other

If automatic network addressing is not yet set up (which will be common for a new network being created from scratch), set static addresses (see manual network addressing: setting current addresses). Make sure that each machine can ping itself on an non-loopback address that has been (automatically or manually) assigned.

Make sure the copy of Microsoft Windows for end users (e.g. Windows 7) can be successfully ping'ed.

Details helpful for operating systems that are Windows XP with Service Pack 2, or newer, may be available at Windows Firewall section, subsection called “Allowing diagnostic traffic through the firewall software bundled with Microsoft Windows”

Quit using static IP addresses on end user machines
Automatic IPv4 Addressing
Set up a DHCP server
Things to keep in mind for simplicity

If there is not a full understanding of subnets, knowing that may be helpful. (See subnets.) To simplify some basic facts on IPv4 subnets: In IPv4, if the subnet is a /24, this means the “prefix length” is 24 and this is the same thing as a subnet that uses the subnet mask of 255.255.255.0. For standard IPv4 subnets which are this size, the subnet contains all of the IPv4 addresses that share the same first three octets. So the 192.168.17/24 subnet contains all addresses from 192.168.17.0 through 192.168.17.255. (That range is including the generally unassignable addresses in the subnet, which are the addresses commonly known as the “Network ID” and the IPv4broadcast address”.

To do things simply, have the DHCP server software run on a computer that is connected to the same subnet that the DHCP clients will be contacting from. Also, the DHCP server should be listening to an IPv4 address that is in the same subnet as the addresses that will be handed out.

Make sure that the DHCP server is actually running (and configured). If that has not been set up yet, consider using one of the following solutions:

Using Microsoft's DHCP server from Windows Server

Go ahead and use Microsoft Windows Server's DHCP Server (installable Role) to become familiar with the process of installing that.

DHCP in Unix

ISC DHCP is a solution that works on Unix (and similar platforms, such as BSD and Linux).

The following was made for the DHCPd that is bundled with OpenBSD, which has been rather heavily modified but was based on ISC's DHCPd server. This is likely to be similar, or even identical enough, to work with ISC's DHCP.

Backup

First, back up any existing file. If the file has never been customized, make a convenient copy of the original version of the file. (If the first line works in the shell being used, then the second line will likely prompt. As the files will be identical at that point, either answer works for that prompt.)

[ ! -f /etc/dhcpddef.conf ] && sudo cp -i /etc/dhcpd.conf /etc/dhcpddef.conf
sudo cp -i /etc/dhcpd.conf /etc/dhcpddef.conf

If the cpytobak program has been installed, use it to make a convenient copy of the current state of the file.

cpytobak /etc/dhcpd.conf
Early/initial information gathering

Figure out the name of the NIC that will be receiving the DHCP traffic. (See: available NICs.) (This is rather optional, but useful for making intelligent comments while modifying the /etc/dhcpd.conf file. This can also be helpful for identifying an IPv4 address.)

Figure out the IPv4 address that traffic will be received at. In simple cases (that don't involve DHCPRelay), the DHCP server), the traffic will be received using the IPv4 address that is on the NIC that will receive the traffic. So, get that address. (See: determining the current IPv4 address.)

Identify a subnet that contains the addresses that will be used to hand out addresses from. For instance, if the addresses to be handed out will be 192.168.16.100 through 192.168.16.199, then the subnet may be “192.168.16.0/24”. (The /24 is saying the same thing as using a subnet mask of “255.255.255.0”.)

Editing the configuration file
Creating a basic configuration

These instructions are designed for people who can copy and paste many lines quickly. (These instructions may be less pleasant for anybody who does not have a working copy-and-paste setup to get information from the web onto the computer running the DHCP server.)

echo ${VISUAL}
sudo ${VISUAL} /etc/dhcpd.conf
Removing contents from the original file

If this is the original file bundled with OpenBSD, remove all lines after the first set of comments. (Keep the # See dhcpd.conf(5) and dhcpd(8) for more information.” and the next two lines (“#” followed by a blank line). Delete the remaining comments that describe that example. If those remaining comments are not deleted, they should be properly updated so that they don't mismatch the file's contents.)

Also, delete the remaining example text.

Copying an example

Instead of the example built into that file (which my have been functional with less customization), this guide is going to start off by using different example content.

See: section about DHCP servers. Go to the section about ISC (which, at the time of this writing, simply refers to the section about OpenBSD's DHCPd file).

Use the example text from the section about DHCP servers, in the section about OpenBSD's DHCPd, in the subsection called “An example file”. Copy the contents of that “example file”, and paste those contents after the remaining comments in the /etc/dhcpd.conf file.

Trimming fat

(The following steps remove some unnecessary details from the example documentation, in order to create an even simpler DHCP configuration file. However, if there is a desire to support multiple subnets or to support features such as a boot file for PXE, then leaving some of these options behind may be sensible. So, feel free to not follow these instructions if that is what makes sense.)

From that example, delete the configuration blocks that are related to “subnet 192.0.2.0” and “subnet 203.0.113.0” and “shared-network LOCAL-NET” (including the sub-block related to “subnet 192.168.1.0”), and also remove the comment block before the “shared-network LOCAL-NET”. All of those are fairly streamlined and simple examples, but we really only need one subnet block for the simplest implementation, and one of the blocks in the example file is even simpler than the other blocks.

The block to keep is the “subnet 198.51.100.0” If that was removed due to some hurried actions, and if copy-and-paste operations allow for simple re-creation, then just place it back.

Further cutomizations of the configuration file

The one problem with using the 198.51.100.0 subnet is that this subnet is officially reserved for examples/documentation. This subnet should not actually be used. So, pick a subnet if one hasn't yet been picked, and update the subnet line to point at the correct subnet.

Likewise, if there are actually multiple subnets being supported, then other remaining subnet blocks (from the example file) may also require customization.

The “option routers” is how the desired “default gateway” is specified. If the DHCP clients should be able to route packets to other subnets (such as networks on the Internet), make sure to specify a valid (correctly working) default gateway. Note that the default gateway's address needs to be an address from the subnet.

Update the range. The range refers to the addresses that will actually be handed out, so this is the first usable address and the last usable address. (This is not the same thing as the first and last address of the subnet, because the first address of a subnet is the network ID and so generally should not be handed out, and the last address of a subnet is the broadcast address and so definitely should not be getting handed out.)

Quite commonly addresses are reserved for devices that do not use randomly assigned addresses. For a /24 with 254 “usable” addresses, one address needs to be the default gateway, and people often hand out only a hundred addresses (commonly starting at .100 or .200) if the network is small and that amount is much more than what will be needed anyway. This means that under 40% of the possible addresses are in the range that get handed out, and that's fine.

Update the comment for the start of the subnet. Include the correct name of the NIC. Also include the purpose of the subnet. For example, if the network is not meant for WiFi, perhaps “main internal (wired) LAN” is more appropriate, or “servers that are virtual machines”.

More information may be found in the general section on DHCP/IPv4 server.

Testing the configuration

Testing the configuration file (before running the DHCP/IPv4 server).

Starting the DHCP/IPv4 server

Run “ date ”, as a good habit to do before running the DHCP server. This may be helpful later in figuring out which log file entries come before starting the DHCP server and which lines come after the DHCP server.

Figure out the name of the NIC that traffic will be getting received on, and then run “ dhcpd if0

Check if there are any errors logged to the /var/log/messages file. Upon success, no new entries will be added to the log file. If there are errors, there are usually fairly few lines, so the following may be sufficient: “ sudo tail -10 /var/run/messages

Check that the server is running. (See: currently running software.) There is no particular reason to believe that it is not running, but if there is a problem then this method is often the fastest way to notice the issue.

If there was a problem that has been fixed, run “ date ” again before trying again to run the server. If things are successful, the log entries may just show the prior errors, so the timestamp can be checked to notice that there are no new log entries.

Test the server (by using DHCP client software).

If everything seems to be working fine, make sure the software starts automatically when the system is rebooted. (The automatically started files section probably provides some helpful details for a solution that will work, although the system starting configuration files may provide details for an even classier solution.) Precise details on performing this do vary more between different operating systems. (For instance, even OpenBSD and FreeBSD use a similar approach but may have differences. Not only do these operating systems use different filenames, but they even use a single filename for a different purpose, and actions recommended for one operating system may be highly discouraged to do on the other operating system.)

Using/Testing a DHCP/IPv4 server

After setting up a DHCP server, one way to check if DHCP is working is to use DHCPLoc, which is by Microsoft and for Microsoft Windows. The program is generally not pre-installed to end user workstations, but is downloadable.

Often, though, a more convenient method is to just try a DHCP client. (If DHCP doesn't work, that may affect network communications. So DHCPLoc may be the safer choice when working on remote machines. However, on physically close machines, a botched DHCP renewal is often easy to recover from.)

Client-side support
Microsoft Windows 7

Make sure the Windows 7 machine is using a DHCP client. (See network addressing?)

If DHCP does not seem to be working as intended, then use IPConfig/All on the Windows 7 machine. Find out what DHCP server is being used. Make sure that DHCP server is a machine that you have under your control. Make sure network communication (ping) is working on that machine.

IPv6 Automatic Addressing

Automatic IPv6 Address Assignment is a bit more complex than the complexity of assigning IPv4 addresses automatically. First, obtain some basic familiarity with the key roles of “router advertisements”, NDP, SLAAC, DAD, and DHCPv6 by reading Overview of key technologies used for IPv6 automatic addressing.

This guide may be a bit less refined than the guide to getting DHCPIPv4 working well.

Router advertisements

The first step that is recommended is to have a router support “router advertisements”.

(Note: Using “router advertisements” is what corresponds to using “router solicitations”. Many people may start to think that rtsold is meant for a server that provides services to a client running rtsol, just like dhcpd runs on a computer that serves other computers running a DHCP server (and there are likely many other similar examples). That just simply is not the case with rtsold, even though the idea does seem fairly logical and consistent with behaviors seen in other cases. The rtsold program is meant for running on client systems, to automate sending messages like what the rtsol program sends, and the corresponding program for servers is whatever program provides “router advertisements”.)

The standards for network design specify that only routers send out router advertisements (as described by Overview of key technologies used for IPv6 automatic addressing and Router Advertisements and Device Roles and only non-routers send out router solicitations (as described by Router Advertisements and Device Roles: section on what types of devices may be auto-configured).

So, on a machine that forwards IPv6, start supporting router advertisements.

Router supporting router advertisements

Supporting the use of SLAAC can be easier than using some DHCPv6 implementations, so starting off with SLAAC is recommended as a first step. Using SLAAC will mean that the IPv6 subnet size should be /64 (as noted by Key IPv6 Automatic Addressing technologies: SLAAC's Required subnet “prefix length”/size).

Perform each of these steps (in order):

  1. configuring the “IPv6 support” code for compatibility with router advertisements
  2. router advertisement server (“Server software” section).
Testing the router advertisements
Overview

The section on supporting router advertisements mentions some possible software, including radvdump which works quite nicely, but that particular program might not be easily available.

The easiest way may be to make sure that the router is advertising a /64 subnet and that the router specifies that the client should use SLAAC. Then, have a client use SLAAC.

Specific steps
OpenBSD

In the IPv6 automatic addressing: Clients supporting router advertisements section, follow the steps in the sub-section called kernel configuration.

Then, later in the IPv6 automatic addressing: Clients supporting router advertisements, use some “Monitoring software”. Specifically, using rtsol ought to be a good choice.

Client-side support

See: supporting router advertisements (particularly the section about any required “kernel configuration” support).

The specific client software implementing NDP section may provide some options.

DHCPv6

Before trying to set a default gateway, see Routing information in DHCPv6.

For details on setting up a server, choose from an option described by DHCPv6 servers and then test the results with an option described by DHCPv6 clients.

Make sure the client knows how to run the DHCPv6 client when a routing advertisement specifies that a DHCPv6 client is supposed to get used. Details may vary between different implementations of NDP impelmentations, and may be discussed by the section on specific client software implementing NDP. Furthermore, the NDP software may simply run a command to run the DHCPv6 client software, and the command to do that may vary between different implementations of DHCPv6 client software. All in all, setting up this configuration can take as long as some of the other steps (like getting NDP working or getting DHCPv6 working).

If desired (and this might be good: if for no other reason, then just for the satisfaction of completing this type of configuration) have the router advertisements tell the client to use a DHCPv6 client.

Once everything is working, make sure that the necessary software will start when computers reboot.

Install a DNS server on the Microsoft Windows Server operating system

Being familiar with Microsoft's DNS Server is recommended. There are alternatives that can actually be deployed in real-world production use (see elsewhere on the section about DNS servers), but becoming familiar with Microsoft's interface may be helpful for handling computer networks that may already be using that interface.

Treat the Windows 7 machine as an Administrator's machine, by also giving it an AAAA record and an A record.

Make sure DHCP clients use the internal DNS server

The DHCP server needs to be configured to send out DNS server inforamtion as a DHCP option. (For Microsoft's server, see: Microsoft Windows Server's DHCP Server (installable Role): section on DHCP options.

Create, and use, an Active Directory domain

Currently, directions are only provided, here, for using a Windows Server operating system.

Setting up Active Directory in Windows Server

This is, by far, going to be simpler if the Active Directory domain controller is also going to be a DNS server. (Get DNS working first.)

If Windows Server is used, this involves making sure that the Active Directory Domain Services role is installed (see software installation: Installing Roles and Features in Microsoft Windows Server operating systems. Those who wish to use the graphical approach may find details in the section about software installation: Microsoft Windows Server's Add Roles Wizard.)

Run the promotion wizard: DCPromo.exe

A common process is to name the Active Directory domain something that ends with .local (when creating the Active Directory domain). Naming the Active Directory domain the same thing as a DNS name (e.g., naming them both example.com) has been known to cause substantial confusion: a very common practice is that a web site may be hosted on different equipment than the Active Directory domain controller. If both of these servers are trying to use the same name, then clients might not be able to successfully reach one of these servers. (Some experience has indicated that it woudl be the public website that is unreachable.) This might, or might not, be as likely to happen with newer versions of the operating system. For now, though, to play safe (including working well with older operating systems), this guide is recommending to make these names different.

For group environments, such as a classroom setting, check if there is a system in place for determining what to name the domain. (The leader (instructor) of the course can specify if there are any specific requirements.) Each technician who is making such a network could name the domain after the technician's name. (Find out if anybody else in the class also goes by the same name. If so, determine who may use a different spelling (possibly by using a last name.)

Joining the domain

Have another computer join the domain. If the client is having troubles joining the domain, make sure the client can communicate with the domain controller. Also make sure that the client is using the domain controller as the DNS server to use. If that's not true, verify whether the client is using DHCP to determine the names of DNS servers. If so, adjust the DHCP server to hand out the Active Directory domain controller's IP address as a DNS server to use. If that is not convenient/feasible, just adjust the client's list of DNS servers (using statically assigned “Primary” DNS server, if needed).

Create user accounts on all installed operating systems
Info: Where accounts are needed

Any machine that uses centralized authentication may just use that username.

  • To be a bit more specific, this means that after creating an account in Active Directory, you don't need to create an additional account for all the computers that use that security domain.
    • An even more specific example: If you added an account in Windows Server 2008's Active Directory, and then a Windows 7 machine joined the domain, then you don't need to also add an account on the Windows 7 machine. Instead, the Windows 7 machine will be able to juse use the Active Directory account.
How to add an account

For Active Directory, use Active Directory Users & Computers. For Unix-type of platforms, see: adding users.

What accounts are needed

For each authentication, create the following accounts:

admin

Make up a password that you document.

Make sure this user is an Administrator. (If this is a domain account, add the account to the group called “Domain Admins”. If this is a different Microsoft Windows account, have the user join the local group called Administrators. If this is a Unix machine, make sure the user is in the “wheel” group. (That might be easiest to handle while creating a user.)) (Details on user groups are available.)

reguser

Make up a password that you document.

Make sure this user is not an Administrator.

(your name)

Create a username that is named after yourself.

teacher

If this is a classroom environment, make this account. Ask the instructor of the course what password to use. The instructor should be able to enter the machine at any time.

Make sure all machines can access the Internet

If there are virtual machines, then they might often not be able to access the Internet at this point.

If the virtual machines are unable to communicate with the physical host, then make sure the physical host has an IP address that is on the same subnet as the virtual machines.

If the virtual machines can ping that one host on the physical machine, but cannot ping other hosts on the physical machine, then make sure traffic forwarding is enabled.

If the virtual machines can ping all IP addresses on the physical host, but not to IP addresses on other subnets (such as the default gateway that is used by the virtual machine), then the problem is probably that the ICMP traffic is reaching the destination, but that replies are not successfully being sent back to the virtual machines. To fix this, either adjust the routing of the remote systems (if such configuration is accessible), or enable NAT on the physical machine. (e.g., for Microsoft Windows Server, see using RRAS for traffic forwarding (and NAT).

Set up shares in Microsoft Windows
Sharing permissions test

Demonstrate how sharing permissions work. Make a note of the answers to the questions that get asked in this section.

  • Alter the Sharing permissions so that users can Read, but not Change/Write, the data
  • Make sure that users have security permissions to write data
  • In the following instructions, customize the references to \\sysname, using the name of the computer system that is sharing the directory.
  • Can a standard user see the contents of \\sysname\PubShared ?
  • Try to copy a file from a remote computer to the \\sysname\PubShared folder. Does that work?
  • Try to copy a file from the system that has the shared folder, and copy the file to \\sysname\PubShared folder. Does that work?
  • Try to copy a file from the system that has the shared folder, to the \Shared\ directory. (For example, try copying the file from C:\Shared\ directory.) Does that work?
  • If that does work, can a remote system access the file by using a shared folder?
  • From a computer that this shared folder is not residing on, use a remote access program (such as Remote Desktop Connection (“RDC”) (over Remote Desktop Protocol (“RDP”)), in the “RDC client software” section; or use RFB/VNC) to remotely control of a desktop session. From that session, try copying a file from the computer with the shared folder, to \Shared directory. Does that work?
  • Can a standard user access \\sysname\C$\Shared folder?
  • Can an Administrator access \\sysname\C$\Shared folder?

Considering these results, explain how the permissions work.

Run Microsoft Security Baseline Analyzer. Report on results.

Check if a centralized shared folder already has this software installed. If not, download this.

Use OpenBSD
Install OpenBSD

Use the official CDs, or burn a copy of a bootable CD. If networking might be a challenge (e.g. if using a virtual machine, or a very slow Internet connection), the install*.iso file may be easier to work with. Otherwise, the smaller cd*.iso may be sufficient.

If a downloaded image needs to be made for installation to a physical system, write the CD to a drive. (See: writing an image to a CD.)

The OpenBSD page has a section called “Installation guide(s)”

Adding a text editor

The package name for a popular text editor is called “nano”.

Use ”nano” as the package name when the directions ask to specify a pkgname, and follow these instructions for adding a software package:

If the official CDs are available
Accessing the CD's contents

If a CD from an actual official CD set is available, make sure you are root and then try running:

mkdir -p /media/cdmount
mount -t cd9660 /dev/cd0c /media/cdmount

If an *.iso image file was made from an official CD, then the process might be slightly more elaborate. (See using a CD image.)

As root, run:

pkg_add -ivv /media/cdmount/$(uname -r)/packages/$(uname -m | uname -p )/pkgname

(In the above line, customize the “pkgName” as necessary.)

Now, another text editor has been installed.

Downloading a program

Optional and recommended: Make sure that networking is functional. Run:

ping -c 5 ftp.$(uname).org

This may need to be something to do later (after networking becomes functional). However, as soon as Internet access becomes available, the following commands should work:

(The first two commands in the following example are not strictly necessary. However, they do save a copy of whatever is downloaded, which can speed things up in case there is ever a need to (re-)install the program in the future.)

export PKG_CACHE=/usr/local/pkgcache
mkdir -p $PKG_CACHE
sudo pkg_add -ivv ftp://ftp.$(uname).org/pub/$(uname)/$(uname -r)/packages/$(uname -m | uname -p )/pkgName

(In the above line, customize the “pkgName” as necessary.)

That example command line should work for immediate use to help install essential programs, such as a text editor that is more pleasant than what gets bundled with the operating system.

Eventually, the process that is recommended for more long term use is to follow the instructions at OpenBSD package easy which will then allow the command to be simpler, such as:

sudo pkg_add -ivv packageName
Create a non-default user, if that has not yet been done

This is likely doable during installation. Alternatively, add users

Disable root

Use the non-default user to get a “root” prompt. Details on how to do that are available at Running software as root.

Use the non-default user, with elevated permissions, to disable the account called “root”. (To see why, if curious and if there are no impending deadlines, Overview: Why the recommended approach is using a new account to disable the “superusers”. For details on how, see disabling user accounts.)

Enable remote access
See: Running OpenSSHd server
Make sure Internet access is working
ping -c 10 8.8.8.8
ping -c 10 google.com
Obtain an easy way to back up a file

This might not be a real thorough backup solution, if the backed up file is on the same hard drive as the original file. Still, such backups can be helpful to restore from changes, so at least making this type of backup is recommended before changing other files.

the cpytobak program is best to create rather automatically, using copy-and-paste or by transferring a file.

Make software installation easy
OpenBSD package easy. If at all possible, make the ~root/bin/pkgcmd file without needing to manually type all of the commands. (Copying and pasting from a remote system is highly recommended.)
Installing software from a trusted source

Use OpenBSD to install nano (if that hasn't already been done), and samba, aide, and icewm. To do this, see the following directions.

Later, a VNC server will need to be installed. (Perhaps ssvnc? or x2vnc or x11vnc?)

Streamlined guide
For OpenBSD
Initial setup

For OpenBSD, SSH in.

Make sure you have root access.

For the moment, until some additional details are more thoroughly tested, we're going to skip the step of backing up the files.

Under OpenBSD: Making things easy, find the section of code that starts with “sudo sudo -p

Run those commands.

Adding software

Know what software to install.

Become root. (See: Running software as root and run a command line shell. For instance, run “sudo $SHELL

Run: ~root/bin/pkgcmd

Run: “ pkg_add -ivv packagename ” (do not type quotation marks. There is an underscore in that command, and “packagename” needs to be customized.)

Details are at: ][CyberPillar][ : Software package management

Get graphics working in a free operating system
Getting graphics working

At the time of this writing, the way to do this is to use X Windows for this.

X Windows

X Windows should needs to be installed.

Try running:
startx

If that does not flip the screen to graphics mode, try to find out why.

Make environent usable

Make sure the mouse is working. If a wireless mouse is not working, try using a wired mouse, as simply making that change has often been sufficient to get things working.

Use IceWM:

Install IceWM

(See the above directions about installing nano, but use “icewm” as the package name)

Running IceWM

If IceWM gives any difficulty about another Window manager being used, try this work around: If desired, go ahead and quit X Windows. Run: “ which icewm ”. If that successfully located (and reported the location of) the icewm file, and if X Windows is still running, then quit X Windows. While X is still in a state of NOT being started, try running:

startx $( which icewm )
File Integrity Checking

Make a log, so that damage/intrusions/etc. can be checked. Details are at: file integrity checking

Transfering files securely

Make sure the OpenBSD machine can communicate with one of the machines using Microsoft Windows.

People who prefer to use a graphical interface may wish to use WinSCP. Use WinSCP to transfer files. If /etc/ssh/sshd_config has a line that enables SFTP (search for Subsystem), then SFTP may be available. If so, use SFTP. Otherwise, use SCP (which often has client-side support provided by the same collection of computer software). SCP might be a bit easier for compatability, but the section documenting SCP notes “This protocol has no bright development future” (Read the SCP section for details on why that statement was made.)

Set up shares in OpenBSD
Using Samba

Set up shares in OpenBSD, using Samba. (Note: Mounting with Sharity Light is more of a challenge.) Filesystems: CIFS/SMB

Discuss NFS security
Filesystems: NFS
Implementing network technologies with multiple platforms
Network infrastructure

If not yet already done, set up DHCP and DNS servers on both a Microsoft Windows Server operating system, and a freely downloadable operating system. Details may be at: DHCP servers. When setting up a second server, make sure to use a different, non-overlapping scope. (For instance, have the first DHCP servers hand out addresses that end with .150 through .174, and have the second server hand out addresses that end with numbers ranging from .175 to .199).

Implementing a web browser
Set up IIS, and either Apache/nginx. Info might be at: Internet Information Services (“IIS”), nginx (pronounced “Engine X”), Apache: Basic Setup Guide
Implementing tunneling

In OpenBSD: Tunnel traffic using some modern security. Generate keys. Tunnel traffic (via SSH port forwarding). On Windows, use TightVNC and PuTTY tunneling.

Bonus goals

Guides might not be fully available for this yet. This may require some experimentation.

Implement Remote Access on Microsoft Windows

This should actually be pretty quick and easy... RDC Security considerations, Remote Desktop. Then, once the server is set up, modern versions of Microsoft Windows tend to have a client called mstsc. See: Remote Access: “RDC client software” for alternatives.

Implement CGI to control a system

Make it so that when visiting a web page, the web page will reboot the server. First, have a command that securely provides a method to reboot the server. This may be done using authentication keys: Some details are at: ][CyberPillar][ : sshkey commands. Then, use CGI to run that command.

In a test environment, the next natural step to do is to make sure that command is only available to authorized users. In an actual production environment, proper security practices would dictate that such considerations need to be made before enabling the functionality.

Implement a backup solution

Have the Windows Server system back up data to the shares in OpenBSD.

Try out Bacula. (Perhaps see: Backup.) Report if it is any good.

If details are available on CyberPillar, they might be at: ][CyberPillar]['s backup page.

Mount a remote filesystem/folder on a freely-available operating system

If using OpenBSD, toy around with Sharity-Light. (See: Sharity-light.) If using another freely available operating system, consider using FUSE with smbfs. (Perhaps see: CIFS/SMB)

Install a web proxy

e.g. squid, or Microsoft Internet and Security Accelerator (if available)

Possible resource: Software installation.

Install, setup, and start administering a local patch server
WSUS may be bundled with Small Business Server?
Submit report

Make sure the documentation is up to speed.