Boxen - put your network operating systems in a box!

Related tags

Cryptography boxen
Overview

boxen

Go Report License: MIT


boxen -- put your network operating systems in a box (or if you speak πŸ‡©πŸ‡ͺ , fight them! 🀣 )!

boxen is a cli tool written in Go that allows you to package your network operating systems neatly into little... boxes (container images) so they are easily portable, and, most importantly, so you can use them with the wonderful containerlab. boxen also provides some basic functionality for running network operating systems on your local machine (without containers) -- even on Darwin systems (for platforms that work with HVF/HAX or no acceleration).

Please note that this is a work in progress... especially the documentation!

Key Features:

  • Easy: It's easy to get going with boxen -- grab your network operating systems qcow2 disk and point boxen to it!
  • Native VMs: Containers are cool, but sometimes (especially for Darwin systems) it is nice to launch network operating system VMs without containers/GUIs/etc. -- boxen has you covered!
  • Containerlab: Love containerlab? Of course you do! We do too -- boxen was built to be used to package network operating systems up neatly for containerlab to orchestrate, it's a great match!

Supported Platform Types

  • Arista
    • vEOS (tested with 4.22.1F)
  • Cisco
    • CSR1000v (tested with 16.12.03)
    • N9Kv (tested with 9.2.4)
    • XRv9K (tested with 6.5.3)
  • Juniper
    • vSRX (tested with 17.3R2.10)
  • Palo Alto
    • PA-VM (tested with 10.0.6)

Additional platforms can of course be added!

Installation

The simplest way to install boxen is to use the installation script:

# download and install the latest release
bash -c "$(curl -sL https://raw.githubusercontent.com/carlmontanari/boxen/main/get.sh)"

# download a specific version - 0.0.1
bash -c "$(curl -sL https://raw.githubusercontent.com/carlmontanari/boxen/main/get.sh)" -- -v 0.0.1

# with wget
bash -c "$(wget -qO - https://raw.githubusercontent.com/carlmontanari/boxen/main/get.sh)"

Packaging For Containerlab

Packaging images for use with containerlab is easy! Snag the appropriate vmdk/qcow2 for your platform of choice, and of course boxen. With those two things done, all you need to do is to run boxen with the package command, and provide a disk to the --disk flag.

$ boxen package --disk ~/disks/nxosv.9.2.4.qcow2
      info   1640884754 package requested for disk 'nxosv.9.2.4.qcow2'
     debug   1640884754 temporary directory '/tmp/boxen2756986238' created successfully
     debug   1640884755 disks allocated for packaging
     debug   1640884755 packaging instance created
     debug   1640884756 bundling required packaging files complete
     debug   1640884756 pre packaging complete, begin docker-ization!
      info   1640884756 docker build output available at '/tmp/boxen2756986238/initial_build.log'
     debug   1640884995 base image building complete!
     debug   1640884995 package install starting
     debug   1640884995 begin instance install
      info   1640884995 install requested
      info   1640884995 qemu instance start requested
     debug   1640884995 launching instance with command: [-name cisco_n9kv -uuid 3c7fe9f9-61af-4c37-bf7b-338fd504f8ae -accel kvm -display none -machine pc -m 8192 -cpu max -smp cores=8,threads=1,sockets=1 -monitor tcp:0.0.0.0:4001,server,nowait -serial telnet:0.0.0.0:5001,server,nowait -drive if=none,file=disk.qcow2,format=qcow2,id=drive-sata-disk0 -device ahci,id=ahci0,bus=pci.0 -device ide-hd,drive=drive-sata-disk0,bus=ahci0.0,id=drive-sata-disk0,bootindex=1 -device pci-bridge,chassis_nr=1,id=pci.1 -device e1000,netdev=mgmt -netdev user,id=mgmt,net=10.0.0.0/24,tftp=/tftpboot,hostfwd=tcp::21022-10.0.0.15:22,hostfwd=tcp::21023-10.0.0.15:23,hostfwd=tcp::21443-10.0.0.15:443,hostfwd=tcp::21830-10.0.0.15:830,hostfwd=udp::31161-10.0.0.15:161 -device e1000,netdev=p001,bus=pci.1,addr=0x2,mac=52:54:00:54:6a:01 -netdev socket,id=p001,listen=:10001 -device e1000,netdev=p002,bus=pci.1,addr=0x3,mac=52:54:00:ee:56:02 -netdev socket,id=p002,listen=:10002 -device e1000,netdev=p003,bus=pci.1,addr=0x4,mac=52:54:00:4e:75:03 -netdev socket,id=p003,listen=:10003 -device e1000,netdev=p004,bus=pci.1,addr=0x5,mac=52:54:00:66:83:04 -netdev socket,id=p004,listen=:10004 -device e1000,netdev=p005,bus=pci.1,addr=0x6,mac=52:54:00:76:d0:05 -netdev socket,id=p005,listen=:10005 -device e1000,netdev=p006,bus=pci.1,addr=0x7,mac=52:54:00:66:25:06 -netdev socket,id=p006,listen=:10006 -device e1000,netdev=p007,bus=pci.1,addr=0x8,mac=52:54:00:6d:8b:07 -netdev socket,id=p007,listen=:10007 -device e1000,netdev=p008,bus=pci.1,addr=0x9,mac=52:54:00:34:99:08 -netdev socket,id=p008,listen=:10008 -bios ./OVMF.fd -boot c]
     debug   1640884995 stdout logger provided, setting execute argument
     debug   1640884995 stderr logger provided, setting execute argument
      info   1640885005 qemu instance start complete
     debug   1640885005 instance started, waiting for start ready state
      info   1640885015 install logs available at '/tmp/boxen2756986238/install_build.log', or by inspect container 'b54b335336c667df60dd04aaaec88b5adf9d455aa46a2f17638239228dbc8d93' logs
     debug   1640885199 start ready state acquired, handling initial config dialog
     debug   1640885211 initial config dialog addressed, logging in
     debug   1640885217 log in complete
     debug   1640885217 install config lines provided, executing scrapligo on open
     debug   1640885225 initial installation complete
      info   1640885225 save config requested
      info   1640885230 install complete, stopping instance
      info   1640885230 qemu instance stop requested
      info   1640885230 qemu instance stop complete
     debug   1640885240 instance installation complete!
      info   1640885280 final image build logs available at '/tmp/boxen2756986238/final_build.log'
     debug   1640885280 packaging complete!
	βœ… finished successfully in 527 seconds

This "package" command will copy the disk image to a temporary directory and write out a few Dockerfiles that will be used for the packaging process. The first dockerfile is the "build" image; this image gets the disk and any necessary files (OVMF.fd, config.iso, etc.) copied into it. Once the build image is created, a container is spawned from that image -- this "install container" is where the initial device prompts (POAP, ZTP, etc.) is dealt with, and a base configuration is deployed. Once the initial configuration is sorted, the configuration is saved, and the container is stopped.

With the initial "installation" done, the disk image is copied out of the stopped container. Finally, a final slimmer container is built, which includes copying in the freshly installed disk.

At that point, the final image will be tagged "boxen_vendor_platform" with a version of whatever the provided disk version was.

Packaging for local VM Use

The process for setting up local VMs is somewhat similar to the packaging setup. First things first is that boxen will need a nice little directory to store its config file as well as any source disks and of course instance disks. The init command initializes this boxen directory, which by default is ~/boxen, but you can provide whatever path you like to the --directory flag.

With boxen "initialized" you are set to "install" a disk as a local source disk. This is done with the appropriately named install flag.

boxen install --disk somedisk.qcow2

Note that by default boxen will look for its config file at ~/boxen/boxen.yaml -- if you initialized boxen with a different path, make sure you pass the config file path with the --config flag!

Just like the packaging process, boxen will automagically determine the vendor, platform and disk version from the provided image. The "installation" process is pretty similar to the packaging process, just without containers of course. The disk is copied to a temp directory and is launched via qemu. The initial configuration process is sorted out, and the configuration is saved. Once complete, the new "source" disk is copied to the "source" sub-directory in the boxen directory.

At this point the "source" disk is ready, but we have no instances to launch!

The boxen provision command allows for provisioning one or many of the same type of instance. If you just installed an Arista vEOS source disk you could provision two vEOS instances like:

boxen provision --vendor arista --platform veos --instances eos1,eos2

The "provisioning" process simply installs these instances into the boxen config file and allocates instance IDs, management interface nat ports, and data plane interface listen ports. You can view the config file to see all of these settings.

Once provisioned you can start or stop instances easily:

boxen start instance --instances eos1,eos2

boxen stop instance --instances eos2

Other Info

Sparsify Disks

Some platforms will support disk "sparsification" -- to enable this, run boxen with the BOXEN_SPARSIFY_DISK env var set to anything > 0.

Dev Mode

During installation/dev/testing and such it is very handy to not delete boxen's temp build directory, you can enable this behavior by setting the BOXEN_DEV_MODE env var to anything > 0.

Log Level

BOXEN_LOG_LEVEL env var can be set to "info", "debug" or "critical" (default info) to control log verbosity. Note that this environment variable is copied into any "packaged" containers -- so if you want to have debug level logging for your containerlab images, you should package the instance with this flag set!

Timeout Multiplier

BOXEN_TIMEOUT_MULTIPLIER does what it says on the tin -- mostly this just modifies how long to wait for console availability and for "read until" operations. This setting is also copied into any packaged containers (see log level note).

Quirks

  • vSRX will accept unencrypted passwords and do poor md5 encryption on them such that they can be sent to the device without needing interaction.
  • PanOS should very, very much be packaged with sparsify set! Without this the image is huge (>8gb), but with sparsify enabled it is a much more manageable (but still large) ~3gb.

VM Acceleration Notes

Typically, when launching Qemu virtual machines, KVM acceleration is enabled -- especially for network operating system VMs. This is all well and good, however KVM is not available on Darwin systems (obviously). But! HVF (hypervisor framework) and HAX are available on Darwin systems, and thankfully some NOS do seem to boot nicely with either HVF or HAX.

Boxen auto-selects the "best" acceleration option available for the environment the VM is being launched. For packaged instances this will always be KVM, and as such you must always run the container on a Linux system with KVM available. For local VMs, KVM is always the most preferred option, however each platform contains a simple slice of supported accelerations (in order of priority), and will be booted with the first available acceleration.

For Darwin users, it is highly recommend to install HAXM (see link above).

TODO

  • Output mgmt interface details when starting local VM instances
Issues
  • Issues Packaging vSRX

    Issues Packaging vSRX

    Hi @carlmontanari

    Thanks for posting this wonderful project. This is something we would love use for packaging a vSRX image into a docker container for some automated testing and validation.

    I am running into an issue when trying to package a vSRX image in qcow2 format. Is there something I am doing wrong that is causing the error below?

    boxen package --disk junos-media-vsrx-x86-64-vmdisk-20.3R3.8.qcow2 
          info   1641225460 package requested for disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.qcow2'
      critical   1641225460 failed gleaning source data from disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.qcow2'
      critical   1641225460 error allocating disks for packaging: inspectionError: failed gleaning source data from disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.qcow2'
            πŸ†˜ finished unsuccessfully in 0 seconds 
    inspectionError: failed gleaning source data from disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.qcow2'
    

    I also tried ova format, bu that did not work either.

    boxen package --disk junos-media-vsrx-x86-64-vmdisk-20.3R3.8.ide.ova
          info   1641226635 package requested for disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.ide.ova'
      critical   1641226635 failed gleaning source data from disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.ide.ova'
      critical   1641226635 error allocating disks for packaging: inspectionError: failed gleaning source data from disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.ide.ova'
            πŸ†˜ finished unsuccessfully in 0 seconds 
    inspectionError: failed gleaning source data from disk 'junos-media-vsrx-x86-64-vmdisk-20.3R3.8.ide.ova'
    
    opened by tagur87 13
  • Fail to build vSRX

    Fail to build vSRX

    Hey @carlmontanari

    Me again. :) Hope you don't mind more issues.

    Here's an error i'm getting when trying to build the docker images it seems.

          info   1641237602 package requested for disk 'media-vsrx-vmdisk-20.3R3.8.qcow2'
          info   1641237637 docker build output available at '/var/folders/db/h649qj4d0s1f5gqprxb2lx9c0000gn/T/boxen947006849/initial_build.log'
      critical   1641237769 error starting build container: exit status 1
      critical   1641237769 error building base image: exit status 1
            πŸ†˜ finished unsuccessfully in 167 seconds 
    

    I tailed out the initial_build.log during the build process, but this is all I get, seems to get stuck here.

    #10 [6/7] RUN bash -c "$(curl -sL https://raw.githubusercontent.com/carlmontanari/boxen/main/get.sh)" -- -v 0.0.0
    #10 sha256:5e256bc9ad51e8e203ec01aa0d4250ba1337b06a263889f6e7ee1553f34794ab
    #10 CACHED
    
    #11 [7/7] RUN curl http://172.19.233.117:6666/disk.qcow2 -o disk.qcow2
    #11 sha256:c58110c498c822f41300a951b2b9602bd964e1412a274fe1e95bee4f99a6e566
    #11 0.290   % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
    #11 0.297                                  Dload  Upload   Total   Spent    Left  Speed
      0     0    0     0    0     0      0      0 --:--:--  0:01:48 --:--:--     0^C
    

    Any advice where in the code to start looking? I know a little Go so, I'd be willing to help contribute, but might need some direction on where to look. :)

    opened by tagur87 8
  • Cannot package Nexus 9000v 10.2(2)F qcow2 file

    Cannot package Nexus 9000v 10.2(2)F qcow2 file

    On an Ubuntu 20.04 virtual machine (running on VirtualBox), I am unable to use boxen package to package the NX-OS 10.2(2)F Nexus 9000v qcow2 file.

    [email protected]:~/Downloads$ BOXEN_DEBUG_LEVEL=debug BOXEN_DEV_MODE=1 boxen package --disk ~/Downloads/nexus9300v64.10.2.2.F.qcow2
          info   1648075996 package requested for disk '/home/christopher/Downloads/nexus9300v64.10.2.2.F.qcow2'
      critical   1648075996 failed gleaning source data from disk '/home/christopher/Downloads/nexus9300v64.10.2.2.F.qcow2'
      critical   1648075996 error allocating disks for packaging: inspectionError: failed gleaning source data from disk '/home/christopher/Downloads/nexus9300v64.10.2.2.F.qcow2'
            πŸ†˜ finished unsuccessfully in 0 seconds
    inspectionError: failed gleaning source data from disk '/home/christopher/Downloads/nexus9300v64.10.2.2.F.qcow2'
    

    Digging through the code, I think this is due to the regular expression pattern here: https://github.com/carlmontanari/boxen/blob/6a3cf944e80d8ac1f9995ef75dd4a3a6f7998e82/boxen/platforms/util.go#L59

    This pattern doesn't match the filename nexus9300v64.10.2.2.F.qcow2. I think the following regular expression pattern should work:

    (?i)(?:(?:nexus9300v(?:64)?|nxosv)\.)(\d+\.\d+\.\d+)
    
    opened by ChristopherJHart 3
  • support for IPInfusion OcNOS

    support for IPInfusion OcNOS

    This PR adds support for IPInfusion OcNOS network operating system.

    Since this platform is a non core scrapligo platform, I have added a community driver for it - https://github.com/hellt/scrapligo-ocnos

    Currently, only boxen install works, packaging is not done.

    opened by hellt 3
  • Cannot package Nexus 9000v 9.2(4) and 9.3(9) qcow2 files -

    Cannot package Nexus 9000v 9.2(4) and 9.3(9) qcow2 files - "did not find bios file in dir '.'"

    On an Ubuntu 20.04 virtual machine (running on VirtualBox), I am unable to use boxen package to package NX-OS 9.2(4) and 9.3(9) Nexus 9000v qcow2 files.

    [email protected]:~$ BOXEN_DEV_MODE=1 BOXEN_LOG_LEVEL=debug boxen package --disk nxosv.9.2.4.qcow2
          info   1648072899 package requested for disk 'nxosv.9.2.4.qcow2'
         debug   1648072899 temporary directory '/tmp/boxen283121203' created successfully
         debug   1648072900 disks allocated for packaging
         debug   1648072900 packaging instance created
      critical   1648072900 error bundling required packaging files: inspectionError: did not find bios file in dir '.'
            πŸ†˜ finished unsuccessfully in 1 seconds
    inspectionError: did not find bios file in dir '.'
    
    [email protected]:~$ BOXEN_DEV_MODE=1 BOXEN_LOG_LEVEL=debug boxen package --disk nexus9300v.9.3.9.qcow2
          info   1648073065 package requested for disk 'nexus9300v.9.3.9.qcow2'
         debug   1648073065 temporary directory '/tmp/boxen327059690' created successfully
         debug   1648073067 disks allocated for packaging
         debug   1648073067 packaging instance created
      critical   1648073067 error bundling required packaging files: inspectionError: did not find bios file in dir '.'
            πŸ†˜ finished unsuccessfully in 2 seconds
    inspectionError: did not find bios file in dir '.'
    

    I have validated that the SHA512 checksum of these qcow2 files match what is available on Cisco's Software Download website.

    [email protected]:~$ sha512sum nxosv.9.2.4.qcow2
    369dac985ebd6ca12ff574f99072024762de8bdbfc8a81944460575b512321c77ac7d42a4d157191969dd8cf1a624fade040c657fbe021d71a5010e18d57f95f  nxosv.9.2.4.qcow2
    [email protected]:~$ sha512sum nexus9300v.9.3.9.qcow2
    c53fd6892d80ded389ec47ff474ec48ccabcf8bef6e9e013dcffbf534d12c20f62f6a1b07f6ed1cad953ab270ba183b396fa40d0d7e0300fb2110ea514d7cde2  nexus9300v.9.3.9.qcow2
    [email protected]:~$
    
    opened by ChristopherJHart 2
  • is `boxenGlobalFlags()` the correct name of a function?

    is `boxenGlobalFlags()` the correct name of a function?

    https://github.com/carlmontanari/boxen/blob/00e2c9b0ffe39bf74b47faeece907702b00030ff/boxen/cli/cli.go#L11

    it seems like this function specifically creates the config CLI flag structure. Should it rather be naned boxenConfigFlag?

    opened by hellt 2
  • added ttl-push make target

    added ttl-push make target

    this make target makes it possible to upload a locally built boxen binary to an anonymous ttl.sh container registry so that anyone on the internet can pull it

    this is rather useful when an author wants to share an unreleased version of boxen (for example to let users test fixes before a new release gets published)

    The workflow assumes that PR author runs make ttl-push the output presents an author with the following:

    ❯ make ttl-push 
    mkdir -p $(pwd)/bin
    go build -o $(pwd)/bin/boxen -ldflags="-s -w" main.go
    docker run --rm -v $(pwd)/bin:/workspace ghcr.io/oras-project/oras:v0.12.0 push ttl.sh/boxen-$(git rev-parse --short HEAD):1d ./boxen
    Uploading 08d9bddae28a boxen
    Pushed ttl.sh/boxen-16e3885:1d
    Digest: sha256:356e263bb588bb3adf7453a35d956f1c49b361c43d6524a90fdaaf9b614a7195
    download with: docker run --rm -v $(pwd):/workspace ghcr.io/oras-project/oras:v0.12.0 pull ttl.sh/boxen-16e3885:1d
    

    The last line can be shared with anyone to let them pull the binary (as an OCI artifact).

    When users run this command, they will receive a binary in their PWD, making it super easy to use

    opened by hellt 1
  • mkisofs in a container

    mkisofs in a container

    This PR makes boxen to use container image with mkisofs (based on https://github.com/hellt/dockerfiles/pkgs/container/cdrkit) if binary is not founds locally on the system

    fix #8

    opened by hellt 1
  • qemu-img executable not found

    qemu-img executable not found

    Trying to package a CSR image and running into the following error, any help is appreciated!

    [email protected]:~$ boxen package --disk ~/boxen/csr1000v-universalk9.17.03.02-serial.qcow2 
          info   1645663051 package requested for disk '/home/juliopdx/boxen/csr1000v-universalk9.17.03.02-serial.qcow2'
      critical   1645663051 error copying source disk image: exec: "qemu-img": executable file not found in $PATH
    
      critical   1645663051 error allocating disks for packaging: exec: "qemu-img": executable file not found in $PATH
            πŸ†˜ finished unsuccessfully in 0 seconds 
    exec: "qemu-img": executable file not found in $PATH
    [email protected]:~$ 
    
    opened by JulioPDX 1
  • support for qemu-img in a container

    support for qemu-img in a container

    this PR proposes to remove the lock on having various binaries used in image build process by using containerization.

    As I move along the code base, the first occurrence is the qemu-img that is used to copy the original disk provided by the user to a temp directory.

    The reason I used hellt/qemu-img as a container repo is that I failed to find a fresh version of qemu-img, hence I built it myself based on alpine in a straightforward way -- https://github.com/hellt/qemu-img-alpine

    opened by hellt 1
  • Ocnos v5 support

    Ocnos v5 support

    Hey @carlmontanari I am working on adding support for ocnos v5 that uses commit functionality. And because I would like the code to still work with older ocnos images, I added commit commands in ocnos platform without err check, so that older images won't break.

    One thing I would appreciate you to counsel me on. For whatever reason, ocnos image can't parse the startup config boxen initially saves during install phase (ocnos software issue), so I need to configure eth0 with 10.0.0.15 address once again once the image starts inside a container. What would be the best way to do that in your opinion?

    opened by hellt 1
  • Boxen-packaged CSR1000v image does not load configuration when started in containerlab, scrapligo error during build

    Boxen-packaged CSR1000v image does not load configuration when started in containerlab, scrapligo error during build

    When attempting to package a CSR1000v image (IOS-XE 16.12.03) using Boxen, some scrapligo channel operation timed out errors appear in the logs. However, the boxen package command doesn't handle this exception and indicates the packaging was completed successfully.

    [email protected]:~$ sudo boxen --version
            version: 0.0.1
            source: https://github.com/carlmontanari/boxen
    
    [email protected]:~$ BOXEN_LOG_LEVEL=debug BOXEN_DEV_MODE=1 boxen package --disk csr1000v-universalk9.16.12.03-serial.qcow2
          info   1653239207 package requested for disk 'csr1000v-universalk9.16.12.03-serial.qcow2'
         debug   1653239207 temporary directory '/tmp/boxen671819217' created successfully
         debug   1653239208 disks allocated for packaging
         debug   1653239208 packaging instance created
         debug   1653239208 bundling required packaging files complete
          info   1653239208 boxen dev mode enabled, not deleting temporary directory after installation
         debug   1653239208 pre packaging complete, begin docker-ization!
          info   1653239208 docker build output available at '/tmp/boxen671819217/initial_build.log'
         debug   1653239253 base image building complete!
         debug   1653239253 package install starting
         debug   1653239253 begin instance install
          info   1653239253 install requested
          info   1653239253 qemu instance start requested
         debug   1653239253 launching instance with command: [-name cisco_csr1000v -uuid 46b39591-73ee-4a02-b3df-693f22a3f6f1 -accel kvm -display none -machine pc -m 4096 -monitor tcp:0.0.0.0:4001,server,nowait -serial telnet:0.0.0.0:5001,server,nowait -drive if=ide,file=disk.qcow2,format=qcow2 -device pci-bridge,chassis_nr=1,id=pci.1 -device virtio-net-pci,netdev=mgmt -netdev user,id=mgmt,net=10.0.0.0/24,tftp=/tftpboot,hostfwd=tcp::21022-10.0.0.15:22,hostfwd=tcp::21023-10.0.0.15:23,hostfwd=tcp::21443-10.0.0.15:443,hostfwd=tcp::21830-10.0.0.15:830,hostfwd=udp::31161-10.0.0.15:161 -device virtio-net-pci,netdev=p001,bus=pci.1,addr=0x2,mac=52:54:00:11:f8:01 -netdev socket,id=p001,listen=:10001 -device virtio-net-pci,netdev=p002,bus=pci.1,addr=0x3,mac=52:54:00:6d:ba:02 -netdev socket,id=p002,listen=:10002 -device virtio-net-pci,netdev=p003,bus=pci.1,addr=0x4,mac=52:54:00:e5:9c:03 -netdev socket,id=p003,listen=:10003 -device virtio-net-pci,netdev=p004,bus=pci.1,addr=0x5,mac=52:54:00:b8:90:04 -netdev socket,id=p004,listen=:10004 -device virtio-net-pci,netdev=p005,bus=pci.1,addr=0x6,mac=52:54:00:11:77:05 -netdev socket,id=p005,listen=:10005 -device virtio-net-pci,netdev=p006,bus=pci.1,addr=0x7,mac=52:54:00:93:a5:06 -netdev socket,id=p006,listen=:10006 -device virtio-net-pci,netdev=p007,bus=pci.1,addr=0x8,mac=52:54:00:90:59:07 -netdev socket,id=p007,listen=:10007 -device virtio-net-pci,netdev=p008,bus=pci.1,addr=0x9,mac=52:54:00:66:d3:08 -netdev socket,id=p008,listen=:10008 -device virtio-net-pci,netdev=p009,bus=pci.1,addr=0xa,mac=52:54:00:29:a2:09 -netdev socket,id=p009,listen=:10009 -cdrom ./config.iso]
         debug   1653239253 stdout logger provided, setting execute argument
         debug   1653239253 stderr logger provided, setting execute argument
          info   1653239263 qemu instance start complete
         debug   1653239263 instance started, waiting for start ready state
          info   1653239273 install logs available at '/tmp/boxen671819217/install_build.log', or by inspect container '39b8358ebe371c59d61fdee8752f03b86d766ce74ccfda225a7ffdbb76a1c095' logs
         debug   1653239414 start ready state acquired, logging in
         debug   1653239434 log in complete
         debug   1653239434 install config lines provided, executing scrapligo on open
      critical   1653239494 error running scrapligo on open: channel operation timed out
      critical   1653239494 package installation failed: channel operation timed out
         debug   1653239497 instance installation complete!
          info   1653239506 final image build logs available at '/tmp/boxen671819217/final_build.log'
         debug   1653239506 packaging complete!
            βœ… finished successfully in 298 seconds
    

    The relevant initial/install build logs from this session are attached to this issue for review:

    iosxe_config.txt final_build.log install_build.log initial_build.log

    I know @carlmontanari asked me to grab console logs (presumably named console.log) from the build container, but I'm not 100% positive where this file is located. I don't see it in /, /tmp/, or /var/log/.

    [email protected]:/# ls -lash
    total 942M
    4.0K drwxr-xr-x   1 root root 4.0K May 22 17:24 .
    4.0K drwxr-xr-x   1 root root 4.0K May 22 17:24 ..
       0 -rwxr-xr-x   1 root root    0 May 22 17:24 .dockerenv
       0 lrwxrwxrwx   1 root root    7 Apr 15 17:54 bin -> usr/bin
    4.0K drwxr-xr-x   1 root root 4.0K May 22 17:24 boot
    4.0K -rw-rw-r--   1 root root  783 May 22 17:24 boxen.yaml
    352K -rw-r--r--   1 root root 350K May 22 17:24 config.iso
       0 drwxr-xr-x  15 root root 3.9K May 22 17:24 dev
    942M -rw-r--r--   1 root root 942M May 22 17:27 disk.qcow2
    4.0K drwxr-xr-x   1 root root 4.0K May 22 17:24 etc
    4.0K drwxr-xr-x   2 root root 4.0K Apr 15  2020 home
       0 lrwxrwxrwx   1 root root    7 Apr 15 17:54 lib -> usr/lib
       0 lrwxrwxrwx   1 root root    9 Apr 15 17:54 lib32 -> usr/lib32
       0 lrwxrwxrwx   1 root root    9 Apr 15 17:54 lib64 -> usr/lib64
       0 lrwxrwxrwx   1 root root   10 Apr 15 17:54 libx32 -> usr/libx32
    4.0K drwxr-xr-x   2 root root 4.0K Apr 15 17:54 media
    4.0K drwxr-xr-x   2 root root 4.0K Apr 15 17:54 mnt
    4.0K drwxr-xr-x   2 root root 4.0K Apr 15 17:54 opt
       0 dr-xr-xr-x 273 root root    0 May 22 17:24 proc
    4.0K drwx------   2 root root 4.0K Apr 15 17:56 root
    4.0K drwxr-xr-x   1 root root 4.0K May 22 17:24 run
       0 lrwxrwxrwx   1 root root    8 Apr 15 17:54 sbin -> usr/sbin
    4.0K drwxr-xr-x   2 root root 4.0K Apr 15 17:54 srv
       0 dr-xr-xr-x  13 root root    0 May 22 17:24 sys
    4.0K drwxrwxrwt   1 root root 4.0K May 22 17:24 tmp
    4.0K drwxr-xr-x   1 root root 4.0K Apr 15 17:54 usr
    4.0K drwxr-xr-x   1 root root 4.0K Apr 15 17:56 var
    [email protected]:/# ls -lash /tmp/
    total 8.0K
    4.0K drwxrwxrwt 1 root root 4.0K May 22 17:24 .
    4.0K drwxr-xr-x 1 root root 4.0K May 22 17:24 ..
    [email protected]:/# ls -lash /var/log/
    total 412K
    4.0K drwxr-xr-x 1 root root            4.0K May 22 17:24 .
    4.0K drwxr-xr-x 1 root root            4.0K Apr 15 17:56 ..
    8.0K -rw-r--r-- 1 root root            7.8K May 22 17:24 alternatives.log
    4.0K drwxr-xr-x 1 root root            4.0K May 22 17:24 apt
     60K -rw-r--r-- 1 root root             58K Apr 15 17:54 bootstrap.log
       0 -rw-rw---- 1 root utmp               0 Apr 15 17:54 btmp
    288K -rw-r--r-- 1 root root            288K May 22 17:24 dpkg.log
    4.0K -rw-r--r-- 1 root root            3.3K May 22 17:24 faillog
    4.0K drwxr-sr-x 2 root systemd-journal 4.0K May 22 17:24 journal
     32K -rw-rw-r-- 1 root utmp             30K May 22 17:24 lastlog
    4.0K drwx------ 2 root root            4.0K May 22 17:24 private
       0 -rw-rw-r-- 1 root utmp               0 Apr 15 17:54 wtmp
    
    opened by ChristopherJHart 1
  • enhancement: allow to set a custom managment interface IP as provided by containerlab

    enhancement: allow to set a custom managment interface IP as provided by containerlab

    currently a hardcoded management interface is used both in both boxen and vrnetlab (10.0.0.15). using a hardcoded interface prevent some external management systems to discover the nodes, as the "real" management address is seen as the one assigned by docker to a container, but when the node call-back home it reports its management addr to be 10.0.0.15 and not the one that was used during the discovery.

    A proposal is for containerlab to add an argument with the allocated IP address and boxen to take this address and configure it for the management interface (as well as the hostfd qemu rules)

    opened by hellt 5
  • Local installation doesn't stop install images

    Local installation doesn't stop install images

    Quick check looks like just need to call a stop over here https://github.com/carlmontanari/boxen/blob/main/boxen/boxen/install.go#L303

    Didn't look too closely yet so could be wrong just opening to remind me :)

    opened by carlmontanari 0
Releases(v0.0.1)
Owner
Carl Montanari
Carl Montanari
Get any cryptocurrencies ticker and trade data in real time from multiple exchanges and then save it in multiple storage systems.

Cryptogalaxy is an app which will get any cryptocurrencies ticker and trade data in real time from multiple exchanges and then saves it in multiple storage systems.

Pavan Shetty 97 Jun 6, 2022
Split and distribute your private keys securely amongst untrusted network

cocert An experimental tool for splitting and distributing your private keys safely* cocert, generates ECDSA - P521 key and uses a technique known as

Furkan TΓΌrkal 187 Apr 16, 2022
Yet another Binance Smart Chain client based on TrustFi Network

TrustFi Smart Chain The goal of TrustFi Smart Chain is to bring programmability and interoperability to Binance Chain. In order to embrace the existin

TrustFi Network 19 Mar 27, 2021
Community-run technology powering the cryptocurrency, and decentralized applications on TrustFi Network

Go TrustFi-Ethereum Official Golang implementation of the TrustFi-Ethereum protocol. Automated builds are available for stable releases and the unstab

TrustFi Network 786 May 26, 2021
LEO (Low Ethereum Orbit) is an Ethereum Portal Network client.

LEO LEO (Low Ethereum Orbit) is an Ethereum Portal Network client. What makes LEO different from other Portal Network clients is that it uses libp2p f

Valist, Inc. 10 Apr 19, 2022
An implementation of the Filecoin Distributed Storage Network

Project Lotus - 莲 Lotus is an implementation of the Filecoin Distributed Storage Network. For more details about Filecoin, check out the Filecoin Spec

null 0 Oct 27, 2021
Uniform interface for interacting with network hardware via telnet/ssh

jgivc/console This package provides a uniform interface for interacting with network hardware via telnet/ssh This package uses part of reiver/go-telne

null 0 Dec 9, 2021
Avalanche: a network composed of multiple blockchains

Coreth and the C-Chain Avalanche is a network composed of multiple blockchains.

Ava Labs 110 Jun 18, 2022
Practicing network programming using Go. These are some fundamental APIs

Go Networking This repository is a collection of Network Programming APIs or sim

Srijan Srivastava 1 Apr 29, 2022
XDC.Network Rosetta API Implementation

Rosetta XDC.Network ROSETTA XDC.Network IS CONSIDERED ALPHA SOFTWARE. USE AT YOUR OWN RISK! COINBASE ASSUMES NO RESPONSIBILITY OR LIABILITY IF THERE I

null 2 Dec 30, 2021
Ethereum Consortium Network Deployments Made Easy

Ethereum Consortium Network Deployments Made Easy Overview The next phase of our support of blockchain on Microsoft Azure is the release of the Ethere

Microsoft Partner Catalyst Team 3 Dec 20, 2020
Btcix - Golang implementation for BTCIX Network

BTCIX Mainnet client Golang implementation for BTCIX Network Mainnet information

BITCOLOJIX 0 May 4, 2022
Minlib - Multi-Identifier Network Development Library

minlib 1. Install git clone https://gitea.qjm253.cn/PKUSZ-future-network-lab/min

null 9 Jan 7, 2022
FabricPing: Network tools for service fabric

FabricPing Network debugging tools for Service Fabric Install Windows powershell

Boshi Lian 6 Jun 27, 2022
This is a close to decentralized RSS3 Network implementation of RSS3 protocol v0.4.0 with full indexing function in Go

This is a close to decentralized RSS3 Network implementation of RSS3 protocol v0.4.0 with full indexing function in Go

Natural Selection Labs 40 Jun 25, 2022
Packaging and encrypting/decrypting your files for Golang

?? Paket – A vault to packaging and encrypt/decrypt your files in golang! pkg.go.dev | Table of Contents ?? Informations ??‍?? ??‍?? What does it do ?

null 19 Nov 15, 2021
CLI Tool to remove unwanted connections from your Chia Node based on Geo IP Location.

chia-bouncer Tiny CLI tool to remove unwanted connections from your Chia Node based on the Geo IP Location (Country). The Tool is written in golang an

st3ffn 4 Jun 25, 2021
Build apps that run everywhere with Go and a browser engine of your choice (Chrome, Firefox, Epiphany or Android WebView).

hydrapp Build apps that run everywhere with Go and a browser engine of your choice (Chrome, Firefox, Epiphany or Android WebView). Overview ?? This pr

Felix Pojtinger 7 Apr 10, 2022