Working with Packages on 2.3 and Converting to Bootstrap
-
Such as?
If it's for a binary package, at least in theory, the pkg code should be handling that properly. I know PBIs had some issues there. When in doubt, pkg add just the underlying program (not the pfSense pkg) and check for the user after.
-
Such as?
If it's for a binary package, at least in theory, the pkg code should be handling that properly. I know PBIs had some issues there. When in doubt, pkg add just the underlying program (not the pfSense pkg) and check for the user after.
Well, the first one I hit was Avahi. Then, there's the infamous Squid thing with the ClamAV stuff where PBI was adding something with wrong UID/GID and the proxy user/group confusion/mess. Also, I recall there vaguely there was some issue related to the UID/GIDs handling with certain range being reserved for pfSense user manager and the accounts removed on reboot???
-
Another note - I don't think this package makes any sense? Never had any GUI.
https://github.com/pfsense/FreeBSD-ports/tree/devel/net-mgmt/pfSense-pkg-iftop
-
Another note - I don't think this package makes any sense? Never had any GUI.
https://github.com/pfsense/FreeBSD-ports/tree/devel/net-mgmt/pfSense-pkg-iftop
It's just there so it gets built and available in the repo. It's console only and very handy to have available.
-
Such as?
If it's for a binary package, at least in theory, the pkg code should be handling that properly. I know PBIs had some issues there. When in doubt, pkg add just the underlying program (not the pfSense pkg) and check for the user after.
Well, the first one I hit was Avahi. Then, there's the infamous Squid thing with the ClamAV stuff where PBI was adding something with wrong UID/GID and the proxy user/group confusion/mess. Also, I recall there vaguely there was some issue related to the UID/GIDs handling with certain range being reserved for pfSense user manager and the accounts removed on reboot???
None of the "official" users would collide with pfSense:
https://github.com/pfsense/FreeBSD-ports/blob/devel/UIDs
https://github.com/pfsense/FreeBSD-ports/blob/devel/GIDsPackages in FreeBSD are supposed to specify their users in the Makefile, and the specifics of UID/GID/etc are pulled from the above files. For example:
https://github.com/pfsense/FreeBSD-ports/blob/devel/www/squid/Makefile#L36I don't think we should have any code in the .inc files or elsewhere to manually make users any longer, if one isn't in the above list we should add it in and also tweak the pfSense package Makefile appropriately.
-
I don't think we should have any code in the .inc files or elsewhere to manually make users any longer, if one isn't in the above list we should add it in and also tweak the pfSense package Makefile appropriately.
OK, sounds good. Junk nuked. :)
-
I had a bit of a look at this task and didn't notice any mention of anything relating to REST..
I noticed the pfSense blog post about converting to REST in 3.0 (https://blog.pfsense.org/?p=1588) - its quite old though.. Is this still the plan?
While in there changing the PHP pages it could be good if people were taking this into account as much as possible..
Something like:
-
Split functional code out into a [file]_rest.php that returns JSON
-
Change HTML page to make REST HTTP requests to execute their functions
Doing this now could get the process of converting to REST early (unless 3 is the next release directly after 2.3?).
I was taking a look at the sipproxd and it seems relatively small and thinking - depending on the time frame that packages need to be converted in - I might be able to take a look at converting that one in this manner? Could give a basic template to start moving to the REST structure..
I'm primary a web developer and work a lot with REST APIs (built in Django) and web front ends (the Ember JavaScript framework)
-
-
REST will be for 3.0 only and some time off (we haven't even began drafting the API) – Seems like overkill to start all that now when we haven't decided on what we'll be using for any of that.
We'll be on 2.3 for a while, most likely there will even be a 2.4, that blog post is long-term goals.
-
I had a bit of a look at this task and didn't notice any mention of anything relating to REST..
I noticed the pfSense blog post about converting to REST in 3.0 (https://blog.pfsense.org/?p=1588) - its quite old though.. Is this still the plan?
While in there changing the PHP pages it could be good if people were taking this into account as much as possible..
Something like:
-
Split functional code out into a [file]_rest.php that returns JSON
-
Change HTML page to make REST HTTP requests to execute their functions
Doing this now could get the process of converting to REST early (unless 3 is the next release directly after 2.3?).
I was taking a look at the sipproxd and it seems relatively small and thinking - depending on the time frame that packages need to be converted in - I might be able to take a look at converting that one in this manner? Could give a basic template to start moving to the REST structure..
I'm primary a web developer and work a lot with REST APIs (built in Django) and web front ends (the Ember JavaScript framework)
I agree with Jimp, we should focus on getting 2.3 out to prevent what could be massive scope creep. Not saying it isn't important though. I was actually looking at make graph.php utilize an API over the weekend so that I could convert the traffic graphs to d3.j3 using JSON for the datasource. If you want to take a stab at converting various small data points to JSON APIs and need someone to bounce ideas off of let me know. I could probably squeeze a little bit of time in the week to hack on stuff like that.
-
-
NUT?
Let me know if anything seems to be missing or if there are any specific topics missed that need covered.
-
Not addressing missing packages yet. The ones we have listed must all be complete first before we can consider expanding that list.
-
Okay, thanks Jim.
Not addressing missing packages yet. The ones we have listed must all be complete first before we can consider expanding that list.
-
Overview of the new pfSense Package port directory structure:
https://doc.pfsense.org/index.php/Package_Port_Directory_StructureLooks great!!!
I've send the first pull request to postfix package. Structure looks extremely easier to port packages to pfsense. Excelent work!!!!!!
-
I've send the first pull request to postfix package.
Still not showing up under Available Packages
-
I've send the first pull request to postfix package.
Still not showing up under Available Packages
it hasn't been merged yet
-
REST will be for 3.0 only and some time off (we haven't even began drafting the API) – Seems like overkill to start all that now when we haven't decided on what we'll be using for any of that.
We'll be on 2.3 for a while, most likely there will even be a 2.4, that blog post is long-term goals.
Maybe a year to an initial release, but yeah.
-
Bind package is needed too..
-
Dear marcelloc and doktornotor, please consider making a independent ClamAV package with default clamav permissions. Its a hell of a ride to make SquidClamAV and Mailscanner run side by side and after each pfSense update all modifications are gone and needs fixing again.
At the moment, I've a working 2.2.6 system with:
Postfix + latest Mailscanner (SA with all modules, DCC pyzor etc.) + SPF marking + ClamD 0.99 (all via pkg install)
Squid + SquidGuard + Squidclamav + c-icap + ClamD 0.99ClamD is running fine, both Squidclamav and Mailscanner use it at the same time without conflicts.
-
I updated another batch of packages, testing is appreciated:
- Backup
- siproxd (status page only)
- FreeRADIUS2 (just needed the config viewer)
- LADVD (status page only)
- OpenBGPD (raw config and status pages)
Of those the most significant one that needs testing is OpenBGPD since I don't have an active BGP connection to test against. Some of the status fields are empty but I'm not certain if it's my lack of working setup or a problem on the page. Feedback is definitely appreciated for that one, and all the rest as well.
-
I pushed updates for Squid, squidGuard, Lightsquid, and some associated fixes in the base system that should at least make things functional for most people. I'll start a fresh thread for those, though.
