Nsh, a unified router style CLI for OpenBSD(github.com)
github.com
Nsh, a unified router style CLI for OpenBSD
https://github.com/yellowman/nsh
23 comments
That is so funny I was actually googling around for this around the same time it was submitted here. The project has been around for at least a decade now. I vaguely remembered what it was called although initially I misremembered it due to confusion with Gnome's nmcli. Happy to have found yellowman's nsh GitHub repo as well the flashrd one. Very cool to be able to interact with OpenBSD just like it was a Cisco or HP managed switch. One day I'd like to compare this with Vyatta.
I would love to have this for an entire OS, not just networking. The ability to capture the entire OS configuration in one file would be amazing. OS upgrade? Get new box, install, copy one config file, boom done. It would also make comparing configurations between hosts so much easier, for example when trying to find out why something works on one box and not on another.
> I would love to have this for an entire OS, not just networking.
To be honest with OpenBSD its not that difficult, and I don't see the point of a tool like NSH for OpenBSD because its so easy to back up and restore all the routing daemon configs.
For your OpenBSD router average setup (from memory, forgive me if I missed something):
For Linux, really the answer is to use Salt or another config tool to get repeatable configs.
To be honest with OpenBSD its not that difficult, and I don't see the point of a tool like NSH for OpenBSD because its so easy to back up and restore all the routing daemon configs.
For your OpenBSD router average setup (from memory, forgive me if I missed something):
- Copy /etc/rc.conf.local
- Copy config files for daemons referred to in /etc/rc.conf.local
- Copy /etc/hostname.if files
- Copy /etc/mygate (if not using dynamic routing)
- Copy /etc/resolv.conf
- Copy /etc/pf.conf
For Linux, really the answer is to use Salt or another config tool to get repeatable configs.
> I don't see the point of a tool like NSH for OpenBSD
I think the point is getting rid of this risk:
> ... forgive me if I missed something
I think the point is getting rid of this risk:
> ... forgive me if I missed something
> I think the point is getting rid of this risk:
What risk ?
If I am (for example) running an OpenBSD firewall or OpenBSD BGP router then there's nothing to forget. It really is as simple as I said it was.
The "forgive me if I forget" was because I wrote my answer from memory instead of looking at my actual script.
There really is absolutely zero need for NSH or any tool like it on OpenBSD if you're just running a router/firewall.
What risk ?
If I am (for example) running an OpenBSD firewall or OpenBSD BGP router then there's nothing to forget. It really is as simple as I said it was.
The "forgive me if I forget" was because I wrote my answer from memory instead of looking at my actual script.
There really is absolutely zero need for NSH or any tool like it on OpenBSD if you're just running a router/firewall.
> You can also git your /etc of course.
You can and you should, in my opinion.
However, you really want to use "etckeeper" [0] to do that (as opposed to "maintaining" /etc as a git repo, manually, yourself).
---
ETA:
Seriously, look over etckeeper's README file [1] and/or man page [2]. Next, go read a couple articles or blog posts that describe "How-To store /etc in a git repository on debian linux" [3]. Then, if you're a sado-masochist, go ahead and actually try it that way for a while. Finally, install etckeeper, spend two minutes setting it up (if your packaging tool didn't do that for you automatically), and almost instantly regain your sanity!
---
[0]: http://etckeeper.branchable.com
[1]: http://etckeeper.branchable.com/README/
[2]: https://man.archlinux.org/man/etckeeper.8
[3]: http://hyperprog.com/howto/etc-git.html
You can and you should, in my opinion.
However, you really want to use "etckeeper" [0] to do that (as opposed to "maintaining" /etc as a git repo, manually, yourself).
---
ETA:
Seriously, look over etckeeper's README file [1] and/or man page [2]. Next, go read a couple articles or blog posts that describe "How-To store /etc in a git repository on debian linux" [3]. Then, if you're a sado-masochist, go ahead and actually try it that way for a while. Finally, install etckeeper, spend two minutes setting it up (if your packaging tool didn't do that for you automatically), and almost instantly regain your sanity!
---
[0]: http://etckeeper.branchable.com
[1]: http://etckeeper.branchable.com/README/
[2]: https://man.archlinux.org/man/etckeeper.8
[3]: http://hyperprog.com/howto/etc-git.html
Agreed, in fact I have all of those in Ansible. I've been using OpenBSD as a home router for over a decade.
When I saw the first paragraph of the Nsh Github Readme my initial thought was "why?".
When I saw the first paragraph of the Nsh Github Readme my initial thought was "why?".
Yes, I agree with that. Recently I've switched my FreeBSD router to OpenBSD, getting it running is trivial and for backups - just few files needs to be rsyncd to my backup machine and that's it.
The windows registry is somewhat like this - a huge extensible data structure containing all the config of a system. Not really portable though (or is it? been a while since I dug deep on a windows box)
Also NeXT/Apple .plist files worked like this.
And looking at modern "DevOps" tooling, we have YAML, or tools that transform YAML into templates and config loaded into other systems (Helm, some parts of Ansible, etc.)
Also NeXT/Apple .plist files worked like this.
And looking at modern "DevOps" tooling, we have YAML, or tools that transform YAML into templates and config loaded into other systems (Helm, some parts of Ansible, etc.)
vyos would be another, though is also networking focused.
Check out NixOs, it does exaxctly that.
> Check out NixOs, it does exaxctly that.
Yeah, but with a whole shidoodle of extra abstraction and complexity that people have to learn and manage.
The subject has been discussed at length on HN multiple times and (IIRC) the consensus is generally the same, the disadvantages introduced by the complexity of NixOs outweigh its benefits.
I'll stick to old-fashioned distros for now.
Yeah, but with a whole shidoodle of extra abstraction and complexity that people have to learn and manage.
The subject has been discussed at length on HN multiple times and (IIRC) the consensus is generally the same, the disadvantages introduced by the complexity of NixOs outweigh its benefits.
I'll stick to old-fashioned distros for now.
Well, you can’t blame someone for replying to
> I would love to have this for an entire OS, not just networking. The ability to capture the entire OS configuration in one file would be amazing.
When you can do exactly that with NixOS.
In my experience it’s not hard to set up a basic configuration on NixOS. But it’s too hard to set up all of my development requirements on NixOS.
> I would love to have this for an entire OS, not just networking. The ability to capture the entire OS configuration in one file would be amazing.
When you can do exactly that with NixOS.
In my experience it’s not hard to set up a basic configuration on NixOS. But it’s too hard to set up all of my development requirements on NixOS.
This is what OpenWRT with the (u)nified (c)onfiguration (i)nterface aims:
https://openwrt.org/docs/guide-user/base-system/uci
uci show
https://openwrt.org/docs/guide-user/base-system/uci
I used this tool a while back. It was fun since I was also working in Cisco IOS a lot at the time, so it was cool to see similarities in the syntax and to use them on my favorite OS. These days I stick as close to base as possible.
I've been wanting to move my pfsense box to a vanilla locked down openbsd box -- I think this is really cool but will stick to the handbook and what not way of doing things so as to not be beholden to a third-party tool