Packages wishlist?
-
Like lcdproc that been part of pfsense for long time and works with number of devices and lcd displays.
-
I'm voting for frox - ftp proxy server. This small package exist for FreeBSD but it's not starting automatically when added with pkg_add.
This is a better proxy for ftp connections than squid with all ports included in CONNECT method.
Best regards
IGIdeus -
This small package exist for FreeBSD but it's not starting automatically when added with pkg_add.
You need to include .sh in frox startup script name at /usr/local/etc/rc.d and also edit the file changing checks on rc.conf from YES to NO.
-
FreeRADIUS 2, updated to a PBI, since the old package is now blocked even though I know I can make it work >:(
-
Scratch that there's a PBI now, just after I got it working without it LOL. I'll test next week.
-
This may not be the ideal place for this posting, but felt it was the most relevant sub-forum to post this, please move if I was incorrect.
I would like to see the ability to easily roll back packages. That way users can avoid the impact of bad updates, such as what has been going on since at least the 12th for the snort package, there maybe others but this the only that has greatly effected my install. I am setting up a new pfsense install to show my bosses and to try and sell them on a subscription. Yet I can not even build the system they want due to snort being broken.
I honestly do not get why there is no method or easy ability for one to roll back a released package. What is the logic behind this? For those coming into the product at a "bad" time due to package issues this would help alleviate the sour taste that comes after finding out multiple pushes of the same package have not worked, each push with its own set of issues.
I feel this a great product and its abilities are greater than other offerings, but this is major thing to me and have seen that many others feel the same way. I personally can not in good faith just recommenced something that I will have to be responsible for that does not at least have the ability to rollback a package until "bugs/breakages" are worked out fully on a released package.
-
I would like to see the ability to easily roll back packages.
You can create o local packages repo for your company and sync it with oficial repo only after you test new updates on a non production machine.
-
Thank you for the suggestion, I had not even thought of that for some reason. Though I still think it would be nice to have the ability to roll back a package version on an actual install or even on a testbox without having to do a whole local repo. But will read more into it to see what it actually entails.
-
@hbc:
I would like a package for LLDP support.
There exist some projects that already work:
This is now at https://github.com/vincentbernat/lldpd and is very alive and well
supports lldp (as the name implies) as well as cdp and a small buffet of other vendor proprietary equivalents. it also implements the LLDP mib via net-snmp and is a client/daemon architecture now.
downside is that although the author has factored the linux specific code into its own sections in anticipation of a bsd 'port' - this work hasnt been completed. so someone with some understanding of layer2 ethernet in bsd would need to complete this work. the author is very active on github and has accepted happily a few minor patches and feature requests from myself.
+1 for including it as a package
-
With SSDs and drives cheap and providing a lot more storage than a typical pfSense install requires, something like that could be a useful way to keep the firewall with less holes, because some data can be stored on the gateway itself…
...running a git server in a jail, maybe?
-
It would be nice to know, or better to show, which packages require which others, and which ones are mutually exclusive and/or redundant.
e.g. HAVP/SquidGuard vs. Dansguardian
e.g. freeRadius vs. freeRadius2
e.g. Squid vs. Squid3
e.g. IPBlocklist/CountryBlock vs. pfBlocker
e.g. OpenOSPFD vs. QuaggaOSPF
etc.One way would be to disable the installation of a package if a competing package is installed, with a link to the installed package that prevents the installation of the package.
-
HAVP/SquidGuard vs. Dansguardian - Its up to you, both requires squid package.
freeRadius vs. freeRadius2 - freeradius is stable, freeradius2 has a lot of new features
Squid vs. Squid3 - same point, v2 stable(and supported by core team), v3 new features
IPBlocklist/CountryBlock vs. pfBlocker -pfblocker , IPBlocklist/CountryBlock are deprecatedOne way would be to disable the installation of a package if a competing package is installed, with a link to the installed package that prevents the installation of the package.
I think a good search on forum/package description could be a better way. For example: Some admins has lightsquid and sarg installed and both packages are squid reports.
-
As a user, I want to install a web filter, a web server, a DCHP server, a DCHP Relay, an E-mail filter, etc.
While it's nice to read in the package description what software project is used to provide a specific service, and while that should be evident on the respective configuration page, I think it's not what I'd want to see in Dashboard or a function menu names.
pfSense itself has gotten much better in that respect, and for a few minor things like pfInfo and pfTop uses proper, descriptive names throughout, rather than supplying the names of the underlying software projects.
Also "Dynamic DNS" would better be named "DNS (dynamic)" or "DNS - DynDNS" to make sure that all the DNS related things remain grouped.The point here is to have related things grouped, and to find things by function/protocol without having to know what software project is behind it.
Unfortunately, that effort is quickly ruined by installing a few packages.
Here a few suggestions:
Dansguardian => E-mail Filter
Proxy Server => HTTP Proxy
Reverse Proxy => HTTP Proxy (reverse)
Avahi => ZeroConf Proxy
Dynamic DNS => DNS (dynamic)
IMSpector => IM Proxy
OpenBGPD => Routing BGP
Quagga OSPFd => Routing OSPF
Postfix Forwarder => E-mail Forwarder
RIP => Routing RIP
siproxd => SIP Proxy
etc. etc. -
The problem with that is that is that multiple packages can have the same function, but they need unique menu names. Plus the menu names can only be a certain length.
Dansguardian and SquidGuard are both Proxy Filters of a sort, but they'd need unique names as someone could have both installed at once.
Sometimes there are conflicts (which could be handled better) so things could share a name, like Quagga OSPF and OpenOSPFD, but not everything is quite so clean.
Also Squid can proxy more than HTTP so calling it an HTTP proxy isn't quite accurate either…
Most of these are bikeshed debates that ultimately nobody will be happy with. :-)
-
The problem with that is that is that multiple packages can have the same function, but they need unique menu names. Plus the menu names can only be a certain length.
Dansguardian and SquidGuard are both Proxy Filters of a sort, but they'd need unique names as someone could have both installed at once.
Well, add a postfix to the name to unique it, but at least people will be able to find and group things by function.
The only other clean alternative is if we had a custom menu system that would allow us to rearrange and rename menu items…Sometimes there are conflicts (which could be handled better) so things could share a name, like Quagga OSPF and OpenOSPFD, but not everything is quite so clean.
Also Squid can proxy more than HTTP so calling it an HTTP proxy isn't quite accurate either…
OK, we can try to find a better name, but "proxy server" is too generic when we also have SIP proxies, E-mail proxies, etc.
Most of these are bikeshed debates that ultimately nobody will be happy with. :-)
Well pfSense itself wasn't always very clean/consistent, but I doubt there were many complaints when that situation improved. I just think it's time for packages to follow suit, and make sure that a package doesn't stick out like a sore thumb but is indistinguishable from the base system for a user once installed.
-
I just think it's time for packages to follow suit.
You mean change current package categories to a more specif one?
for example:
change dansguadian from Services to proxy filter
change squidguard from Network Management to proxy filter
change squid from Network to proxy serveror create tabs for each category
-
He's talking about the actual menu entries… Services > Proxy Filter (squidguard), Services > Proxy Filter (squid) and so on.
-
In an ideal world, we might have freely definable, customizable menus, but that's a huge change and may make into something like pfSense 3.0 but it's certainly not around the corner or easy to do.
In the second best of worlds, we'd have submenus for specific categories, e.g.
Services > DNS > Server
Services > DNS > Forwarder
Services > DNS > Dynamic DNSThat would solve the issue with long drop-down menus and makes things easy to find, although the former has been somewhat defused with the recent addition of scrollable menus.
Of course, that's a non-trivial change to the UI which some people may not even agree with, even though.
So in the third best of worlds, we simply name things in such a way that they fall in place within a linear menu structure in logical groups. The pfSense base system does that already fairly well; notice e.g. how nicely the DHCP and most of the DNS items fall into place.
He's talking about the actual menu entries… Services > Proxy Filter (squidguard), Services > Proxy Filter (squid) and so on.
Exactly. Because that's a very easy and quick change and it solves 90% of what the more complex solutions would achieve for almost zero development effort. All it needs is a naming convention that people adhere to.
-
In an ideal world, we might have freely definable, customizable menus, but that's a huge change and may make into something like pfSense 3.0 but it's certainly not around the corner or easy to do.
This is not feasible from my point of view, I think there is no reason why we should customize the feel and looks of a tool. I think the effort should be more or less in a making rules and adjustments of the network
-
In an ideal world, we might have freely definable, customizable menus, but that's a huge change and may make into something like pfSense 3.0 but it's certainly not around the corner or easy to do.
This is not feasible from my point of view, I think there is no reason why we should customize the feel and looks of a tool. I think the effort should be more or less in a making rules and adjustments of the network
Feasible or not, it's not what I suggested we do, certainly not anytime soon.
I do however take a bit issue with the direction of the argument. It strikes me a bit as if we were talking about screwdrivers and you'd say:
"I think there is no reason why we should create ergonomic handles on a tool. I think the effort should be more or less in making durable and non-slip screwdriver tips."The point is, a good screwdriver has both, it may even have a ratcheting handle, in which you can customize the interface, depending on whether you want to screw a screw into or out of something…
