VaultWiki News

Earlier in the week we were alerted to a possible security issue in all Premium versions of the VaultWiki 3 series, in which an admin could accidentally grant regular users AdminCP access. VaultWiki 3.0.16 patches this issue by displaying an error message if an admin "attempts" to do this, and by rolling back any users it deems to have been affected. It also fixes a small number of cross-browser compatibility issues.

For users who have expired licenses, Patch Level releases are available for versions released in the past year:

• 3.0.15 Patch Level 1
• 3.0.14 Patch Level 1
• 3.0.13 Patch Level 1
• 3.0.12 Patch Level 1
• 3.0.11 Patch Level 2
• 3.0.10 Patch Level 2
• 3.0.9 Patch Level 2

For all these patch releases, we strongly recommend running the bundled upgrade script in order to correct any errors. This is a necessary security fix that will ensure all of your forums stay safe and secure. We apologize for any inconvenience this may have caused.

Back in January 2010, we began the transition of moving VaultWiki from our parent company's site (Cracked Egg Studios LLC) to its new home here at VaultWiki.org.

We left redirects in place for 6 months, so that new users would be redirected to the correct place. We left user records users in the old database in case some customers missed news of the move and logged in at the old site, so that they didn't have a scare that their account no longer existed.

However, it is now over 18 months since we changed domains, and it doesn't appear like any existing (active) customers are unaware. So as of today, we have gone ahead and removed any user accounts from the old site database, provided:

• The user had not logged into the old site during 2011, AND
• The user had not joined the old site prior to 2007, AND
• The user had not joined the old site after January 5, 2010, AND
• Either:
  
  • The user had not joined the old site prior to June 17, 2008, OR
  • We recognized the username from a separate forum owned by NuHit, LLC.
• UNLESS the user was recognized as a non-VaultWiki customer, or had made significant contributions to non-VaultWiki sections of the old site.

How does this change affect you?

Accounts existing on VaultWiki.org, including those that were transferred from the old database last year, are unaffected. All VaultWiki licenses will continue to be honored here.

However, if you joined or purchased your VaultWiki license on the old web site at http://www.crackedeggstudios.com and your account met the criteria outlined above, you should no longer receive email or other correspondence from that web site. Your account there no longer exists. Should you still be interested in that site, feel free to visit and create a new account.

It has come to our attention that a large portion of our customer base has been unable to download the newest version of VaultWiki, 3.0.12. The reason for this is probably that the last update was in February, so any customers with March - May license expirations may have let their access to new updates lapse.

However, 3.0.11 and all earlier versions contained a security vulnerability, so it is irresponsible on our part if we don't provide these users any way to patch their installations.

Therefore, as of today, we have provided patches for VaultWiki versions between 3.0.1 and 3.0.11.

If your license was active at any time in the past year, you can download one of these patches from the Members Area: https://www.vaultwiki.org/members/

Details and Policy Changes

Creating patches for old versions has required both an upgrade to our Members Area and backend software, as well as an update to the License Agreement, which neglected to mention security patches or End-of-Life situations.

https://www.vaultwiki.org/pages/Info:License-Agreement

In the past, it was our policy to only update the most recent version in all "live" branches of VaultWiki with security updates. However, since 2.5.x has been End of Life for over 6 months, there is only 1 branch like this. Furthermore, this doesn't protect customers with expired licenses, who may intend on fully upgrading later, but for now just want to be safe.

Now, we will provide security updates to ALL live, stable versions.

A live version is a version that has not reached End-of-Life. Any version that is more than 1 year old is considered End-of-Life. A stable version is any non-Patch Level (PL) release that isn't an Alpha, Beta, or Release Candidate.

As currently, to protect our customers by preventing them from accidentally downloading vulnerable releases, vulnerable versions will still be removed from the download area. However, due to the aforementioned changes, versions released in the past year would be replaced with a PL release.

This change applies retroactively to all versions released in the past year.

Late last week we discovered a security vulnerability in all versions of VaultWiki up to and including 3.0.11, but not including VaultWiki Lite. Over the weekend we released 3.0.12 to correct this issue and sent out an email to our customers advising them of the issue and recommending that they upgrade.

VaultWiki 3.0.12 also contained a number of bug fixes and is the first release to be compatible with vBulletin 4.1.4 and its new ckEditor.

In the 5 days since 3.0.12's release, we have fixed a number of other editor-related bugs that occur under different site configurations. If you downloaded 3.0.12 earlier in the week to patch the security issue, we recommend downloading the updated build to correct any remaining compatibility issues.

Sub-Domain Support

As of 3.0.12, VaultWiki now has added support for placing the wiki at a sub-domain. Specifically, with an additional proxy file and updated an Rewrite-Rules generator, it is now easier than ever to configure VaultWiki in this way. You can even have URLs like: wiki.domain.com/Article_name

MediaWiki Syntax Support

We've further enhanced our MediaWiki import process and improved support for a number of MediaWiki markup tags. We've also added a GALLERY BB-Code in VaultWiki, which allows users to create a row of wiki image thumbnails without text wrapping around them.

GALLERY functions similarly to the normal IMAGE tag:

Beginning some time around last Friday, May 20, our server began encountering critical problems and the site became intermittently unavailable until the machine crashed completely.

What Happened

As it was a vacation weekend for many of us here, we were unaware of the issue almost until we returned on Monday, at which point we contacted the WiredTree data-center to have them investigate.

First indications were of a runaway cron job, because memory usage rose to 100% before the server first went down. However, after a day of this not panning out, we soon encountered another problem. Even after each server reboot, we were unable to log into WHM or cPanel to administer the server because "400 attempts to create a session failed". We were even unable to make any changes to the server via SSH, which gave a more informative message: "read-only file system."

Apparently a read-only file system occurs when there is a serious problem with I/O to the hard drive, and the file system becomes read-only to protect the data from damage. The people at the data-center swapped out and cloned the hard-drive to no avail; it wasn't until the motherboard was replaced that the server returned to normal. The onboard SATA controller had essentially failed.

What We Did Afterwards

Even though the problem was a faulty controller that probably swallowed up all the memory by queuing file updates until the queue used up all available memory, we still didn't like that memory was used up at all.

We went on a spree of updating server software, two of which (PHP 5.3.6 and XCache 1.3.2) corrected memory leak situations in previous iterations. The PHP memory leak was actually likely to occur in a vBulletin forum installation like we have here. While the site was down, we also went ahead and updated MySQL to 5.5 to receive the reported performance benefits.

What This Means for the Future

The site was down for an extended period of time and during that time all services were unavailable. We apologize for that. However, the issue was largely out of our hands (hardware failure) and as far as we can tell it was not due to any malicious attack by a third party.

If anything like this occurs again in the future (and with computers, we all know it eventually does), I assure you, we will be back. This event has caused us to set up additional measures to protect some services so that we can alert visitors and customers to the problem while it's happening.

As this took most of our attention, almost no work was done on VaultWiki development during that time. Therefore, we are about a week behind schedule, but are back to work already today.

Well, for a few hours there, I didn't think we'd make it through April Fools' Day with a working new site, but here we are. On to the juicy bits, what's changed, what's new, where we're going from here, and how a bunch of it almost didn't happen.

New Server Location

As I mentioned in the previous article, last month we reached the limits of what our shared hosting account could provide. I had been watching our resource usage for almost a year, crossing my fingers that the server admins wouldn't notice. When we were unable to handle a substantial number of our existing customers being online all at once during day 1 of the last patch release, it became obvious it was time to look for something new.

So we made the substantial monetary investment, and got ourselves a dedicated server. We spent weeks settings it up and making sure the site had all the same functionality as before. And while we were just twiddling our thumbs waiting for April 1 to launch, we received the long-feared notice from our old host that we were in fact consistently using almost twice as many resources as we were alotted.

NginX

When I had originally read on forums about NginX, I always thought it was pronounced "In ginks." Not until I bothered getting a box running with it myself did I learn it was intended to be pronounced "Engine X." We have completely eliminated Apache from the equation and use NginX to deliver content with almost the same speed that we had been getting with our Content Delivery Network. With all of our tweaking, pages that at best were processed in 280 milliseconds on our old server are now being processed sometimes less than 100 milliseconds.

When it came time to launch today, however, the URL rewrites that had been working fine in our tests all last month no longer worked once we switched the DNS to point to our new server. It took a while before I figured out how to get NginX working with vBSEO and our custom rewrites, since the instructions with vBSEO are insufficient for all but the simplest setups. For those interested, you can't use try_files, and you need to manually set REDIRECT_URL before handing off the request to vBSEO.

New Look

We have changed the default style of the site to something we feel is much cleaner and fits the theme we are pushing with the impending VaultWiki 4 - getting outside the box. There's still some cleanup still to be done with the style, but I think it's already better than the stock vB style.

Of course, customers can use the Style Chooser in the site footer if they want to see how VaultWiki will look on an unmodified style.

We've spent a lot of time trying to reduce latency by using CSS sprites, and we've redesigned the Members Area (yet again) to make it more useful.

Vastly Improved Security

We've been planning this one for over a year - getting an SSL certificate from a trusted authority, allowing the connection between us and our customers to be encrypted.

It had long bothered me that we offered an installation service where we requested user login information, and this information was being transmitted over an "insecure" connection. Now I can rest easy.

Another significant investment that shows you we are a real company that cares about the integrity of our products and services.

Upcoming Changes

While we will now be focusing fully on developing VaultWiki 4 until the Alpha 1 release next week, here's what else we're planning for the next month.

With the SSL certificate, we'll be able to add more payment options. First up are Google Checkout and Amazon Payments.

We'll be adding a new section to Support very soon for issues and requests related to the functionality of this site. Currently these items are sprinkled throughout forums or the VaultWiki milestones, making it difficult to keep track of these particular items.

For now, Site Support items can be placed in the new (temporary) forum. If you run into ANY issues with the new site, please post them there.

In closing, I'd like to say a few words about the title. I couldn't figure out what version of the site this would be. While it's our second VaultWiki "dedicated" server, it's really the third site move for VaultWiki, and the fourth redesign / restructuring of a VaultWiki site. With all this confusion, and us using NginX, I'm satisfied with version X.