Eventual forum upgrade plan

Gocom · 2013-11-05 10:45:50

philwareham wrote:

So what are you saying, you want to now scrap FluxBB and all the hours of work we have put into theming it?

It’s not like we would start from square one. But maintaining FluxBB can become a pain. Each release I will have to re-patch it, unless someone else wants to.

Besides, punBB future development is pretty much dead at this point (one developer working on it, occasionally) – nearly 2 years since last release. So don’t expect more of those nice features to appear any time soon.

Sure, but I wouldn’t make raw commit activity a real measurement. FluxBB’s commits consist of fixes to issues that have never gotten to PunBB. It would be nice if PunBB’s development was active and they didn’t write commit messages in Russian, but its pretty hard to commit tons of fixes, when there is nothing to fix or reported as an issue.

PunBB guys either fixed XSS issues when they backported from FluxBB, or FluxBB somehow got rid of sanitisation, or forked from point before sanitiation was added. This file has XSS vulnerabilities, this one doesn’t. PunBB 2008, FluxBB 2010. Or salting; PunBB salted passwords in 2008, while FluxBB uses raw sha1.

These all are probably because of FluxBB forking from old branch and never backported these changes, but these aren’t necessarily a good sign.

philwareham · 2013-11-05 11:19:02

I understand your concerns, but I’d still like to wait and see where development goes on both before potentially jumping ship. FluxBB is good enough for right now – not perfect by any stretch of the imagination, but that’s just the way it is.

ruud · 2013-11-05 19:29:57

A few years ago this forum used PunBB. We switched to FluxBB because it was considered to be better then. Even security-wise, IIRC. Interesting to read that this has changed.

Btw. Thanks for the elaborate responses to the things I mentioned. Much appreciated.

colak · 2013-11-06 05:23:21

There’s another issue which is the mods to manage the database. Especially the User management one which helps us delete 1000s of (possibly bot registered) users/month (I just deleted 1800).

mrdale · 2013-11-06 06:11:12

I guess security is a critical issue with forums, since we’re all posting our credit card information in our signatures. Maybe we can find a system that has triple opt-in or one that salt AND peppers passwords. I’d even opt for the dreaded Worcestershire option just to make sure. Our words are just THAT important.

Gocom · 2013-11-06 06:30:25

Those that are affect by rainbow tables, also use the same password for other services.

Last edited by Gocom (2013-11-06 06:33:16)

Gocom · 2013-11-06 06:49:37

colak wrote:

There’s another issue which is the mods to manage the database. Especially the User management one which helps us delete 1000s of (possibly bot registered) users/month (I just deleted 1800).

We’ve written scripts that clear the database automatically. Both month old users that haven’t logged in, and spammers on the first login if they weren’t flagged and blocked during registration.

colak · 2013-11-06 06:53:28

Gocom wrote:

We’ve written scripts that clear the database automatically. Both month old users that haven’t logged in, and spammers on the first login if they weren’t flagged and blocked during registration.

Jukka, you’ll make the admin jobs redundant. I’ll call for a union meeting on you:)

Seriously now. I guess you mean “month old users that haven’t ~~logged in~~ posted anything.”

Gocom · 2013-11-06 07:15:22

colak wrote:

Seriously now. I guess you mean “month old users that haven’t ~~logged in~~ posted anything.”

I mean logged in; we can’t just go killing off random lurker accounts that are in use. Removing someones account without any reason will offend the user. For instance, I registered July 2006, but I did my second post over a year later; in July 2007. During 2006 I only posted a single link.

I hope you neither are deleting random accounts that haven’t posted anything, but only those that have never logged in or are actually clearly spammers.

I may later on add more clean up rules, but they will be very strict about what they do remove. E.g. no posts, two years without log in and found on SFS database. Stop Forum Spam can easily contain false records, so its information must be taken with a grain of salt.

philwareham · 2013-11-06 08:05:07

I’m nearly done at my end. Just got to apply some IE8 fixes, browser test a bit more and squash any glitches that I find. Any other changes can be done post launch, once we start looking at the other brand sites.

So we just need a deployment strategy now.

els · 2013-11-06 08:15:54

colak wrote:

Jukka, you’ll make the admin jobs redundant. I’ll call for a union meeting on you:)

Dammit. Let’s go on strike, Yiannis!

Gocom · 2013-11-06 08:37:34

philwareham wrote:

So we just need a deployment strategy now.

We have two options;

The server pulls in the data itself.
Or we have build server that then rsync the files.

If we do on the server itself, we will have to install the passive build requirements to the server; git, Node.js, Ruby and Bundler, and either pre-deploy Ruby gems, or use an account that can write gems without having to sudo. Same of course goes for any staging/build server.

That reminds me, Phil, Gemfile shouldn’t be modified unless very much necessary — unlike node modules and composer packages, gems aren’t local to the project. When you update the Gemfile you are altering everyone’s whole system, and requiring that users run manual build tasks as sudo. Modifying package.json and composer.json is whatever, Gemfiles preferably once a year.

For Textpattern websites we can’t not use syncing since plugins and templates are in the freaking DB. We will actually have to change data; either pull out the database and send it back in, or update it locally in temporary database.

I’m probably going to write some sort of script that can be hooked on post-commit, and run pull + rsync, which would mean it can be used both locally and remotely. Probably as a two step process so that you don’t have to give Apache access to git, Node and such.

push <--> git --> post-hook receiver: log commit if tagged release
timed build-tool --> checks log: if new commit --> build --> deploy

Or it could just be timed and directly check the git server.

Last edited by Gocom (2013-11-06 08:54:34)

wet · 2013-11-06 08:52:49

[forum@textpattern ~]$ which git ruby node bundler gem 
/opt/local/bin/git
/opt/local/bin/ruby
/usr/bin/node
no bundler in /opt/local/bin [...]
no gem in /opt/local/bin /opt/local/sbin [...]
[forum@textpattern ~]$ pkgin avail | grep rubygems
ruby18-rubygems-1.8.24 Ruby standard for publishing and managing third party libraries
ruby19-rubygems-1.8.24 Ruby standard for publishing and managing third party libraries
[forum@textpattern ~]$ pkgin avail | grep bundler
ruby18-bundler-1.1.4 Manage your application's dependencies
ruby19-bundler-1.1.4 Manage your application's dependencies
ruby193-bundler-1.1.4 Manage your application's dependencies

Gocom · 2013-11-06 09:02:51

This means the dependencies can be installed on the server? Cool. Means we can deploy within the same user land. For the forum simple shell script should work wonders that runs just the install commands.

colak · 2013-11-06 09:03:32

Gocom wrote:

I mean logged in; we can’t just go killing off random lurker accounts that are in use. Removing someones account without any reason will offend the user. For instance, I registered July 2006, but I did my second post over a year later; in July 2007. During 2006 I only posted a single link.

I hope you neither are deleting random accounts that haven’t posted anything, but only those that have never logged in or are actually clearly spammers.

I may later on add more clean up rules, but they will be very strict about what they do remove. E.g. no posts, two years without log in and found on SFS database. Stop Forum Spam can easily contain false records, so its information must be taken with a grain of salt.

currently we are deleting through a monthly click of a button, all users who registered but not verified their email within a month and all verified users who – within a month – still have zero posts. This keeps the users db kind of manageable. Most ‘cleaning’ happens to verified accounts with zero posts. Today, out of the 1800, 1600 were those. I updated the rules of the forum to warn people of that. Any user with at least one legit post remains in the db.

Textpattern CMS

Textpattern CMS support forum

#91 2013-11-05 10:45:50

Re: Eventual forum upgrade plan

#92 2013-11-05 11:19:02

Re: Eventual forum upgrade plan

#93 2013-11-05 19:29:57

Re: Eventual forum upgrade plan

#94 2013-11-06 05:23:21

Re: Eventual forum upgrade plan

#95 2013-11-06 06:11:12

Re: Eventual forum upgrade plan

#96 2013-11-06 06:30:25

Re: Eventual forum upgrade plan

#97 2013-11-06 06:49:37

Re: Eventual forum upgrade plan

#98 2013-11-06 06:53:28

Re: Eventual forum upgrade plan

#99 2013-11-06 07:15:22

Re: Eventual forum upgrade plan

#100 2013-11-06 08:05:07

Re: Eventual forum upgrade plan

#101 2013-11-06 08:15:54

Re: Eventual forum upgrade plan

#102 2013-11-06 08:37:34

Re: Eventual forum upgrade plan

#103 2013-11-06 08:52:49

Re: Eventual forum upgrade plan

#104 2013-11-06 09:02:51

Re: Eventual forum upgrade plan

#105 2013-11-06 09:03:32

Re: Eventual forum upgrade plan

Board footer