Packages wishlist?
-
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…
-
way offtopic
I just mentioned that does hammer work better if you can read hammer from the hammer itself?!? and have changeable plates on that so you can localize your hammer text. Like the shape itself isn't enough.
-
way offtopic
I just mentioned that does hammer work better if you can read hammer from the hammer itself?!? and have changeable plates on that so you can localize your hammer text. Like the shape itself isn't enough.
No, but pfSense is a tool box, not a single tool. And a well organized and labeled toolbox is a lot more efficient to use, than a box where things are wildely out of order and you have to go hunting for the tools.
Also, not everyone is a master craftsman. You want to be able to have the apprentice fetch an auger then you must assume that he may not know how an auger looks like, but if he can read and the toolbox is organized and labeled properly, he will likely fetch the auger, even if he's never seen one before.
Further, since this is a thread about a wishlist, I think it's perfectly fine that I wish what I consider relevant. It's not like I'm dictating features, I just take the liberty to wish for what makes my work easier.
-
IMHO pfsense pkg developers' energy should be focused on making sure that the handful of "Tier 1" packages (e.g. Snort, routing daemons for BGP/OSPF, Varnish/haproxy and Squid) work flawlessly.
Btw I am not sure that trying to glue together packages like Squid + Dansguardian / SquidGuard etc will work as well as in the various commercial UTMs.
Finally, since IMHO pfsense isn't very well suited for SOHO environment (unless one really wants to learn a great deal in the process), it doesn't matter very much if pfsense is always checking to make sure that a user doesn't do the wrong thing (e.g. resolving conflicts between packages Quagga-OSPF vs OpenOSPF etc).
-
Hi,
I would like to see Salt as a package. It would be convenient to be able to remotely configure and manage a bunch of pfSense installations from one central point.
There's already a Salt package available in FreeBSD ports:
http://docs.saltstack.org/en/latest/topics/installation/freebsd.html
-
Finally, since IMHO pfsense isn't very well suited for SOHO environment (unless one really wants to learn a great deal in the process), it doesn't matter very much if pfsense is always checking to make sure that a user doesn't do the wrong thing (e.g. resolving conflicts between packages Quagga-OSPF vs OpenOSPF etc).
You make it sound like learning something were a bad thing. pfSense works just fine in my SOHO setup, as a matter of fact, I switched to pfSense because nothing else out there (except maybe Vyatta, but I don't like their ever more proprietary approach) could do the job I want at anywhere near justifiable costs, because cost is a massive factor in a SOHO office.
Arguing against built-in conflict resolution is like saying circular saws are for professionals only, and therefore they don't need finger guards. We might as well do away with the anti-lockout rule, etc.
IMO any good product minimizes the error potential, that's the whole point of having a user interface in the first place, otherwise, we all could just edit config files with vi. -
In my case I would love to see nginx as package. It can be used as reverse proxy, web server, SSL-offloading for HAProxy (replacement for stunnel), etc.. It is light in resource usage and does great work.
-
Could anyone please create a Zabbix 2.0 Proxy package upgrade? Since there are a lot of improvements in the latest Zabbix release, It would be great if we could use it. Thank you! :-*
-
i'd really like to see some kind of clientless ssl vpn. similar to what sslexplorer or adito is/was. the new astaro UTM has a html 5 based clientless vpn.be great if could link to freeradius also.
-
If an up-to-date OSS project exists for such a thing, I'm sure it could be looked into, so long as the requirements are not crazy (like Adito's need for Java)
There really is no such things as a "clientless" VPN, it may use Java or hook into the browser, but it's still a client.
-
I would like a clickable whois search on the alerts or blocked tab in snort.
Greets, Judex
