[nSLUG] Perl, new website and such ...
fpicabia at gmail.com
Wed Jun 5 07:23:48 ADT 2013
On Tue, Jun 4, 2013 at 6:25 PM, Ben Armstrong
<synrg at sanctuary.nslug.ns.ca> wrote:
> Speaking of Perl, the reason we ran out of disk space, bringing the
> mailing list down, was the Innodb database file for the broken Mediawiki
> that ran our site grew to engulf the entire disk (30G of the 39G we have
> on our VPS slice!) Since I knew that was full of mostly spam, and we
> have an older, clean dump of the database anyway, for the small amount
> of good material we could salvage from it, I just threw out mysql and
> mediawiki entirely. In place of that is a stub page built from Ikiwiki
> (that's where the Perl comes in).
> Prepared to be underwhelmed. Here's the site so far ...
> Now, I never did want to be the person who "owns" this project, which is
> why I put it off for so long, so I'm looking for one or more apprentices
> interested in its care and feeding. We need to give the site some actual
> content (the old database could be a starting point for that, or else we
> could just start over from scratch). Give me a shout if this kind of
> work interests you.
Mediawiki is a spam magnet out of the box. I don't know why they continue to
release it that way. For those who have not encountered the problem...
There are many ways a mediawiki site can have content added to it which
will not appear on normal navigation of the site. This content typically
appears on special pages, which might show with the random page or search,
or in the multiple nooks and crannies of mediawiki. The spammers do not want
to deface your site. They want you to continue hosting their junk, which
is only there to increase page rankings in search engines (more links
to their sites, search engines increase the importance ranking of the linked
target). The spammers find such open mediawikis and blast it
with updates, overwriting the efforts of each other, and filling
the system's database. It can also create a high system load.
mediawiki is not designed as a CMS nor to be secure.
NSLUG's website is mainly static isn't it? Why bother with a
CMS/wiki at all? Any wiki seems to be like having
multiple keys left under multiple welcome mats - the problem
is, that was not a mistake, that is the spirit of the original design.
I'd think the only page needing common updates is
the monthly meeting time. This could be handled
with a .shtml inclusion and a text file containing the meeting
date and any other announcements. sftp the text file
once a month and you're done.
More information about the nSLUG