Packer, Vagrant/VirtualBox, autoinstall(8), ...

double-p

double-p

BOFH
Ich habe Stimmen gehoert ;-)

"vbox ist immer so ein Gefummel mit dem Netzwerk"
"vagrant braucht man erst eine 'box' von sonstwelchen quellen - und die sind veraltet"
"packer... wat? viel zu kompliziert!"
"autoinstall(8) testen saugt!"

Da sich die Installation der Basiskomponenten je nach OS unterscheidet, ueberlass ich
das mal jedem einzeln; es braucht (bei mir ist die "Basis" OSX; es gibt alles fertig in brew/cask)

Natuerlich auch ein OpenBSD ISO :-) Es gibt noch mehr Wege, aber nehmen wir mal das "grosse" install58.iso

Die fuer vagrant notwendige "box" erstellt man mit packer; erstmal die packer config: "OpenBSD-installme.json"
Code: 
{
  "provisioners": [
  ],
  "builders": [
    {
      "type": "virtualbox-iso",
      "name": "vbox-obsd-58-amd64",
      "boot_command": [
        "A<enter>"
      ],
      "boot_wait": "15s",
      "disk_size": 5120,
      "guest_os_type": "OpenBSD_64",
      "iso_url": "file:///Users/pbuehler/Software/ISOs/install58.iso",
      "iso_checksum": "90d1c29ea5c2d6db1a37ac84b02da57c085aee3c1e285eb64831d82ace20c4ee",
      "iso_checksum_type": "sha256",
      "ssh_username": "root",
      "ssh_password": "vagrant",
      "ssh_wait_timeout": "10m",
      "shutdown_command": "echo '/sbin/halt -p' > shutdown.sh; sh 'shutdown.sh'",
      "guest_additions_path": "disable",
      "virtualbox_version_file": ".vbox_version",
      "vboxmanage": [
        [ "modifyvm", "{{.Name}}", "--memory", "64" ],
        [ "modifyvm", "{{.Name}}", "--cpus", "1" ],
        [ "modifyvm", "{{.Name}}", "--nattftpfile1", "auto_install" ],
        [ "modifyvm", "{{.Name}}", "--nattftpserver1", "192.168.2.101" ]
      ]
    }
  ],
  "post-processors": ["vagrant"]
}
Key things:
type: baue in virtualbox mit einem ISO als boot-medium
boot_command: der installer geht bei nicht-PXE nicht von einem (A)utoinstall aus; also gibt es ein A<enter>
ssh_password: muss zu dem SHA in der (s.u.) install.conf passen
--nattftpfile1: das triggered im installer, dass er sich vom nattftpserver eine /install.conf holt
--nattftpserver1: IP-Adresse vom vbox-host, es ging aber auch alles andere, das von der VM aus erreichbar ist

die install.conf fuer autoinstall(8):
Code: 
keyboard layout = us
System hostname = obsd58-box
Password for root = $2b$10$1R9GYeS7SQ5ExpVUWkl0DOWvF11VHP6XlWz47cGLEEU9gKpoH7oN.
Allow root ssh = yes
ntpd = yes
X Window System = no
com0 = no
root disk = wd0
Use (W)hole disk = W
Location of sets = cd
Set = +*
Unverified = yes
SHA256.sig. = yes
timezone = Europe/Berlin
Als Webserver setze ich in dem Directory mit der install.conf:
Code: 
ruby -run -e httpd . -p 80

Dann baddabum-build:
Code: 
packer build OpenBSD-installme.json

Das bootet die install58.iso; triggered den autoinstall, den Rest macht dieser anhand der install.conf.
Ergebnis ist ein packer_vbox-obsd-58-amd64_virtualbox.box Image.

Vagrant weiss noch nichts davon:
Code: 
vagrant box add --name "obsd58" packer_vbox-obsd-58-amd64_virtualbox.box

Eine simple VM bekommt man mit einem Vagrantfile:
Code: 
Vagrant.configure("2") do |config|
  config.vm.guest = :openbsd
  config.ssh.shell = "ksh -l"
  config.ssh.username = "root"
  config.ssh.password = "vagrant"
  config.vm.box = "obsd58"
  config.vm.synced_folder ".", "/vagrant", disabled: true
  config.vm.provider :virtualbox do |v|
  v.customize ["modifyvm", :id, "--memory", 128]
  v.gui = true;
  end
end

Fuer das 317. IPsec debug-fest eignet sich dieses Vagrantfile (allerdings noch mit 5.7; der Kurzausflug
beinhaltet noch nicht die sudo->doas "migration").
Code: 
Vagrant.configure("2") do |config|
  config.vm.guest = :openbsd
  config.ssh.shell = "ksh -l"
  config.vm.box = "obsd57"

  config.vm.define "ipsec-client-left" do |v|
  v.vm.network :private_network, ip: "192.168.50.5"
  v.vm.hostname = "ipsec-client-left"
  end
  config.vm.define "ipsec-gw-left", primary: true do |v|
  v.vm.network :private_network, ip: "192.168.50.254"
  v.vm.network :private_network, ip: "10.0.123.254"
  v.vm.hostname = "ipsec-gw-left"
  end
# "internet"
  config.vm.define "ipsec-gw-right" do |v|
  v.vm.network :private_network, ip: "10.0.123.253"
  v.vm.network :private_network, ip: "172.24.50.254"
  v.vm.hostname = "ipsec-gw-right"
  end
  config.vm.define "ipsec-client-right" do |v|
  v.vm.network :private_network, ip: "172.24.50.5"
  v.vm.hostname = "ipsec-client-right"
  end
end
Hier sieht der client-left nur gw-left; client-right nur gw-right und die gw gegenseitig -- bis man einen passenden Tunnel etabliert hat.

HTH! :-)
 
Ich boote hier die Build-VM mit dem passenden OS (PXE-Boot vom passenden ZFS-Dataset) und baue zu Fuß ein komplett bootbares Image, optional mit FDE, einfach durch auspacken der Release-tgzs und drüberbügeln der entsprechenden Config für den Host (handgefrickelt, Shell).

Das Image kann ich dann auf ne CF schreiben oder direkt auf dem vServer auf die Platte malen.

Alles obskur da oben. :)
 
Es geht ja eben nicht um "zu Fuss" - ich ziehe ein neues Snapshot ISO und habe:
--> vbox-obsd-58-amd64: 'virtualbox' provider box: packer_vbox-obsd-58-amd64_virtualbox.box
real 2m36.633s
Nach insgesamt 5 Minuten ist dann mein IPsec-Testbed auf einem aktuellen Stand und hochgefahren.
Das ist nicht obskur, sondern effizient ;-)

Ausserdem kann ich so 1:1 auch meine autoinstall/provisionings fuer das RZ testen. Kein CF, kein vServer.

Ergaenzung fuer die aktuellen snapshots, die kein sudo(8) mehr haben, vagrant das aber derzeit noch braucht:
OpenBSD-installme.json
Code: 
  "provisioners": [
  {
  "type": "shell",
  "environment_vars": [
  "PKG_PATH=http://artfiles.org/openbsd/snapshots/packages/amd64/"
  ],
  "inline": "pkg_add -Iz sudo-1.8"
  }
  ],
 
"Zu Fuß" = "ohne OpenBSD-Installer/-ISO", nur tar pxf base57.tgz etc.; macht natürlich letztendlich alles das Script. Die gleiche VM baut mit nem anderen Script auch regelmäßig neue Releases und Packages, dank ZFS snapshot+rollback immer schön vom sauberen Ausgangszustand aus.

Wollte sagen: diese hippen Setup-Tools sind mir alle suspekt. Wenn ich das OS kenne, dann mal ich mir lieber schnell ein Script zusammen, dann weiß ich wenigstens, was das macht und zieh mir nicht den neuesten Hipster-Kram auf die Kiste. Alles nur unnötig abstrahiert IMHO.
 
Seh ich das richtig, dass der die VM startet und dann Tastendrücke in die VM schickt? Also so echte Tasten mit der emulierten Tastatur? Und wenn nach 15s nicht der installer auf das A reagiert, passiert ggf. gar nichts? Was kann da schon schiefgehen mit fixen Timings. :)

Nee lass mal, Schnickschnack. *didum*
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben