Development environment?

[Patrick M. Hausen]

Hi all,

how do you setup your working environment when e.g. hacking on plugins? A couple of things are evident, like "use git", get a decent IDE, ...
Then I guess it is a good idea to have a virtualized OPNsense installation. No problem, I have several options here.

But how do actually deploy your changes to test them? When I develop for our hosting management at work all I need to do is type "vagrant up" and I have a complete development copy of my data centre. And then I can just run my Ansible playbooks on these instances.

Does anyone have ready-made scripts to deploy from local development environment to a running OPNsense? What do I need to restart after I changed things in a plugin's UI?

Thanks!
Patrick

[franco]

Hi Patrick,

Easy

On the dev VM:

# opnsense-code plugins
# cd /usr/plugins/category/plugin
# make upgrade

Latest git code for this plugin installed... Add new plugin directory and a Makefile borrowed from another plugin and you can start working on files in src/ directory (which maps to /usr/local after install).


Cheers,
Franco

[Patrick M. Hausen]

Hi Franco,

thanks. Two more questions:

1. How do I change the remote to my own git repo? I know how to do that with git, but is there a canonical way provided by OPNsense tooling?

2. Will the method of bootstrapping over an existing FreeBSD system continue to be supported, at least for the time being? Because in that case I would start creating a Vagrant environment - and of course publish it for others to use.

[mimugmail]

1) fork plugins and git clone https://github.com/youruser/plugins

2) I'd GUESS, as long as ZFS is not included in the installer, yes. But the bootstrap is also used for existing installation e.g. when local packages broke or were removed, to start over again.

[Patrick M. Hausen]

@mimugmail

re 1) - I meant what do I need to do on the test VM to make ˋmake upgradeˋ pulls from my repo?

Thanks!

[Patrick M. Hausen]

Sorry, I need to come back once more. If I understood Franco correctly, `make upgrade` will pull the last version of a plugin from git. So far so good.

That means that I have to push every change I want to try to git if I want to use that as a deployment method.

I'd prefer to have a short local edit-deploy-test cycle and only commit and push things that have at least no obvious breakage.

How do you guys go about that? You are not editing directly on the running OPNsense VM, are you? I prefer to use VScode on my desktop and not vi via ssh

[Fright]

@pmhausen
This is probably completely wrong  , but I do simple quick checks directly on the test VM.

I prefer to use VScode on my desktop and not vi via ssh

VScode + https://github.com/billziss-gh/winfsp works

[Patrick M. Hausen]

I'm on a Mac

But thanks for the hint. I'll look for ssh based deployment from VScode. Currently building a Vagrant einvironment.

[franco]

Sure, opnsense-bootstrap is useful for unbreaking a hosed system and it won't go away.

As per manual page opnsense-code also supports different accounts and repositories:

# opnsense-code [-f] [-a myowngithub] myownplugin

(-f deletes the current repo in case one already exists under /usr with the same name)


Cheers,
Franco

[franco]

PS: "make upgrade" *installs* the current code found in the repository, whether it is checked in or not does not matter. There is also "make install" or "make collect" to move either files from the repository to the system or move them from the system to the repository (inline edit kind of thing), but I would recommend "make upgrade" because it builds a proper package and installs it like the firmware GUI would.

[Patrick M. Hausen]

As per manual page opnsense-code also supports different accounts and repositories:
# opnsense-code [-f] [-a myowngithub] myownplugin
(-f deletes the current repo in case one already exists under /usr with the same name)

Ah ... so you have the repo on the test VM! Right? That was the missing piece in the puzzle. I would not do that if I started afresh, but if the infrastructure is already there, I'll look into it.

[franco]

Yes, pull the code into the VM and then run it from there. Make changes and push back to repo out of VM when done.

Cheers,
Franco

[Patrick M. Hausen]

My main concern was how to synchronise changes from my desktop system to the VM ... I am perfectly comfortable with git 

Definitely not going to do larger editing over ssh ... if there's nothing readily available, I'll probably just script something.

[Patrick M. Hausen]

Vagrant virtual environment done:

https://github.com/punktDe/vagrant-opnsense

Enjoy!

[Patrick M. Hausen]

I ran into the first problem. Vagrant insists (I checked the source!) that the first interface (em0) be the NAT adapter with more flexible options for the other ones (em1, em2, ...). Naturally the NAT adapter must be WAN because this is how Vagrant/Vbox guests access the Internet.

If I successfully ran the bootstrap script with the `reboot` command at the end disabled, can I put some interface configuration in place before the initial reboot as an OPNsense appliance? Just create /conf/config.xml with just the interface parts?

Or will `opnsense-importer` automatically look for configs on first startup? I can of course provide a second small virtual disk with a matching structure (if I find some documentation of said structure).

I want to save users the need to use the console to assign interfaces and have everything come up ready to use automatically.

Thanks!
Patrick