Custom package repos with 2.3

  • Banned

    Hey guys, maybe I'm missing something, but:

    • Remove pkg_mgr_settings.php
    • Remove pkg_mgr_settings.php privilege definitions


    • What exactly is the replacement?
    • How are people supposed to maintain packages when they cannot point things to where their repo is?!  Wiping of pretty much any existing documentation assisting people in that task has not been enough yet?! :o >:(
    • Why we cannot have multiple package repos like every damn shitty Linux distro out there?

    And most importantly: Could you kindly post some concept of what's going on and provide some reasonable documentation to those about ~5 people left who still care enough to touch the packages code? Or, you really intend to repeat the PBI disaster once again?

  • We don't yet have answers re: a replacement, were discussing it earlier today. With the removal of the XMLRPC portion of packages, those pages were no longer applicable.

    Since everything is in pkg including base, there isn't a direct replacement for the way things used to work. There are options for multiple repos in pkg, but there are potential complications.

    We'll put together an updated guide for package developers once we have some good answers there.

  • Banned

    Well… thanks for reply. I find this way of doing things extremely unfortunate. This makes proper testing/development of packages on 2.3 pretty much impossible.

  • This will potentially complicate package testing on 2.3.  I don't yet have Snort converted to Bootstrap, but once I do complete the GUI part, it would be nice to be able to test a complete installation on a 2.3-ALPHA virtual machine like I have always done with 2.2.x and earlier using my own private package repository.

  • Rebel Alliance Developer Netgate

    If you build the pkg versions of the pkg you can always copy the files to the box and add them with pkg directly. The good thing about pkg is that the GUI packages and CLI packages are all the same now. Files are all kept together inside the archive.

    So you can build the package on your builder, pkg delete the old one and the pkg add the new one or some other pkg song-and-dance.

    For example, a basic thing like Cron is pfSense-pkg-Cron-0.3.2, so you can do this if you build a new copy and put it on the firewall:

    pkg add /path/to/file/pfSense-pkg-Cron-0.3.2.txz

    Should also work with "pkg add" and a URL to an http or https web server also.

    Making the package should be as simple as checking out our ports tree copy from github and finding the ports directory, making changes, and then running "make package" like so:

    $ git clone pfSense-ports
    $ cd pfSense-ports/blah/pfSense-pkg-foo/
    [hack, hack, hack]
    $ make package  (might need sudo)
    $ scp work/pkg/pfSense-pkg-foo* root@myfirewall:.

    And then on the firewall:

    # pkg add pfSense-pkg-foo-<version>.txz</version>

    I just tested the above by making a simple local change to the Cron package and then added it to a 2.3 VM that didn't already have it, custom changes were there.

    You could also get fancy and setup poudriere and make your own repo but in most cases that will be overkill.

    EDIT: There are some additional considerations if you add files, like updating the plist, and crafting a new pfSense package from scratch may be trickier if you aren't familiar with how the FreeBSD ports tree works, but overall it will be smoother in the long run. Definitely easier than PBIs!

  • Rebel Alliance Developer Netgate


    Well… thanks for reply. I find this way of doing things extremely unfortunate. This makes proper testing/development of packages on 2.3 pretty much impossible.

    The only thing you can't do is click the button in the GUI to install from an alternate repo (yet) but now that both the GUI and CLI packages are installed completely identically it's all the same and even installing manually with pkg add works the same. Check the format of the pfSense-pkg ports in our ports repo, it's pretty slick, all of the old PHP-based package "install" procedures are there but they are kicked in by the pkg install process now and not reliant on pfSense functions to do it. Much more elegant and less error-prone! :)

  • Thanks @jimp for the instructions on using the new pkg system for testing.  That helps me a lot.  I'm still a bit of a novice when using pkg, but I did eventually learn enough about PBI to be able to produce a package with it, so I will keep plugging along and learning pkg until I am competent with it as well.


Log in to reply