IDS/IPS and antivirus on 2.1 release
-
I think having pfsense start up with nothing, exactly as it does now, is the best way to go. It ensures maximum compatibility across a broad range of platforms. I think if you want a package, add a package is the correct mentality. SNORT especially, is something that some just MUST have and others should avoid like the plague.
-
Let's take an objective look at this:
Pros to having things as a package:
- Able to update more frequently independent of a firmware release
- Allows the package development to proceed with more freedom
- Faster response to upstream changes for things like snort versions, rule formats, AV databases, CVEs, etc.
- Keeps the main system simpler, smaller, etc. (less complexity)
- Less bloat in the main system for things many users do not need (snort users are in the minority)
- Most packages works fine as-is for most users
- Smaller download sizes, less bandwidth used for hosting pfSense downloads and mirrors
- Lots of other good things discussed here and elsewhere about the package system.
Cons for having things as a package
- Making those 4 clicks to install the package can be tiresome and tough work the one time you have to do it. I'm surprised people haven't broken their fingers.
- Some people want it pre-installed
- Somehow magically better code and support because it's in the base system.
Things that have little or no bearing on whether or not it's a package:
- The menu name (snort vs IDS/IPS vs some other confusing name)
- How the package behaves during a firmware upgrade that happens for most people 1-2 times per year, if that.
- How a package interacts with other features such as CARP
So, in other words:
- Some valid complaints are not about the package itself, but about how packages in general are handled. This is a base system issue, and you can't "fix" that by moving a package into the base system. You're treating the symptom not curing the disease.
- Some valid complaints are about the code of the packages themselves. This will not be solved by moving it to the base system. Someone still has to fix it. Bringing it into base would only happen if a package was already in good shape, or if someone funding getting it into good shape and other factors deemed it worthy. The same fixes would happen if it were kept a package and someone fixed the package. Hence, broken code is broken no matter where it is, and good code is good no matter where it is.
In conclusion:
- Help the package maintainers fix packages by contributing code, funds, etc.
- Help identify and fix issues with package handling in the base system (patches are always welcome, doubly so if they actually fix things in an elegant and useful way)
- Keep using packages and make them even more awesome than they already are.
If anything arguments could be made for taking even more things out of the base system, though what we have now strikes a good default balance.
If you want a real debate about whether a package should be a package, or in the base system, take a closer look at a small, simple package such as sudo or blinkled. It's a much better debate than this one for large/complex add-ons. ;D
-
I think modularizing things into packages is per se a good thing, but having started with pfSense as a total noob not all that long time ago, I remember the confusions the packages create.
And that boils largely down to competing/conflicting packages that are not recognizable as such, and the vastly differing quality and level of support for various packages.
If there were some sort of curation process, e.g. official packages (things that are maintained by the pfSense team, and are just taken out of the base system for a more modular setup), qualified packages (very commonly used things that for license or other reasons are not part of the base system or official packages, but are tested and have a seal of approval that they work and are consistent with the UI and naming conventions), and user contributed packages (for which no assertion is made in regards to anything), that would be a step forward, particularly if one could restrict the list of packages shown in the "available packages" section to a certain quality level, e.g. only official packages, or qualified and official packages, or everything.
As long as there's a better way of handling package conflicts, and as long as package isn't synonym with less support, less quality, less consistency, etc. I'm all for modularizing things. However right now, I consistently get the feel that anything that's in a package is "second class citizen", and that's pretty much the main reason that I'd love to see everything that I consider important part of the base system.
-
You do see that Alpha, Beta, RC, Stable tag in the packages right? Are those tags confusing?
Also, in every disro of Unix like OS, packages are handled like that. I wouldn't want the "Microsoft" one stop shop o-code method anyway.
Sounds like you just don't like the way opensource projects work in general.
There are some pretty sweet commercial appliances you can buy for an arm and a leg.
Of course, no one can see the code most of the time. No idea if its protecting you or rooting you.
Actually, I have a pretty good idea… Huawei makes some pretty nice stuff. Install it liberally. -
You do see that Alpha, Beta, RC, Stable tag in the packages right? Are those tags confusing?
No, but they turn out to be meaningless. These tags make a statement about the stability of the package, not about the quality of the integration, whether or not they are a modularized part of the official project, or some more or less supported/approved add-on
Also, in every disro of Unix like OS, packages are handled like that. I wouldn't want the "Microsoft" one stop shop o-code method anyway.
This wouldn't be the Microsoft model, more along the lines the Apple AppStore model, except more liberal: for a package to be either official (something that is done by the core project team, but put into a package to make things more modular) or qualified (third party contribution, but tested), it would have to fulfill certain standards e.g. the way their interface works, if it can use aliases properly, what naming conventions are used, etc.
If it doesn't do these things, it would be marked as unqualified user contributed package. -
If you want a real debate about whether a package should be a package, or in the base system, take a closer look at a small, simple package such as sudo or blinkled. It's a much better debate than this one for large/complex add-ons. ;D
- vote for iftop in base ;)
Let the debate begin!
You do see that Alpha, Beta, RC, Stable tag in the packages right? Are those tags confusing?
Actually they are confusing. Take a look at haproxy, haproxy-full, haproxy-devel. They are all marked as release. Something about devel being release status seems a big odd :). I brought that up in another discussion and it was mentioned the tags are not maintained very well. I am not really trying to complain about it though. After a post on the forums I got it figured out. I am just trying to state that the tags are not very accurate it seems for some packages.
-
The RC/Beta/etc tags are largely meaningless. I'd love to fix that, but that means either personally testing each one or getting reliable feedback about the actual quality of a package.
Some, like sudo, are simple and probably could be release quality, but they are also very new and not many have given feedback to say it works or has issues. So to me it may be release, but in general it's "beta" since it's really not quite well-tested and reviewed.
- vote for iftop in base ;)
Let the debate begin!
My heart says +1 because I love iftop but my brain says no because it doesn't really fit in base. :-)
-
My experience is that Stable means it will probably work, beta means alpha and alpha means don't make any freakin plans. You are going to be pulling your hair out for the next several hours if not days.
-
At least they don't mean the same as Google's release and beta which means it will generally work but they might pull the plug at any time :).
-
LESS IS MORE - *Nix philosophy No. 1
I am reiterating that it is always the best to separte base OS from the extra goodies (packages). It keeps simple, both development and system adminstration.
The demand from some of the users who might come from the GUI culture that a monolithic (including packages) pfSense shall deviate the focus from developers. Everyone's need is possible with the current package system (though I am finding pbi a bit exhaustive) on top of base OS. Else I suggest to play a bit on command line and add desired packages in jails to separate the OS from the base OS.
Alternatively, they can compile whatever they need from the pfSense source directly as per their own requirments than asking for the developers. I preferred this way maybe because I am comfortable with the command line since the last century. The exhaustive menus and options on a single page of GUI exhaust me, yet I am for GUIs for those in my team who does not want to follow the sharp learning curve of command line tools, mostly coming from windows and mac cultures (now I can add ubuntu users, too in this group).
DO NOT UPGRADE UNLESS IT BREAKS - *nix Philosophy No. 2
As far as the broken packages with frequent updates of pfSense base are concerned (which is preferred by most of the non-*nix users these days), I would like to remind *nix philosophy that do not upgrade if it does not break. However for snapshot releases you may need to do so, but before check the changelog. FYI, I am still on July 18 snapshot because it is working for my own needs. ;-)
SEPARATION OF PACKAGES - A Suggestion
pfSense 2.1 is alright as it is now, yet I suggest the developers of pfSense to separate the active packages from not-maintained packages to avoid confusion that it is not the problem with pfSense developers' part when the package breaks.Thanks!
-
- Some people want it pre-installed
I guess that slightly missed the mark. Not only "pre-installed", but also "pre-configured".
Of course, as every IT professional knows, everyone has different demands - and about noone one the business side really has any idea about their what their requirements actually are.
http://geekandpoke.typepad.com/geekandpoke/2008/03/quiz-of-the-mon.html
Okay, let's get off topic - to the package system.
One of the shortcoming I perceive is that it appears to be version-agnostic (with regard to the version of the base system).
Yes, there is a text box which may say "stable platform: 2.0". What does this mean? Will it work on 2.0.0, or on 2.0.x as well? Will it run on 2.1.x? Why does it appear at all when I run an obviously incompatible version? Well, the last point might actually be a feature - you can see that somne function is potentially available if you chose to upgrade from, let's say 1.2 to 2.0.
However, things are a bit more complicated. Take vnstat2 for an example. It happily runs under 2.0.x and equally happily crashes under 2.1.x. There's a manual fix available somewhere here in this forum, for months by now, IIRC. However, integrating this fix into the official package will probably break vnstat2 on older pfSense relases. Defiinitely not the way to go!
I contemplated adding a package named like "vnstat2 for 2.1-RC0 and maybe further", but that seems like an extremely crappy workaround. Especially since a pfSense upgrade from 2.0 to 2.1 will not automagically upgrade "vnstat2" to "vnstat2 for 2.1-RC0 and maybe further".
A package system which maintains different versions of packages for different base system versions might solve this issue, but causes another issue: someone has to maintain the "comptability matrx" for each new relese. Not bloody likely.
Any other ideas, anyone?
-
DO NOT UPGRADE UNLESS IT BREAKS - *nix Philosophy No. 2
As far as the broken packages with frequent updates of pfSense base are concerned (which is preferred by most of the non-*nix users these days), I would like to remind *nix philosophy that do not upgrade if it does not break. However for snapshot releases you may need to do so, but before check the changelog. FYI, I am still on July 18 snapshot because it is working for my own needs. ;-)
Not sure that applies in a security relevant context. Usually upgrades mean bug fixes, and bugs are potential exploits. So as far as security relevant software goes, I'd like to be on the latest patch level of every single component of the system, as far as anyhow possible.
I'm sure a few year old version would seem to work just as trouble free, until such point that someone uses a bug for an exploit and hacks the system.
This is a very different scenario as a desktop OS and a word processor, where one can say: "If you could write with it a letter yesterday, you can write one tomorrow, so why bother upgrading and risking potentially incompatible changes?"SEPARATION OF PACKAGES - A Suggestion
[…]I suggest the developers of pfSense to separate the active packages from not-maintained packages to avoid confusion that it is not the problem with pfSense developers' part when the package breaks.That would be a good step. It's essentially impossible to discern which package is acting out "Sleeping Beauty" and rests for the next 100 years, and which ones are being maintained.
-
The package system already has a way to deal with this. The files with the list of possible packages can have min and max pfSense version specified. When 2.1 came out (requiring pbi installer files) lots of packages had their max version set so they would not appear for install on 2.1. These limits have been removed as packages got a pbi available and could install on 2.1. Similarly the min version protects new packages from being installed on 1.2.3 (or very new packages with pbi only, that won't install on 2.0.n).
Obviously, just because a pbi is built, it doesn't mean the package is guaranteed to work on 2.1 - someone also has to test it! So there can easily be packages listed for 2.1 that don't work so well :(
If different things need to be done in configuring a package on different pfSense versions then the code in the package PHP tests the pfSense version and does different stuff accordingly. This is now quite routine, and many packages have a "standard" bit of code at the top of their PHP that sets various "environment variables" depending on the run-time pfSense version. Subsequent code substitutes the variables as needed.IMHO, the package system is a great thing, and just needs:
a) More package maintainers to care for their package and are willing to learn how packages are implemented and do their code in a reasonably common manner.
b) Fixing up the alpha, beta, release, stable… package status - first make an agreed list of status words, someone to assess how robust each package is now, update the status, then in consultation with package maintainers, keep the status up-to-date. (and maybe add a filter to the package list display to just show packages from a selected status and above)
c) Add more package doco and release notes (and future plans even) on the WiKi (pointed to from the package install list) so that users have an easy trail to follow to know what is going on with a package.I can understand that for the BSD Perimeter/Electric Sheep Fencing guys, they need to be very careful about a package having a status that implies it is "officially supported" in some way. They need to decide if they are happy to have a package status that means "really great and won't ever break your base system, it will be supported like the base system". Otherwise the set of package status words needs to have a "best" status that does not imply this...
It all requires willing and capable volunteers.
-
DO NOT UPGRADE UNLESS IT BREAKS - *nix Philosophy No. 2
As far as the broken packages with frequent updates of pfSense base are concerned (which is preferred by most of the non-*nix users these days), I would like to remind *nix philosophy that do not upgrade if it does not break. However for snapshot releases you may need to do so, but before check the changelog. FYI, I am still on July 18 snapshot because it is working for my own needs. ;-)
Not sure that applies in a security relevant context. Usually upgrades mean bug fixes, and bugs are potential exploits. So as far as security relevant software goes, I'd like to be on the latest patch level of every single component of the system, as far as anyhow possible.
AFAIK, a bug means the system breaks, no matter to what extent. So bug fix is the part of the broken system. I do not deny that.
I'm sure a few year old version would seem to work just as trouble free, until such point that someone uses a bug for an exploit and hacks the system.
New exploits can happen to any system any time because penetrators (particularly with APT guys) use newer methods than the newest that you think of! ;-) So there is always a risk of new exploits.
In some places I am using firewalls-cum-routers that runs on a single floppy disk on a very low-end machine, working without any problem since the last century. So it depends on sys-/net-admin.
This is a very different scenario as a desktop OS and a word processor, where one can say: "If you could write with it a letter yesterday, you can write one tomorrow, so why bother upgrading and risking potentially incompatible changes?
Mostly frequent upgrades through upgrade managers is the problem with the one who uses sophisticated Xwindows systems, particularly in desktops. What I have seen is most of the computer users these days choose to upgrade stuffs automagically without knowing what they are doing to the system nor reading any changelogs or security advisory. They do it just because something is automagic!
I have seen even on the *nix systems like Debian, CentOS that sometimes things break because of incompatibility of libraries after an update which would have been working flawlessly earlier. Maybe that is the reason, pfSense team has chosen pbi which delivers both packages plus dependency libraries like in NixOS.
However, I am for upgrading for security vulnerabilities plus feature needs, not because it just says that there is something new in the market. If it works and safe, there is no need to upgrade. It's like marriage. ;-)
Ed Hillary was asked why he climbed Mt. Everest, his reply was "Because it is there." It does not mean that everyone has to climb Mt. Everest because it is there. Same applies to software upgrades, it is not always necessary to upgrade just because it is there!
