New package: tinc (mesh VPN) - Need assistance packaging
-
I've been toying with a package for the tinc mesh VPN (http://www.tinc-vpn.org) and I think I've gotten it working pretty well. The one area I've got no clue on is the new PBI/build stuff so I'd like someone who knows how this stuff works to let me know if I specified it all correctly. In testing I've been using the FreeBSD binary packages. It's a pretty straight forward install with only one dependency (lzo2).
Here is what I have in my pkg_config.8.xml.amd64 file:
<package><name>tinc</name> <website>http://www.tinc-vpn.org/</website> <descr>tinc is a Virtual Private Network (VPN) daemon that uses tunnelling and encryption to create a secure private mesh network between hosts on the Internet.</descr> <category>Network Management</category> <depends_on_package_base_url>http://files.pfsense.org/packages/amd64/8/All/</depends_on_package_base_url> <depends_on_package>lzo2-2.06.tbz</depends_on_package> <depends_on_package_pbi>tinc-1.0.18-amd64.pbi</depends_on_package_pbi> <build_port_path>/usr/ports/security/tinc</build_port_path> <build_port_path>/usr/ports/archivers/lzo2</build_port_path> <build_pbi><ports_before>archivers/lzo2</ports_before> <port>security/tinc</port></build_pbi> <version>1.0.18</version> <status>ALPHA</status> <pkginfolink>http://doc.pfsense.org/index.php/tinc_package</pkginfolink> <required_version>2.0</required_version> <config_file>http://www.pfsense.com/packages/config/tinc/tinc.xml</config_file> <configurationfile>tinc.xml</configurationfile> <logging><facilityname>tinc</facilityname> <logfilename>tinc.log</logfilename> <logtab>tinc</logtab></logging></package>The various config and XML files can be grabbed here if anyone wants to take a look: http://s3.botch.com/tinc-pfsense.tgz
My main question is did I put in all the build_* tags correctly to get the system to actually build the two binaries?
If so, how do I go about getting this added to the real repo?
-
If you want it to work on 2.0.x as well as 2.1, you need a depends_on_package tag for a tinc tbz file also.
The depends_on_package tags are used by 2.0.x - they are ignored by 2.1.
The build_port_path and build_pbi tags look OK, though if the FreeBSD port of tinc already depends on lzo2 you probably do not need to specify that manually (in build_port_path, depends_on_package or in ports_before).
If you only want it to work on 2.1 in a PBI, then you can remove the build_port_path, and depends_on_package tags, then set the required version to 2.1.
-
Thanks jimp. I started this on 2.0 but have only been testing on 2.1 lately so I think I'll just make it 2.1 only. How does the below look:
<package><name>tinc</name> <website>http://www.tinc-vpn.org/</website> <descr>tinc is a Virtual Private Network (VPN) daemon that uses tunnelling and encryption to create a secure private mesh network between hosts on the Internet.</descr> <category>Network Management</category> <depends_on_package_base_url>http://files.pfsense.org/packages/amd64/8/All/</depends_on_package_base_url> <depends_on_package_pbi>tinc-1.0.18-amd64.pbi</depends_on_package_pbi> <build_pbi><port>security/tinc</port></build_pbi> <version>1.0.18</version> <status>ALPHA</status> <pkginfolink>http://doc.pfsense.org/index.php/tinc_package</pkginfolink> <required_version>2.1</required_version> <config_file>http://www.pfsense.com/packages/config/tinc/tinc.xml</config_file> <configurationfile>tinc.xml</configurationfile> <logging><facilityname>tinc</facilityname> <logfilename>tinc.log</logfilename> <logtab>tinc</logtab></logging></package>Assuming it's good, how do I go about getting it added to the repo?
Also, on an unrelated note, do you know if there is any way for a package to add a network interface? I could not find any other packages that do it nor any documentation around it. Looking at the pfSense code it appears OpenVPN gets special hardcoded treatment to support its interfaces showing up when a new VPN is created. My package works fine without an interface in the GUI (you just need to manually handle routing and add broader firewall rules elsewhere) but it'd be nice if it could integrate similar to OpenVPN.
-
That looks OK.
To get it in, the best way is to sign up on github, make a fork of the packages repo, add your files/code, then submit a pull request.
Not sure about the interfaces bit. We do a bit of fudging on the backend with openvpn to rename its interfaces from tunX to ovpnXY. What sort of interfaces does tinc make?
-
Thanks, I'll set up a git account.
As to the interfaces, tinc uses the same sort of tun interfaces that OpenVPN does (it can also use tap but I'm guessing that'll be pretty rare for pf users). I'd played around with adding them into the GUI via various php calls and manual config editing. I can get them to show up by renaming them like ovpnXY but that's pretty confusing GUI wise and I'd need to make sure to track interfaces along with openvpn. I managed to get them in the GUI called tincXY but there is some process on boot that deletes any interfaces with names that don't fit a certain pattern. At that point I decided it'd like take changes to the base code and likely wasn't something that could be done in a package. I thought I'd throw out the question though. If you all are looking to expand the things that packages are able to do in the future that may be something worth considering.
-
Might be worth opening a feature request ticket for on http://redmine.pfsense.org/ with a target of "future"
Having them named tincXX would be best so they fit the right pattern. Most things don't need to know or care that the OpenVPN interfaces exist though, assigning them is optional.
Is there a reason you need to touch the interfaces themselves in the GUI? In older versions (pfSense 1.2.x) OpenVPN was treated mostly like a package.
-
Nothing that can't be handled by some easy command line stuff. It just allows you to do things on the interface in the GUI like you can for all the other interfaces, such as routing and firewall rules. I was just trying to make a nicely integrated package. I have the configuration all in the GUI, logs in logging section, service started in services, status page, etc. next step seemed to be to give it a proper interface to apply routing and firewall rules to.
-
For the firewall rules, it would be easy to just make an interface group under Interfaces > (assign) (or add one to the config from the pkg), and then when you bring up the tinc interface, add it to the group with ifconfig. OpenVPN does this and that's how the openvpn rules apply to all OpenVPN interfaces.
Routing might be a little trickier, but could be handled in the VPN's interface.
-
Good idea on the interface group, I'll have to give that a try.
In the mean time I think I've committed it to git and put in a pull request. Let me know if I need to tweak anything.
-
Looks OK I need to give it another glance before merging - you might want to add the pkg to the non-amd64 pkg_config.8.xml also (just change the package base url so it doesn't have "amd64" in it when copying it there), unless this package really only works on amd64.
-
FYI- it compiled OK and uploaded but it's a little newer than what you put in the XML
tinc-1.0.19-amd64.pbi
Adjust the name and submit another pull request then it should be ready to use.
-
Thanks I think I've bumped version to 1.0.19, added 32-bit, and sent a new pull request.
-
ok, that's all merged and built and uploaded
-
I added the interface group creation during package install. Seems to work well, thanks for the idea. Sent a PR your way for it.
Also, I found what may be a small bug. You can't add menu items to more then one section if they have the same name. In my case I wanted to add an entry in both the VPN and Status menus (similar to how OpenVPN is listed) but it would only show the first one. After a glance at the code it seems to match on name only when seeing if it already exists and doesn't take placement into consideration. For the time being I just changed the name slightly on the Status menu.
-
OK, that request was merged. You may want to bump the version number on the package when you make changes like that. Even if you don't change the binaries, you can see some of the other packages have a separate "package" version that changes independently of the underlying software, so people know to reinstall to pick up recent changes in the package code.
Haven't hit that menu bug before but it's not terribly surprising. That was probably done to avoid duplicate menu entries at some point.
-
is this package now generally available? i cant see it in the list?
-
I believe it's only on 2.1.
-
you dont mean … 2.0.1 ? :(
-
No, only 2.1-BETA
-
This would be handy to have on 2.0.x if someone happens to have the time and it's not too much trouble, it sounds like it's just a packaging issue? Unless 2.1 is really, really close to release, but it's hard to judge release timeframes based on past history with pfSense yet :-)
