My opinion is that pfSense is becoming unusable…
-
i tend to agree every single upgrade ive done has broken the system in a new way everytime.
unable to allocate swap space.
packages breaking.
or the system just breaking spewing strange errors.
it feels like the big testing should perhaps be longer and less new version released in a fast pace. -
it feels like the big testing should perhaps be longer and less new version released in a fast pace.
perhaps they should be longer, perhaps they should not be longer ….
perhaps there are just not enough people trying the snapshots when they are available .... "lets wait until its released before risking a broken system" <== if that's the case, then waiting longer would be pointless
-
i tend to agree every single upgrade ive done has broken the system in a new way everytime.
unable to allocate swap space.
packages breaking.
or the system just breaking spewing strange errors.
it feels like the big testing should perhaps be longer and less new version released in a fast pace.Packages are not maintained by the pfSense people.
Asking that pfSense should be tested longer because some volunteers are not getting those packages updated fast enough is a stretch. -
I started using pfSense with 2.2 beta, I built my appliance and I did not ever had any real/stopping problem. pfSense is far far the better firewall/routing OS I ever used.
Packages are well maintained by other brilliant guys, never had a problem with them, in particular Snort and pfBlockerNG (I have been a beta tester also).
I simply thank all pfSense Team for their work, I am showing my appreciation with a Gold subscription in order to support them to get pfSense better. -
I've been using it for over a year and never had an upgrade problem.
In fact, I've never had any problem. It just works (and very well).
-
After the release of 2.2 this project has become full of bugs and is unusable!
I think it is not just my opinion, too bad, it was a nice project ….
Probably more a reflection of the network admin than the project.
-
Lets be clear here - this guy was installing on a OLD ip530, what was that EOL and Support back in 2010 or something.. And sure looks like he got it installed to me from this thread
https://forum.pfsense.org/index.php?topic=89481.msg495079#msg495079
I have been running pfsense on hardware and vm for years and have never had an install/upgrade problem.. Then again I don't install to ancient - is that hardware listed to being supported for this version? Its like people complaining of problems with 2.2 (freebsd 10.1) running on pre 5.5u2 versions of esxi.. Previous versions of esxi do not support 10.1 freebsd.. So why would they support pfsense that is on freebsd 10.1, etc..
I agree with tim – PEBKAC!!
-
I understand your position John, but come on…
Just because you have never had an upgrade issue doesn't mean that others have not. There are a number of upgrade issue posts on the forum, and I have had my pfSense made unusable 2x on upgrades. And that is on supported hardware, on a clean system with only 2 packages installed (and zero errors in logs, etc prior to upgrade).
So it CAN happen.
I like pfSense, so I'm not saying it is 'going downhill'. But I am saying that it isn't perfect, and not all issues are end user caused...
-
… on a clean system with only 2 packages installed ...
But there is your problem.
You are using packages.
Since most packages are not maintained by the core devs, you can not be sure that they still work after an upgrade.If you are running pfSense in a production environment you really need to setup a test environment first to make sure that everything work before you upgrade your production devices.
Or just wait a few days/weeks before upgrading and observe the forum to see how things are going. -
"not all issues are end user caused"
Agreed, but MANY of them are..
You can not expect pfsense devs to test every possible upgrade scenario on every possible hardware combination. Especially with packages that are not part of the core code.
If you are running pfsense in production setup, no matter the hardware I can not believe you would go through an upgrade without testing? Or at min a easy planned ahead rollback plan.
Everyone from the devs to the fans of pfsense would benefit from planned and documented upgrades, where issues could be reported with detailed information on failure or success. What specific hardware, what specific packages. The config prior to the upgrade, the config after the upgrade if it finished but stuff not working, etc.
I have no sympathy for admins that click upgrade in a production setup without any pre-thought to what could go wrong, etc. Whats the saying plan for the worst hope for the best ;)
Personally I am not really a fan of upgrading with major version changes and normally would do a clean install with restore of configuration. There is a big difference going from 2.2.1 to 2.2.2 then going from 2.1.5 to 2.2 or even more likely to have issues going from 2.0 to 2.2
Maybe part of your upgrade plan when your on such OLD hardware if in production setup is to take the time to do a hardware refresh and swap in with a clean install. This allows you rollback to working system very quickly if something goes down hill.
So while not all problems are "user" related - yes there is going to be bug and problems with any system.. Can tell you have had more issues with upgrading cisco then ever had with updating pfsense for example.. But if you actually plan for what your doing vs just oh new version is out – click.. WTF what went wrong?? That damn pfsense is so unstable!!
Even on my home setup I take a snapsnot before I upgrade even to a minor version x.x.0 to x.x.1 etc..
-
Or at min a easy planned ahead rollback plan.
x 1,000,000. Before I upgrade, I have:
- a snapshot
- a full backup
- a config.xml backup.
Doing an upgrade of anything without a rollback plan is just stupid, like going without insurance.
-
That's also why I love CF-based NanoBSD. I never upgrade the CF card in the system. I always take a fresh CF with a freshly dd'ed image on it, restore the config from the previous version (using similar hardware usually put on a shelf for spare). When finished, just power off the live system, swap the CF card and power on.
I still have the old CF card with the previous working version in my pocket, which I can pop back in if it turns out later that for some reason we don't like the upgrade. Some things can be detected weeks later…
And it's also the fastest way to do the upgrade, you only have downtime during power on...
-
@KOM:
Or at min a easy planned ahead rollback plan.
x 1,000,000. Before I upgrade, I have:
- a snapshot
- a full backup
- a config.xml backup.
Doing an upgrade of anything without a rollback plan is just stupid, like going without insurance.
I'd like to add that I always have the installer for the version that I am currently running in the event I need to wipe and roll back.
-
That's also why I love CF-based NanoBSD. I never upgrade the CF card in the system. I always take a fresh CF with a freshly dd'ed image on it, restore the config from the previous version (using similar hardware usually put on a shelf for spare). When finished, just power off the live system, swap the CF card and power on.
I still have the old CF card with the previous working version in my pocket, which I can pop back in if it turns out later that for some reason we don't like the upgrade. Some things can be detected weeks later…
And it's also the fastest way to do the upgrade, you only have downtime during power on...
I guess you never noticed the previous working version is still there on the alternative slice…
-
OFF topic:
Lately it happened with several Windows 7 freshly installed HP machines in my environment that after a regular Windows Update procedure (which installed about 100 updates), after reboot, they just went BSOD. I had to reinstall them from scratch… and it happened again. Turned out a specfic update pack from Microsoft was the culprit. It's still inthere, they didn't remove it. Most probably because it doesn't generate the same error on other machines...
-
I guess you never noticed the previous working version is still there on the alternative slice…
Thanks again for your valuable irronic input. Congratulations my friend.
I also do some customizations on my systems by installing some special FreeBSD packages which I like to do not on the live system. This is more important than messing with slices, trust me (I've ran into it on 2 of my boxes).
-
I will never quite understand people that will waste the time to complain and bash a product that they got for free.
OP, no one is making you use this product. If you don't like it, leave. Better yet code something better yourself so you have a valid platform to complain from.
-
roll eyes
Giving feedback is OK (pos or neg) - even a good thing. Of course it needs to be constructive (which maybe the OP was/wasn't). But insinuating any dissenting opinions or comments shouldn't happen isn't productive either.
-
I think everyone would welcome productive comments on how to make pfsense better. But commenting that its not useable because you had an issue trying to upgrade some ANCIENT hardware is just BS all around.. The OP has a whole 4 post… So clearly he has been quite active with the community that all wants to see pfsense improve and thrive.
The OP is a F'ing troll to be honest.. And that we feed him is our own problem to be sure..
-
The OP is a F'ing troll to be honest.. And that we feed him is our own problem to be sure..
I agree, this topic should have ended and been locked right after DotDash's reply. Two pages now headed to three. Can I get an admin plz. ;)
