Netbox-Sync

Imagine this, you are managing your infrastructure for your lab or server farm using the popular NetBox tool. Everytime you install a new machine you connect to it and collect all the system's information to enter into NetBox. Including stuff like system resources, architecture, vendor, type and all the network interfaces. Tedious isn't it?

Well, this is where NetBox-Sync comes in (name subject to change). NetBox-Sync is going to be a CLI application, written in Rust, that will automatically collect your machine's details and send them to your NetBox instance. This will make it easier for you to install and update your inventory.

If you want to learn Rust and help me build this project please reach out to me through the public channels linked in my GitHub Profile, your help is greatly appreciated!

Goal for this Hackweek

There are multiple goals for this Hackweek. Split into the main focus and nice-to-have goals.

Main Focus

  • [x] Get a working API client for Netbox-Sync so it can communicate with a Netbox instance
  • [ ] Implement functions to create machines/VMs and get a list of existing ones.
  • [ ] Implement a "publisher" module to "steer" API calls.

Acceptance criteria for this goal

  • [x] NetBox-Sync is correctly addressing the right NetBox URI from config file or CLI according to set hierarchy.
  • [ ] The payload data is in the correct format

Nice-To-Have

  • [x] Error Handling PR is done and documented correctly.

Resources

NetBox-Sync Repository: https://github.com/ByteOtter/netbox-sync

API-Client PR: https://github.com/ByteOtter/netbox-sync/pull/36

Netbox Documentation: https://docs.netbox.dev/en/stable/

Who I need

People with some Rust knowledge and familiarity with OpenAPI stuff would be a huge help I think. But anyone is welcome! :)

Looking for hackers with the skills:

rust netbox cli systemsmanagement

This project is part of:

Hack Week 23

Activity

  • about 2 years ago: smflood liked this project.
  • about 2 years ago: renxt0310 liked this project.
  • about 2 years ago: jzerebecki liked this project.
  • about 2 years ago: digitaltomm liked this project.
  • about 2 years ago: chock added keyword "systemsmanagement" to this project.
  • about 2 years ago: chock joined this project.
  • about 2 years ago: mfriedrich started this project.
  • about 2 years ago: c-hagenest liked this project.
  • about 2 years ago: chock added keyword "rust" to this project.
  • about 2 years ago: chock removed keyword systemsmanagement from this project.
  • about 2 years ago: chock added keyword "rust" to this project.
  • about 2 years ago: chock added keyword "netbox" to this project.
  • about 2 years ago: chock added keyword "cli" to this project.
  • about 2 years ago: chock added keyword "systemsmanagement" to this project.
  • about 2 years ago: chock originated this project.

  • Comments

    Be the first to comment!

    Similar Projects

    Arcticwolf - A rust based user space NFS server by vcheng

    Description

    Rust has similar performance to C. Also, have a better async IO module and high integration with io_uring. This project aims to develop a user-space NFS server based on Rust.

    Goals

    • Get an understanding of how cargo works
    • Get an understanding of how XDR was generated with xdrgen
    • Create the RUST-based NFS server that supports basic operations like mount/readdir/read/write

    Result (2025 Hackweek)

    • In progress PR: https://github.com/Vicente-Cheng/arcticwolf/pull/1

    Resources

    https://github.com/Vicente-Cheng/arcticwolf


    Mail client with mailing list workflow support in Rust by acervesato

    Description

    To create a mail user interface using Rust programming language, supporting mailing list patches workflow. I know, aerc is already there, but I would like to create something simpler, without integrated protocols. Just a plain user interface that is using some crates to read and create emails which are fetched and sent via external tools.

    I already know Rust, but not the async support, which is needed in this case in order to handle events inside the mail folder and to send notifications.

    Goals

    • simple user interface in the style of aerc, with some vim keybindings for motions and search
    • automatic run of external tools (like mbsync) for checking emails
    • automatic run commands for notifications
    • apply patch set from ML
    • tree-sitter support with styles

    Resources

    • ratatui: user interface (https://ratatui.rs/)
    • notify: folder watcher (https://docs.rs/notify/latest/notify/)
    • mail-parser: parser for emails (https://crates.io/crates/mail-parser)
    • mail-builder: create emails in proper format (https://docs.rs/mail-builder/latest/mail_builder/)
    • gitpatch: ML support (https://crates.io/crates/gitpatch)
    • tree-sitter-rust: support for mail format (https://crates.io/crates/tree-sitter)


    OpenPlatform Self-Service Portal by tmuntan1

    Description

    In SUSE IT, we developed an internal developer platform for our engineers using SUSE technologies such as RKE2, SUSE Virtualization, and Rancher. While it works well for our existing users, the onboarding process could be better.

    To improve our customer experience, I would like to build a self-service portal to make it easy for people to accomplish common actions. To get started, I would have the portal create Jira SD tickets for our customers to have better information in our tickets, but eventually I want to add automation to reduce our workload.

    Goals

    • Build a frontend website (Angular) that helps customers create Jira SD tickets.
    • Build a backend (Rust with Axum) for the backend, which would do all the hard work for the frontend.

    Resources (SUSE VPN only)

    • development site: https://ui-dev.openplatform.suse.com/login?returnUrl=%2Fopenplatform%2Fforms
    • https://gitlab.suse.de/itpe/core/open-platform/op-portal/backend
    • https://gitlab.suse.de/itpe/core/open-platform/op-portal/frontend


    Exploring Rust's potential: from basics to security by sferracci

    Description

    This project aims to conduct a focused investigation and practical application of the Rust programming language, with a specific emphasis on its security model. A key component will be identifying and understanding the most common vulnerabilities that can be found in Rust code.

    Goals

    Achieve a beginner/intermediate level of proficiency in writing Rust code. This will be measured by trying to solve LeetCode problems focusing on common data structures and algorithms. Study Rust vulnerabilities and learning best practices to avoid them.

    Resources

    Rust book: https://doc.rust-lang.org/book/


    Learn a bit of embedded programming with Rust in a micro:bit v2 by aplanas

    Description

    micro:bit is a small single board computer with a ARM Cortex-M4 with the FPU extension, with a very constrain amount of memory and a bunch of sensors and leds.

    The board is very well documented, with schematics and code for all the features available, so is an excellent platform for learning embedded programming.

    Rust is a system programming language that can generate ARM code, and has crates (libraries) to access the micro:bit hardware. There is plenty documentation about how to make small programs that will run in the micro:bit.

    Goals

    Start learning about embedded programming in Rust, and maybe make some code to the small KS4036F Robot car from keyestudio.

    Resources

    Diary

    Day 1

    • Start reading https://mb2.implrust.com/abstraction-layers.html
    • Prepare the dev environment (cross compiler, probe-rs)
    • Flash first code in the board (blinky led)
    • Checking differences between BSP and HAL
    • Compile and install a more complex example, with stack protection
    • Reading about the simplicity of xtask, as alias for workspace execution
    • Reading the CPP code of the official micro:bit libraries. They have a font!

    Day 2

    • There are multiple BSP for the microbit. One is using async code for non-blocking operations
    • Download and study a bit the API for microbit-v2, the nRF official crate
    • Take a look of the KS4036F programming, seems that the communication is multiplexed via I2C
    • The motor speed can be selected via PWM (pulse with modulation): power it longer (high frequency), and it will increase the speed
    • Scrolling some text
    • Debug by printing! defmt is a crate that can be used with probe-rs to emit logs
    • Start reading input from the board: buttons
    • The logo can be touched and detected as a floating point value

    Day 3

    • A bit confused how to read the float value from a pin


    Rewrite Distrobox in go (POC) by fabriziosestito

    Description

    Rewriting Distrobox in Go.

    Main benefits:

    • Easier to maintain and to test
    • Adapter pattern for different container backends (LXC, systemd-nspawn, etc.)

    Goals

    • Build a minimal starting point with core commands
    • Keep the CLI interface compatible: existing users shouldn't notice any difference
    • Use a clean Go architecture with adapters for different container backends
    • Keep dependencies minimal and binary size small
    • Benchmark against the original shell script

    Resources

    • Upstream project: https://github.com/89luca89/distrobox/
    • Distrobox site: https://distrobox.it/
    • ArchWiki: https://wiki.archlinux.org/title/Distrobox


    A CLI for Harvester by mohamed.belgaied

    Harvester does not officially come with a CLI tool, the user is supposed to interact with Harvester mostly through the UI. Though it is theoretically possible to use kubectl to interact with Harvester, the manipulation of Kubevirt YAML objects is absolutely not user friendly. Inspired by tools like multipass from Canonical to easily and rapidly create one of multiple VMs, I began the development of Harvester CLI. Currently, it works but Harvester CLI needs some love to be up-to-date with Harvester v1.0.2 and needs some bug fixes and improvements as well.

    Project Description

    Harvester CLI is a command line interface tool written in Go, designed to simplify interfacing with a Harvester cluster as a user. It is especially useful for testing purposes as you can easily and rapidly create VMs in Harvester by providing a simple command such as: harvester vm create my-vm --count 5 to create 5 VMs named my-vm-01 to my-vm-05.

    asciicast

    Harvester CLI is functional but needs a number of improvements: up-to-date functionality with Harvester v1.0.2 (some minor issues right now), modifying the default behaviour to create an opensuse VM instead of an ubuntu VM, solve some bugs, etc.

    Github Repo for Harvester CLI: https://github.com/belgaied2/harvester-cli

    Done in previous Hackweeks

    • Create a Github actions pipeline to automatically integrate Harvester CLI to Homebrew repositories: DONE
    • Automatically package Harvester CLI for OpenSUSE / Redhat RPMs or DEBs: DONE

    Goal for this Hackweek

    The goal for this Hackweek is to bring Harvester CLI up-to-speed with latest Harvester versions (v1.3.X and v1.4.X), and improve the code quality as well as implement some simple features and bug fixes.

    Some nice additions might be: * Improve handling of namespaced objects * Add features, such as network management or Load Balancer creation ? * Add more unit tests and, why not, e2e tests * Improve CI * Improve the overall code quality * Test the program and create issues for it

    Issue list is here: https://github.com/belgaied2/harvester-cli/issues

    Resources

    The project is written in Go, and using client-go the Kubernetes Go Client libraries to communicate with the Harvester API (which is Kubernetes in fact). Welcome contributions are:

    • Testing it and creating issues
    • Documentation
    • Go code improvement

    What you might learn

    Harvester CLI might be interesting to you if you want to learn more about:

    • GitHub Actions
    • Harvester as a SUSE Product
    • Go programming language
    • Kubernetes API
    • Kubevirt API objects (Manipulating VMs and VM Configuration in Kubernetes using Kubevirt)


    OpenRC in openSUSE by jimedrand

    Description

    I have been using openSUSE for 3 years and I am just seen the systemd as init system. Actually, I want to make openSUSE with supports to another init such as OpenRC init that I'm always using it in another distros, and I was think, "what about if I'm including OpenRC init in openSUSE and give anyone as second way for them who don't want to use systemd?", and I'm curious about that. That's why I'm opening these.

    Goals

    Giving OpenRC support for Tumbleweed first, then going in Leap in future if possible.