OPNsense Forum
Archive => 17.1 Legacy Series => Topic started by: ooboyle on May 11, 2017, 06:48:39 pm
-
Running:
OPNsense 17.1.6-amd64
FreeBSD 11.0-RELEASE-p8
OpenSSL 1.0.2k 26 Jan 2017
Can I safely enable the FreeBSD repo?
I need to install py27-salt and any dependencies.
Oliver
-
Hi Oliver,
It's never safely recommended as it can break at any moment pkg is ran now or in the future due to the way the packages are linked against OpenSSL/LibreSSL and numerous option tweaks.
The normal way is to enable it, install hoping pkg will not delete vital packages for OPNsense, then disable the interface again. Optionally lock the required package from the GUI to keep it safe on upgrades (although this may prevent OPNsense from upgrading)
A safer way would be:
# opnsense-code tools ports
# cd /usr/ports/sysutils/py-salt
# make install
To build the tool natively on your box.
Cheers,
Franco
-
Thanks, Franco.
Yes, I assumed that would be the answer. I took a snapshot, added the package, updated opnsense as well, and all works fine.
Given that salt is a config mgmt tool, and therefore quite likely that many people would benefit from having it's presence supported by opnsense, are you able to add it to your repo?
I'm not a fan of compiling directly. Packages only.
Oliver
-
Hi Oliver,
To be honest I don't like compiling either. 4 times the compile for py-salt, added to every release, growing package mirrors. The carbon footprint and all. ;)
The dependencies are a bit heavy: https://www.freshports.org/sysutils/py-salt/
I can try a test build, but we would like to steer away from providing heavy ports. It adds release time and sometimes sweat when builds fail in packages that we don't even have plugins for.
So to ask more vividly: anyone else using py-salt?
Cheers,
Franco
-
Franco,
I'd be happy to use the saltstack repo as per: https://docs.saltstack.com/en/latest/topics/installation/freebsd.html
But when I tried to install it, it wouldn't work. Some very minor dependency issue, is seemed. If you can get that working, it would also be an acceptable path forward.
I do understand about wanting to keep your repo slim but config mgmt tools are becoming more and more common. If you want enterprises to jump in, this is a must. You'd hit the majority with salt, chef, and puppet.
Oliver
-
Hi Oliver,
That's a good option that saltstack is doing there, although the mirror is slow and does not have signed packages (it has HTTPS at least).
However, the conflict revolves around "py27-setuptools27", which was renamed by from FreeBSD two months ago and subsequently adapted by OPNsense, which caused upgrade issues for some people here too.
So the matter of the fact is that "These packages are usually available earlier than upstream FreeBSD" is not true, which causes your problem. They would need to rebuild their mirror on top of the latest FreeBSD ports.
That being said, I tried the workaround we had to do in OPNsense to get this working:
# pkg delete -f py27-setuptools
# pkg install py27-salt
This on a normal OPNsense installs 23 packages with a total of 108 MB storage space. That's what I meant by heavy dependencies. :)
But it still doesn't work because multiple packages depend on py27-setuptools and py27-setuptools27 at the same time and it ends up installing one of them and blocks the other again.
Cheers,
Franco
-
Here's a snapshot TEST build based on OpenSSL/amd64:
saltstack: {
fingerprints: "/usr/local/etc/pkg/fingerprints/OPNsense",
url: "pkg+https://opnsense.c0urier.net/snapshots/py-salt/${ABI}/",
signature_type: "fingerprints",
mirror_type: "srv",
priority: 11,
enabled: yes
}
The size of this would add more than an hour of build time to our current releases and several tens of MB to our mirrors and subsequently major upgrades. I'm not against pulling in more enterprise, but I'm not convinced the benefit for non-enterprise users in this community is clear so this may violate the goal of mutual benefit.
Cheers,
Franco
-
Franco,
Thanks for looking into this in more detail. Based on what you said in reply #5, it sounds like the preferred approach is for them to rebuild their mirror on the latest FreeBSD ports. Does that still hold true?
If so, I'll see if I can alert them to the situation and request a rebuild.
Oliver
-
Based on what you said in reply #5, it sounds like the preferred approach is for them to rebuild their mirror on the latest FreeBSD ports. Does that still hold true?
You are spot-on, yes.
Cheers,
Franco