PfSense Two-factor authentifaction
-
You could perhaps test/update this: https://github.com/pfsense/pfsense-packages/pull/715
Requires python. Gets easier after 2.3 is released.
Of course, after 2.3, I start looking at taking all of the PHP off the system anyway.
-
@jwt:
You could perhaps test/update this: https://github.com/pfsense/pfsense-packages/pull/715
Requires python. Gets easier after 2.3 is released.
Well Python is already there with 2.2.5…
@jwt:
Of course, after 2.3, I start looking at taking all of the PHP off the system anyway.
Hopefully this won't be "organized" the bootstrap way… ::)
-
Hopefully this won't be "organized" the bootstrap way… ::)
Maybe you should work here.
-
@jwt:
Hopefully this won't be "organized" the bootstrap way… ::)
Maybe you should work here.
Well I don't do Python so I would't be of much use for that goal… :P
On a more serious note, people like Phil Davis could provide more input on that kind of "development by copy-paste chaos" model embraced in bootstrap. Beyond occasional venting of frustrations on a random PR fixing 75866th dumb regression they've remained pretty much silent. Seriously guys, another disaster of similar scale could well kill the project.
-
@jwt:
Hopefully this won't be "organized" the bootstrap way… ::)
Maybe you should work here.
Well I don't do Python so I would't be of much use for that goal… :P
On a more serious note, people like Phil Davis could provide more input on that kind of "development by copy-paste chaos" model embraced in bootstrap. Beyond occasional venting of frustrations on a random PR fixing 75866th dumb regression they've remained pretty much silent. Seriously guys, another disaster of similar scale could well kill the project.
I'm not sure I understand what you mean by '"development by copy-paste chaos" model embraced in bootstrap'. The main source of the trouble is that there have been (ahem) "community members" who, while contributing to the effort, have checked off pages as "complete", when, in-fact, same had not happened. What we're doing now is going back with a set of (Bash) scripts which extract all the element names from a 2.2 file, and all the element names from the 2.3 equivalent.
The two extractions can then be compared to discover name typos/errors. This has helped clear up several previously unnoticed issues, but is not yet quite complete.
Phil Davis seems pretty involved to me, and quite willing to lean-in and lend a hand.
You've fixed a plethora of (mostly smaller, but they all count to me) bugs, and I (we, really) thank you for that. I've said similar (about both you and Phil) out-loud to at least cmb during the past week.
This said, your abrasive manner (and yes, I know that I'm abrasive, so this is very pot->kettle->black) means you also get dismissed as just being angry.
You don't need to know Python to work here. We actually employ more people in service and support roles than we do engineering. This is somewhat "by-design", since I prefer smaller teams of higher skilled workers to large teams of code monkeys.
I think pfSense will be better for the changes, especially in the change-over to pkg (.vs PBIs which were a mistake from the start). If you don't, we're not forcing you to upgrade.
If the project dies, you could always run that other … more orange one, or fork the smoldering remains and give it a go yourself.
You might find that it's a lot of fun being on the target of a seemingly endless stream hostility and criticism, where every effort to make a living is decried as money grubbing.
In any case, thank you for your continued efforts to make pfSense better.
-
What do I mean? I quit testing the 2.3 snapshots yet again after hitting a bug that - on a simple reordering of rules - wiped the complete ruleset on all interfaces. That was way over a month after the Redmine issue tracker started to get spammed by hundreds and hundreds of bugs introduced in the code.
You have a problem, guys: there are GUI coders which clearly do absolutely ZERO testing of the backend functionality. If it renders, ship it. This ain't a website, though. It needs to work properly as a firewall in the first place. The look and feel is secondary.
And - do NOT dare to blame this on the community. Absolutely absurd. This ain't even an alpha. You missed the internal testing phase. Should have remained internal for good couple more months before releasing this for public testing.
P.S. Ditching the PBI garbage is of course welcome. Should never have been used in the first place. Heck - updating the GUI is welcome as well. Now that you mention the "more orange one" – why make yourself look so unprofessional by publishing such terribly buggy code? What's the hurry here?
And - while here - FFS start documenting things as you go.. You mention the packages. When your "documentation" consists of a 8 years old file full of "needs to be documented" comments listing tons of disfunctional abandoned stuff and missing actually working one - what do you expect? I filed a bug about the state of the XSD schema that after someone filed another bug about a package where service cannot be stopped. Then I spent an hour grepping the code for what tag could be used to fix that, found a bunch of issues with the service handling code
Maintainers' documentation - grepping the PHP code for stuff that's actually usable. Sigh.
-
What do I mean? I quit testing the 2.3 snapshots yet again after hitting a bug that - on a simple reordering of rules - wiped the complete ruleset on all interfaces. That was way over a month after the Redmine issue tracker started to get spammed by hundreds and hundreds of bugs introduced in the code.
I believe the bug you refer to was fixed during the past week.
Until late in the past week, the bootstrap bugs were kept in a separate tracker, especially so the mainline wouldn't get spammed.
Did you not notice?We did just move all the bugs in the bootstrap tracker to the 'pfsense' tracker, because we're getting ready for BETA, and it's time.
You have a problem, guys: there are GUI coders which clearly do absolutely ZERO testing of the backend functionality. If it renders, ship it. This ain't a website, though. It needs to work properly as a firewall in the first place. The look and feel is secondary.
Agreed that the look and feel of the webGUI is secondary. Updating the look isn't the whole reason the work was done. The larger part is that the GUI code was an unmaintainable mess.
And - do NOT dare to blame this on the community. Absolutely absurd. This ain't even an alpha. You missed the internal testing phase. Should have remained internal for good couple more months before releasing this for public testing.
Since I'm paying the bills, I am the decider. You can blame me. I called for an alpha, and I'm currently lining up the ducks for a BETA.
(We'll go BETA when I have general internal consensus.)And I already leveled blame for the "it renders but doesn't work" at certain unnamed members of the community, and same is well-deserved. I will not retract.
P.S. Ditching the PBI garbage is of course welcome. Should never have been used in the first place. Heck - updating the GUI is welcome as well. Now that you mention the "more orange one" – why make yourself look so unprofessional by publishing such terribly buggy code? What's the hurry here?
And - while here - FFS start documenting things as you go.. You mention the packages. When your "documentation" consists of a 8 years old file full of "needs to be documented" comments listing tons of disfunctional abandoned stuff and missing actually working one - what do you expect? I filed a bug about the state of the XSD schema that after someone filed another bug about a package where service cannot be stopped. Then I spent an hour grepping the code for what tag could be used to fix that, found a bunch of issues with the service handling code
Maintainers' documentation - grepping the PHP code for stuff that's actually usable. Sigh.
Patches welcome, Jakub.
Or, you know, you could work here, and work on this type of thing 24x7 if you wish.
-
@jwt:
Patches welcome, Jakub.
I responded to this already on the bug. So, I filed a pissed off bug about state of documentation - and - the knee jerk reaction: we comtemplated removing it.
It just doesn't make sense to provide patches for similar things in an environment where documenting things ls considered vastly useless waste of time, where development documentation is unmaintained, and when it becomes ridiculously outdated, it gets removed. (Seen here, seen this with the custom package repo howto, seen this with other docs on the former dev wiki as well.) Outdated info removed -> problem gone?! There's definitely a pattern there.
As noted on the bug - people come, people go, know-how gone. Documentation should stay so that when someone new comes, months are not wasted unproductively. Unless you see a value in getting things properly documented - there's just no point in submitting patches. People need to get into a habit of documenting things "as they go". When it's not being done for years, fixing things like this takes ridiculous amount of time. Doing it for the sake of it being done and then leaving it as a bitrot again - what for?
@jwt:
Or, you know, you could work here, and work on this type of thing 24x7 if you wish.
Making people work 24/7 would probably be illegal even in the U.S. :P If you are serious about this, either some freelancer contract or whatever else could be worked out, however - as said above - doing things like this should be seen as something of value. Waste of your money and my time otherwise. (Would involve fair amount of paperwork both for me and you.)
-
@jwt:
Patches welcome, Jakub.
I responded to this already on the bug. So, I filed a pissed off bug about state of documentation - and - the knee jerk reaction: we comtemplated removing it.
Yes, I know. I was in Chris' office and actually made the half-jest suggestion that it just be removed. That file is, as you so bluntly stated, "a piece of pathetic, useless, unmaintained junk", "untouched since 2007". Entirely correct. Nobody has done anything with it for over half the lifetime of the project. Chris admitted that he didn't even know it existed.
And if Chris doesn't know about it, why keep it?
Had you filed a bug, "the XML tags used for packages are a black box, and need to be documented", rather than "pathetic, useless, unmaintained junk", and then pointed out that package.dtd hasn't been updated in 8 years, I think you might have found a more receptive response.
In any case, instead of removing it, we confirmed it as a bug, and Chris added, "it would be nice to update and fix." Perhaps you blanked on that in your ire at the suggestion that it just be removed.
Here you had won the battle, but then lost the ground gained. Like me, at times, you are your own worst enemy.
Twenty-seven years ago, I pointed out a set of severe flaws with things my group was working on to my boss. His response, "Jim, you always bring me problems. Bring me solutions." In that moment, I was enlightened. I'd just been challenged to fix things, and was being given the latitude to do things my way. I was a rock start at that job, and several after. So, a challenge, Jakub, lead from the front, or continue to engage the project like a REMF.
Try being a little less acetic, a little less hostile. I know it's fun to rant, I enjoy it too, it gets attention, but unless wielded carefully, it works against you. Try to tone it down some Dial it back, and bring solutions, or at least suggestions for solutions.
To address your response in part: Guys - you realize that if you rely on volunteers to maintain stuff, they need something to start with?
Point-in-fact, with the exception of a few people, we do not "rely on volunteers to maintain stuff". There are some volunteers who do. You, Phil Davis and Bill Meeks stand out, but it's 5am, and I'm still at work, and the list of people who contribute a lot has a length less than 10.
If you think packages are undocumented, try looking at wizards sometime. They're also black magic. They're also due for a re-write post 2.3.
It just doesn't make sense to provide patches for similar things in an environment where documenting things ls considered vastly useless waste of time, where development documentation is unmaintained, and when it becomes ridiculously outdated, it gets removed. (Seen here, seen this with the custom package repo howto, seen this with other docs on the former dev wiki as well.) Outdated info removed -> problem gone?! There's definitely a pattern there.
The question is, why document bad design when we can, instead, fix it? I also have some concern about providing every dumb fuck with a set of documentation: "make your own packages", "set-up your own package repo" when we don't have a clear policy on what is, and is not, "pfSense" and/or "supported". I don't want to take support calls on someone's abhorrent hack, and I don't want someone's abhorrent hack to end up as an "official package" when we haven't checked it, and have no way to maintain it.
One of the first things I did in 2012 was to cut out any package that had arrived with a binary for which we did not have source.
As noted on the bug - people come, people go, know-how gone. Documentation should stay so that when someone new comes, months are not wasted unproductively. Unless you see a value in getting things properly documented - there's just no point in submitting patches. People need to get into a habit of documenting things "as they go". When it's not being done for years, fixing things like this takes ridiculous amount of time. Doing it for the sake of it being done and then leaving it as a bitrot again - what for?
@jwt:
Or, you know, you could work here, and work on this type of thing 24x7 if you wish.
Making people work 24/7 would probably be illegal even in the U.S. :P
So we're clear (and yes, I saw the smiley), I invited you to work 24/7 if you wish. It's not a requirement. I nearly always give people the time off they ask for. In one infamous case that I'll not detail, I made someone take a full month. He thought he was being fired, and I was just forcing him to take a break that he otherwise would not take.
If you are serious about this, either some freelancer contract or whatever else could be worked out, however - as said above - doing things like this should be seen as something of value. Waste of your money and my time otherwise. (Would involve fair amount of paperwork both for me and you.)
My preference is employment, though I do have people on-contract.
I hadn't remembered that you're trained as a lawyer. This should be "fun". In the same way stabbing your eyes with forks is fun.
-
BTW, in response to And - while here - FFS start documenting things as you go..
(Needs to live in a different place, and could be improved, but you asked/accused.)
I'll also point out that we undertook the task of getting "the book" (pfSense: The Definitive Guide) into RTD format, mostly so it could be edited without the written-in-Java hot mess of Oxygen XML, and, therefore, hopefully, kept up to date.
-
@jwt:
To address your response in part: Guys - you realize that if you rely on volunteers to maintain stuff, they need something to start with?
Point-in-fact, with the exception of a few people, we do not "rely on volunteers to maintain stuff". There are some volunteers who do. You, Phil Davis and Bill Meeks stand out, but it's 5am, and I'm still at work, and the list of people who contribute a lot has a length less than 10.
Well, yes… so - considered why? There were some other people, like marcelloc, who did tons of work on packages, he then apparently got pissed off by the PBI supercrap and thrown in the towel until the thing gets replaced with something where you are not hitting bugs on every step.
Now, people are asking for packages here. For many things, they could easily write their own. Except that the whole damned thing is completely undocumented. Where do you point these people? Imagine you had a VM image ready for that. Start a VM, point your pfSense box to it, put in your own package, enjoy playing with that. When you think it's ready and useful for other people, do a PR and something will review and possibly merge it. There's this DTD documenting the tags, there's the sample package shipped with that that shows the tags in action, there's always raw PHP (or Python, or brainfuck :P) in case the XML cannot do what you need, and run
pkg install pfsense-devel-manpages
to get pfSense-specific code docs.That would be something to get people started. When you tell them "observe the blackbox in action, grep through the code and after a couple of months you'll get a grip of basics", well - shockingly that doesn't work very well.
@jwt:
If you think packages are undocumented, try looking at wizards sometime. They're also black magic. They're also due for a re-write post 2.3.
Actually, some crazy guy recycled that wizard stuff for a package (the TinyDNS thing. I've seen it and have takes a hard pass on that. So yes - when you do not document things when you write them, you are doomed. Often faster to rewrite the code from scratch than investigate how the heck is that damned thing actually working. And hey, the thing being extensible makes it sexy, not the other way round.
@jwt:
The question is, why document bad design when we can, instead, fix it?
But you still don't document the fixed stuff either…
@jwt:
I also have some concern about providing every dumb fuck with a set of documentation: "make your own packages", "set-up your own package repo" when we don't have a clear policy on what is, and is not, "pfSense" and/or "supported". I don't want to take support calls on someone's abhorrent hack
Why not? You charge the people for that, you get the money - so when they broke it themselves, they pay for it eventually - to you. Charging them $$$ for pointing out their broken modification doesn't sound bad to me. You can always offer them to rewrite their abhorrent hack in a proper way for more $$$s.
@jwt:
and I don't want someone's abhorrent hack to end up as an "official package" when we haven't checked it, and have no way to maintain it.
Well yes, then improve the code review before merging. :)
-
marcelloc was one of the people who's name I couldn't remember (above).
There is no money in bespoke engineering.
-
This thread started off about 2FA!
You guys have been having so much fun that I couldn't resist joining in ;)
My main focus at the moment is to prevent crud bugs from being released in 2.3. I think that all the crud bugs are out of 2.2.* - ones where there are simple typos in var names and all that sort of crud that would never happen in the first place in a decent declarative programming language with compiler (or parser) that would tell you straight-up that you had fat fingers.Well yes, then improve the code review before merging
This
It was "unfortunate" that a huge block of code "inherited" from a medium-length development effort in another repo got committed with so many of these crud bugs in it. I have worked on other projects as an integration officer, being delivered code from side-development efforts that ran for 6 months, 1 year… without keeping properly integrated with the mainline code development. There are thousands of lines of conflicts. There are whole chunks of code that just do not work any more because the mainline has been re-engineered in the meantime - auto-merge and conflict detection do not pick all that up. It takes loads of effort to review all the detail and sort it all out.
It all works much better if the people/staff on the side development effort understand the integrating/merging needs and the importance of not missing out on correctly merging bug-fixes from the mainline. And if those controlling the mainline have good communication with the side development effort. And if there is almost-continuous-integration.Anyway, it is too late for all that now. The job is to find all the remaining crud bugs and correct them.
On the Python thing - it feels like I get a new language to learn every 6 months. Actually it takes maybe 30 minutes to find out how to do "if", "for", "while", "switch", put ";" on the end of statements or something else or nothing, name a var, call a function... The longer learning is to look through the list of "standard functions" provided with the language. At first you tend to just go looking for ones that do jobs you were used to doing in some other language. But actually there might be (good) new ways of doing things - and for that you need to scan through the whole list of functions and noting ones that look new and interesting to use one day.
And you two protagonists, you need to practice deleting superfluous adjectives before posting. @doktornotor if the existing code is crap we can all see that (its out there in public) and don't need to be reminded over and over. It won't help the person who contributed it to see those sort of adjectives. Much better to try and force yourself to tone down the language.
Documentation - not too many people who love writing it. I don't mind reviewing it, but hate writing it from scratch. At this particular point in the development cycle I think there is not much point trying to reverse-engineer and document some old stuff that should go in the bin. It might be better to re-engineer stuff (stuff that supports packages, wizards...) and document it as it is done.
-
thanks for your input.
-
any recent thought on 2FA ?
-
-
development by copy-paste chaos
Also known as full stack
overflowdevelopment.