-
Notifications
You must be signed in to change notification settings - Fork 91
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
OpenBSD node definition and build instructions. (#50)
* OpenBSD node definition and build instructions. * show pkg_add with cloud-init. Default to dhcp on em0. * Update 'Create the VM' section * Add link to binary
- Loading branch information
1 parent
edc671c
commit c6bfcb8
Showing
2 changed files
with
364 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,94 @@ | ||
id: OpenBSD | ||
general: | ||
description: OpenBSD Firewall / Router / Server / Host | ||
nature: firewall | ||
read_only: false | ||
device: | ||
interfaces: | ||
has_loopback_zero: true | ||
physical: | ||
- em0 | ||
- em1 | ||
- em2 | ||
- em3 | ||
- em4 | ||
- em5 | ||
- em6 | ||
- em7 | ||
serial_ports: 1 | ||
default_count: 2 | ||
loopback: | ||
- lo0 | ||
ui: | ||
visible: true | ||
label_prefix: oBSD- | ||
icon: firewall | ||
label: OpenBSD | ||
sim: | ||
linux_native: | ||
libvirt_domain_driver: kvm | ||
driver: server | ||
disk_driver: sata | ||
ram: 1024 | ||
cpus: 1 | ||
nic_driver: e1000 | ||
cpu_limit: 100 | ||
boot: | ||
timeout: 300 | ||
completed: | ||
- 'login:' | ||
uses_regex: false | ||
inherited: | ||
image: | ||
ram: true | ||
cpus: true | ||
data_volume: false | ||
boot_disk_size: false | ||
cpu_limit: true | ||
node: | ||
ram: true | ||
cpus: true | ||
data_volume: false | ||
boot_disk_size: false | ||
cpu_limit: true | ||
configuration: | ||
generator: | ||
driver: server | ||
provisioning: | ||
volume_name: cidata | ||
media_type: iso | ||
files: | ||
- name: meta-data | ||
editable: true | ||
content: |- | ||
instance-id: openbsd | ||
local-hostname: openbsd | ||
- name: user-data | ||
editable: true | ||
content: |- | ||
#cloud-config | ||
# Docs: https://cloudinit.readthedocs.io/en/latest/explanation/about-cloud-config.html | ||
hostname: openbsd76p1 | ||
write_files: | ||
- path: /etc/motd | ||
content: | | ||
########################################################## | ||
## A sample message of the day. ## | ||
########################################################## | ||
- name: network-config | ||
editable: true | ||
content: |- | ||
#cloud-config | ||
# Docs: https://cloudinit.readthedocs.io/en/latest/reference/network-config-format-v1.html | ||
network: | ||
version: 1 | ||
config: | ||
- type: physical | ||
name: em0 | ||
subnets: | ||
- type: dhcp | ||
- name: vendor-data | ||
editable: true | ||
schema_version: 0.0.1 |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,270 @@ | ||
# OpenBSD-CML | ||
|
||
Instructions for building an OpenBSD node in Cisco Modeling Lab | ||
|
||
## Why OpenBSD in CML? | ||
|
||
OpenBSD is standards-compliant, has good documentation, and is secure. | ||
|
||
OpenBSD can act as a router, a routed layer 3 firewall, a NAT boundary, a | ||
bridging Layer-3 firewall, an end host, a webserver, a load balancer, and many | ||
other roles not mentioned here. | ||
|
||
# Deployable image | ||
|
||
A pre-built OpenBSD CML image is available | ||
[here](https://cml-images.nerdops.io/). | ||
|
||
The instructions below were used to create the image. | ||
|
||
# Create a qcow2 OpenBSD VM | ||
|
||
## Create the VM | ||
|
||
Resources required for initially building the VM can differ from the resources | ||
required for running an instance of that VM in CML. | ||
|
||
As resources in CML are generally scarce I suggest starting with a fairly | ||
minimal configuration while building the VM. Although it's generally possible | ||
to increase the resources at runtime it's hard to decrease them. | ||
|
||
* RAM: 1GB | ||
* Disk: 8GB | ||
* CPU: 1 | ||
* Network: single interface with Internet access (used to install patches and | ||
upgrades) | ||
|
||
When running an instance of this VM in CML it is possible (and even likely) | ||
that you will add aditional network interfaces or increase the RAM or Disk | ||
space. RAM, Disk, and Network are all easily increased in your CML config. | ||
|
||
During the install process OpenBSD will either install a single-CPU kernel or a | ||
multi-CPU kernel. If you want to use a multi-CPU kernel you will need to | ||
create the VM with more than one CPU. It is possible to change the kernel | ||
after the fact but it's easier to just create the VM with more than one | ||
CPU. As this is a destined for a lab environment I suggest creating the VM | ||
with only one CPU. | ||
|
||
Although I used VMWare to build this image it should be mostly the same to use | ||
other platforms (VirtualBox, QEMU, KVM, etc). | ||
|
||
## Install OpenBSD | ||
|
||
I used the amd64 | ||
[install76.iso](https://cdn.openbsd.org/pub/OpenBSD/7.6/amd64/install76.iso) | ||
image to perform a base install. I did not install games nor any of the x11 | ||
packages (just to save space). | ||
|
||
I used ```cisco``` for the root password. I disabled root SSH logins out of | ||
habit. | ||
|
||
### Partitioning | ||
|
||
Although auto partitioning is sufficient for this, I created a single | ||
partition in order to both use the entire disk and to avoid the need to create | ||
a swap partition. | ||
|
||
### Users | ||
|
||
I created a second user named ```cisco``` with the same password. | ||
|
||
## First boot | ||
|
||
Once the base system is installed reboot and log in as root. | ||
|
||
Right away you should check for updates: | ||
|
||
syspatch | ||
pkg_add -u | ||
|
||
### Install additional packages | ||
|
||
This is an exellent opportunity to install some of the packages that are | ||
useful for network operations. Of course, it may be possible to install | ||
these packages later if your labs have Internet connectivity. | ||
|
||
If you intend to use ```cloud-init``` you will need to install git: | ||
|
||
pkg_add git | ||
|
||
#### Install now | ||
|
||
The benefit of installing packages now is that they will be available | ||
for use immediately on all instances of the node. The downsiide is that | ||
it will occupy more space on the image. | ||
|
||
These packages have been extremely useful through the years: | ||
|
||
pkg_add mtr-- wget gnuwatch nmap wireguard-tools | ||
|
||
Please note the ```--``` in ```mtr--```. If ```mtr``` is specified without | ||
the ```--``` the ```pkg_add``` command will ask the user which version is | ||
desired; normal MTR or MTR with GTK support. By using the ```--``` suffix the | ||
non-GTK version is installed. | ||
|
||
#### Install later | ||
|
||
If there is Internet connectivity for the instance at runtime it is also | ||
possible to install these packages later. This will save space on the image. | ||
|
||
To install at runtime, become root on the instance and run the following | ||
command: | ||
|
||
pkg_add mtr-- wget gnuwatch nmap wireguard-tools | ||
|
||
Alternatively, if you are using ```cloud-init``` you can include a | ||
```packages``` section in your ```user-data``` file. For example: | ||
|
||
```yaml | ||
#cloud-config | ||
packages: | ||
- mtr-- | ||
- wget | ||
- gnuwatch | ||
- nmap | ||
- wireguard-tools | ||
``` | ||
### Add username and password hints | ||
If some other admin tries to use your newly minted node it would be nice if | ||
they can easily see what username and password to use. This will appear on | ||
the serial console. | ||
Update the ```/etc/gettytab``` file. Replace the existing default section with | ||
this: | ||
|
||
default:\ | ||
:np:im=\r\n%s/%m (%h) (%t)\r\n\ | ||
************************\r\n\ | ||
* Console login *\r\n\ | ||
* username = root *\r\n\ | ||
* password = cisco *\r\n\ | ||
* *\r\n\ | ||
* General login (SSH) *\r\n\ | ||
* username = cisco *\r\n\ | ||
* password = cisco *\r\n\ | ||
************************\r\n\ | ||
\r\n:sp#1200: | ||
|
||
### Enable IP forwarding | ||
|
||
Enable IP forwarding. By default this is turned off. This isn't strictly | ||
required for an end host nor webserver; but it's a step easily missed. | ||
|
||
echo "net.inet.ip.forwarding=1" > /etc/sysctl.conf | ||
|
||
### cloud-init | ||
|
||
```cloud-init``` is a tool that allows you to configure a VM on first boot. | ||
This allows you to configure a VM without having to use the VM's console. | ||
|
||
#### Install cloud-init | ||
|
||
There is no pre-built ```cloud-init``` package for OpenBSD. However, it's not | ||
difficult to install it from source: | ||
|
||
git clone https://github.com/canonical/cloud-init.git | ||
cd cloud-init | ||
./tools/build-on-openbsd | ||
|
||
If it was successful you should see several ```cloud-init``` commands | ||
in ```/etc/rc.local```. These commands will be run on boot. | ||
|
||
#### Configure cloud-init | ||
|
||
By it's very nature ```cloud-init``` is typically used with a cloud provider | ||
with access to the Internet. As the intent here is to build a VM that will run | ||
inside a CML environment is is necessary to configure ```cloud-init``` to look | ||
for a local data source. | ||
|
||
Edit ```/etc/cloud/cloud.cfg``` and add the following: | ||
|
||
datasource_list: ["NoCloud"] | ||
datasource: | ||
NoCloud: | ||
fs_label: cidata | ||
|
||
The configuration above will look for a mounted CDROM with a label of | ||
```cidata``` during the boot process. The following files will be read (if | ||
present): | ||
|
||
* ```meta-data``` | ||
* ```user-data``` | ||
* ```network-config``` | ||
* ```vendor-data``` | ||
|
||
The files above are optional. Please note that they do not have a file | ||
extension (there is no ```.yml``` extension). | ||
|
||
#### Configure the boot process | ||
|
||
By default ```cloud-init``` will populate the ```/etc/rc.local``` file. The | ||
```ds-identify``` command will be run by default but is not required since | ||
the datasource is already configured. I recommend commenting out this line | ||
in order to speed up the boot process. | ||
|
||
### Enable logins on serial console | ||
|
||
Enable serial console to provide a login prompt | ||
Edit ```/etc/ttys``` so that ```tty00``` reads as: | ||
|
||
tty00 "/usr/libexec/getty std.9600" vt220 on secure | ||
|
||
This file uses a combination of tabs and spaces. It will work fine if you only | ||
use spaces. Copying and pasting from this README will work fine. | ||
|
||
NB: you can output to a serial console without being able to login on it. This | ||
step enables that login. | ||
|
||
## Snapshot | ||
|
||
Now is a good time to create a snapshot of your VM. This point in the install | ||
it's still fairly easy to install future patches and additional software. | ||
|
||
## Finalize the image | ||
|
||
These commands will enable output to the serial console needed for CML and | ||
cleanup the original network interface. It's hard to undo these (but not | ||
impossible). | ||
|
||
# remove the network interface config that was created by the installer: | ||
rm /etc/hostname.em0 | ||
# remove the SSH host keys that were generated during the boot: | ||
rm /etc/ssh/ssh_host_* | ||
# remove the configuration files that cloud-init created: | ||
rm -r /var/lib/cloud | ||
rm -r /var/run/cloud-init | ||
# redirect the default console to the serial console: | ||
echo "set tty com0" > /etc/boot.conf | ||
# shutdown and power off the VM: | ||
shutdown -p now | ||
|
||
## Create a clone of the VM | ||
|
||
This is the last step before exporting your image to a qcow2 file. | ||
|
||
If you attempt to convert the VMWare image to a qcow2 image from the | ||
snapshotted VMDKs above you will end up with a non-bootable image. I do not | ||
understand why. I suspect it is due to how qemu-img handles snapshots. For | ||
best success I recommend you clone your VM to get a flattened VMDK image. I | ||
had success with ```Clone to Template...``` in VMWare. | ||
|
||
## Convert VM to qcow2 | ||
|
||
This step is not required if you already have a qcow2 image. VMWare provides | ||
a series of VMDK files which need to be converted. | ||
|
||
Copy all of the VMDK files from your image to someplace where you can run the | ||
```qemu-img``` tool (available in Linux). | ||
|
||
qemu-img convert -f vmdk -O qcow2 <base filename.vmdk> <target qcow2 filename> | ||
|
||
If you receive an error you may be specifying the wrong base VMDK file. Look | ||
for the smallest VMDK file and use it. | ||
|
||
Now you can export your qcow2 image for use in CML. | ||
|
||
## OpenBSD node definition | ||
|
||
An OpenBSD [node definition](OpenBSD.yaml) is include in this directory. |