A pfSense roadmap
-
With it disabled and/or not recommended, it does not hurt pfSense.
I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Rewrite the code once to Python and thats it. End of support.
On top of that, don't write whatever the fuck you want; 2.3 is set to drop PPTP. 3.0 is far away from us. The rewrite isnt even taking in though PPTP.
2.3 should be released with PPTP "as-is" and disabling/hiding it unless the user himself decides to enable it. If it drops in 3.0 (whenever that is in the far future), so be it (depending on what timeframe, I would probably be for dropping it).
-
I assume these PLCs are sitting behind a router? Why not let pfsense tunnel all the stuff you used to use PPTP for over a different type of vpn?
Because old stuff is usually only compatible with PPTP.
I just gave my point of view; I understand that security wise (and technology wise) the choice to drop PPTP, I just dont agree removing it; I think it should be unsupported.
-
With it disabled and/or not recommended, it does not hurt pfSense.
I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Rewrite the code once to Python and thats it. End of support.
I assume you volunteer to do the job… ::)
-
With it disabled and/or not recommended, it does not hurt pfSense.
I guess you figure the code is self-maintaining. And also will rewrite itself to Python by some magic.
Rewrite the code once to Python and thats it. End of support.
I assume you volunteer to do the job… ::)
You are avoiding the subject.
2.3 is to released soon.
3.0 is to be released in a distant future.Leave it as-is right now unsupported in 2.3 (PHP), 2.3.1 (PHP), 2.3.2 (PHP), 2.4 (PHP), etc.
THEN when the rewrite in Python comes (3.0) if noone wants to rewrite it in Phyton, then don't. Release the 3.0 release without PPTP.
Do I need to spoonfeed you any further?
-
Also, from what I understood, the team wants to move away from having a pfSense distribution to being a package called pfSense that runs on FreeBSD.
If this is so, technically you would install FreeBSD then install a package called "pfSense" and if you still want to, you can install a package that acts like a PPTP server on FreeBSD. Thats what I understood from the blog post although I might be mistaken.
I think that would be great personally :)
-
Do I need to spoonfeed you any further?
No, thanks. Enough time wasted debating obvious junk that should already have been removed, since it's been utterly broken for years.
-
Do I need to spoonfeed you any further?
No, thanks. Enough time wasted debating obvious junk that should already have been removed, since it's been utterly broken for years.
I just want to go on record saying I personally use SSTP and/or OpenVPN. I do understand certain scenarios (like I listed) where PPTP might come in handy (even as a quick test).
-
Also, from what I understood, the team wants to move away from having a pfSense distribution to being a package called pfSense that runs on FreeBSD.
If this is so, technically you would install FreeBSD then install a package called "pfSense" and if you still want to, you can install a package that acts like a PPTP server on FreeBSD. Thats what I understood from the blog post although I might be mistaken.
I think that would be great personally :)
both will exist, but having pfSense as a package (including 'base') will allow us to update individual components. I suppose if someone wanted to create a "PPTP package" and add it in, that would still work.
-
Are there some public discussions about which web framework to use for pFsense 3, how the api would look like etc… or did nothing happen in that regard yet. Also is there a way to sign up somewhere if one would be interested in helping out on the effort?
-
Are there some public discussions about which web framework to use for pFsense 3, how the api would look like etc… or did nothing happen in that regard yet. Also is there a way to sign up somewhere if one would be interested in helping out on the effort?
Not yet, right now from a web perspective we're still focused on the Bootstrap work for 2.3. We'll start a thread on the development board here when all that gets underway, as well as the dev mailing list. Definitely would appreciate help on that effort when we get to that point!
In the mean time, we welcome contributions to the bootstrap effort.
-
Any ~ ETA on 2.4 as Im pretty keen to get a non corrupting Filesystem
-
Any ~ ETA on 2.4 as Im pretty keen to get a non corrupting Filesystem
It'll be beta quite soon. Not too much longer now. It's shaping up fast.
-
Any ~ ETA on 2.4 as Im pretty keen to get a non corrupting Filesystem
It'll be beta quite soon. Not too much longer now. It's shaping up fast.
Currently the description of the 2.4 development snapshot says:
HIGHLY-EXPERIMENTAL pfSense 2.4.0 ALPHA developers tree
Are you implying that at some point in the (near?) future the description will say BETA instead of ALPHA? If so, what are the criteria for ALPHA vs. BETA? I'm looking forward to 2.4 being released so I can move away from a tunnel to native ipv6.
-
Yes, beta soon and that page will be updated.
-
No doubt the developers are all busy getting 2.4 ready for release, but the original post of this thread is coming up on 3 years old. It would be nice if there was an update to the roadmap.
-
OK, I see the new roadmap in the 2.4.0-RC announcement here:
https://www.netgate.com/blog/pfsense-2-4-0-rc-now-available.html
But my concerns right now are the recent Dnsmasq exploits. So I tried updating, and tried, and tried, until I read the not so fine print:
"32-bit x86 and NanoBSD have been deprecated and are not supported on 2.4."
Well fuuuuu. I just repurposed a Checkpoint U-20 box, and bought a spare just in case. Alas, they are Pentium-M based, which means a lousy 32 bit x86 core. So most embedded hardware can now be tossed in the trash because they have old 32-bit cores?
And how about my security concerns over Dnsmasq?
https://www.netgate.com/blog/no-plan-survives-contact-with-the-internet.html
"Users on pfSense 2.3.x or earlier concerned about these bugs can switch to the DNS Resolver (Unbound) until a new pfSense software release is available."
Will there be a 2.3.4_2 for us poor 32-bit untouchables?
What would it take for us to roll our own 32 bit 2.4 binaries? I see that FBSD-11.1 is still supported for 32-bit x86. All of the FreeBSD packages will have precompiled 32 bit binaries, so what else do I need to do to build a 32 bit x85 version of pfSense 2.4+?
-
Read https://www.netgate.com/blog/no-plan-survives-contact-with-the-internet.html closer.
We'll be putting out 2.3.5 after 2.4.0.
-
Ooops, that's on me. I stopped reading when it seemed to be addressing only the 2.4 branch. Thank you for including plans to update the 2.3 branch.
The question remains going forward: can we come up with a recipe for a 32-bit build of the 2.4 branch when the dust settles? Sure it won't be supported but sometimes you just gotta deal with it.
-
No, it is not viable. None of the patches have been tested on i386 and it's entirely possible there are required pieces missing (like an i386 kernel config), and who knows what else.
It isn't going to happen, and the time wasted on chasing it down on the off chance it might work would be better spent on non-obsolete hardware.
-
And how about my security concerns over Dnsmasq?
https://www.netgate.com/blog/no-plan-survives-contact-with-the-internet.html
"Users on pfSense 2.3.x or earlier concerned about these bugs can switch to the DNS Resolver (Unbound) until a new pfSense software release is available."
FYI- As of right now, if you are on 2.3.4-p1 you can fetch an updated dnsmasq
pkg update -y dnsmasq
That should find the update and install it, afterward you have to restart the dnsmasq service
