WikiFur:Moving hosts

From WikiFur, the furry encyclopedia.
Revision as of 05:25, 9 February 2013 by GreenReaper (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search
This page relates to the move to en.wikifur.com. It is preserved for historical interest.
WikiFur is moving hosts in the near future. This page explains why, and explores the various options available to us.

Summary[edit]

Since its creation in July 2005, WikiFur has been hosted on Wikia, a full-service wiki hosting provider, or wiki farm.

Wikia is not a charity. It is a for-profit company funded by venture capital. This has many positive aspects - not least the high performance and availability of WikiFur to date. However, over time, the negative effects have become more evident.

On Friday 6 June 2008, Wikia announced that it would be enforcing a new default skin (Monaco) with significantly increased advertising, some of which would intrude into the content area (in the top-right position normally occupied by a picture or infobox). Users would still be able use other skins by logging in and selecting them in their preferences, but administrators could not select a non-Monaco default for users. They have also discarded a promise made before WikiFur's arrival to never host popup ads (this change was reverted after further discussion).

We believe that this new style and level of advertising negatively impacts our readers to an unacceptable level. We also feel that Wikia is asserting an inappropriate level of ownership over the wikis for which it provides services. They have indicated that they want a more cohesive community of wiki sites than we do. These differences of opinion and needs are not likely to be resolved.

WikiFur is not the only site to have problems with this - it has been the subject of much discussion. Members of Wookieepedia (the Star Wars Wiki) and Teletraan-1 (the Transformers wiki) have come to the conclusion that they need a "plan B". We concur, and intend to use it as soon as possible.

Administrative support for above statement[edit]

Support
  • I'm GreenReaper, and I approve this message. --GreenReaper(talk) 20:07, 14 June 2008 (UTC)
  • Agreed. Moving not only frees us from the reigns of Wikia, but opens up numerous new opportunities for WikiFur as a whole. --— beeps (talk, contribs) 21:10, 14 June 2008 (UTC)
  • Agreed. I think that a move would help us grow and is in our long-term best interests. --Douglas Muth 21:53, 14 June 2008 (UTC)
  • With Wikia's intent now clear, both in their desire to increase monetization by advertising alone rather than by sales of services, and in their desire to claim greater ownership over member wikis, I feel that WikiFur will be best served by moving to an independent host. -- Siege(talk) 15:10, 15 June 2008 (UTC)
  • I also am strongly in support. -- Sine 01:31, 16 June 2008 (UTC)
  • I agree. Establishing independence from this sort of money-grubbing is definitely in WikiFur's long-term interest, especially if Wikia's changes lead to attempts at editorial control - a definite no-no for a wiki. Carl Fox 03:13, 16 June 2008 (UTC)
  • I support a move. I dislike pop-ups. I looked at the wikia's communitytest of the Monaco and while I think I could handle one of the Google ad boxes, a double-dose of Google ads at the top of every page looks like it would be ad-heavy. --EarthFurst 04:01, 16 June 2008 (UTC)
  • Unfortunately, it looks like Wikia won't compromise in its decision so it's necessary to find a new host. --Rat 07:30, 16 June 2008 (UTC)
  • I'm going out to get boxes and parcel tape, pop-ups are just unacceptable and moving to a new server is quite feasible. --Nidonocu - talk Nidonocu 13:22, 16 June 2008 (UTC)
  • Not giving a choice to the customer (us) means not caring about them. Also, pop-ups make me cringe! Either point is enough for me to want to move. • Ekevu • 14:16, 16 June 2008 (UTC)
  • I agree Spirou 02:21, 17 June 2008 (UTC)
  • I concur with the reasons stated for finding a new host. It's been good with Wikia so far, but I don't like where they are heading. --mwalimu 21:30, 17 June 2008 (UTC)
  • I support the move - finding a new host does seem to be in the best interests of WikiFur's future.--Higgs Raccoon 20:54, 18 June 2008 (UTC)
Neutral
  • I've always been a fan of the wikia style, and look at the pros and cons of the move, I'll just wait and see what happens afterwords. --Shadow-Fox Kakuretsin 07:56, 30 June 2008 (UTC)
    Not an admin, but point noted. To clarify: we do like skin options - we don't like having them forced on our readers. The issue was that the skin change was partly driven by Wikia's requirements for branding and advertising, and was not presented as optional. --GreenReaper(talk) 08:05, 30 July 2008 (UTC)
    It's not as much as that as that, but even though this is a large database, the cons almost seem to outweigh the pros. --Shadow-Fox Kakuretsin 08:26, 30 July 2008 (UTC)
    There are downsides, but we can cope. Hopefully once you see the performance and features of the new server, you'll appreciate the pros. :-) --GreenReaper(talk) 04:46, 1 August 2008 (UTC)
Oppose
Recuse
  • Currently working for Wikia -- JSharp (talk) <staff /> 04:17, 19 June 2008 (UTC)

Things to consider[edit]

  • Wikia may still maintain a site at furry.wikia.com. This is up to them - the GFDL permits it, although certain images uploaded under different licenses (or none) might not be available for their use.
    • For this reason, please immediately change links to use en.wikifur.com rather than furry.wikia.com. The new domain will work both before and after the move.
  • GreenReaper has control over the WikiFur service mark, therefore our site will be using it and Wikia will not.
  • A full database backup (not just the XML) and image backup should be available to us. User login details may be available.

Current status[edit]

Our images currently occupy 1.4GiB of space. The database page table can be compressed if necessary and in that case should take up less than 100MB. Allowing for reasonable expansion over the next year, we will be at 2GiB.

Our total bandwidth use is hard to calculate, but we use about 50GiB a month in CSS and HTML transfer alone. It is not unrealistic to suggest that our total usage might be three times this after images.

Comparison of options[edit]

During the administrative discussion, several options were proposed.

Some options that were quickly dismissed:

  • Wikia has indicated that while they might consider an offer of money for hosting, it does not really fit into their business model. WikiFur's administrators felt it would not work on a long-term basis.
  • Other wiki farms were ignored, as we do not believe they will offer a sufficient level of service to justify the additional cost.

Shared hosting (NearlyFreeSpeech.net)[edit]

NearlyFreeSpeech.net is a shared hosting provider with load-balancing. They provide Linux, PHP 5 and MySQL. They host Anthrocon's website (and GreenReaper's personal site).

Pros
  • We only pay for what we use - no more, no less
  • Integrated rsync.net option for a low price with no transfer costs
  • Should provide good availability and probably sufficient performance
  • Competent techs willing to "go the extra mile" for the right people (as certified by Giza)
Cons
  • The costs provide a disincentive to grow our audience and our site:
    • The cost of bandwidth, while great for small sites, becomes uncompetitive quite quickly, even with the long-term bandwith discount
    • Storage costs are high - $10.00 per GiB/month. No bulk discounts (yet).
  • Limited control over the environment. We can run CGI scripts manually (remote triggered), and there is ssh and [S]FTP, but we can't add or configure OS-level modules ourselves.
  • No ability to run most others kind of servers (no static IP).
  • No memcached (in-memory object caching daemon), which could severely limit MediaWiki performance
Estimated cost
  • Storage: 2.0 * $10.00 * 12 = $240
  • Bandwidth: 150 GiB * 12 = 1800 GiB, which will cost $479.82. The subsequent year would be $407.12.
  • MySQL: ($0.01 [base process] + $0.01 [InnoDB table support]) * 365 = $7.30
  • Backup: 2.0 * $1.40 * 12 = $33.60 (optional)
  • Total: $760.72 for the first year, with backup (varies significantly depending on accurate estimate of bandwidth usage)

Virtual server (Linode.com)[edit]

Linode offers Linux virtual servers occupying high-powered machines (quad-core Intel Xeons with RAID-1 disk mirroring), with a certain dedicated amount of memory, storage and bandwidth, and a guaranteed (small) percentage of the real computer's CPU which may increase if other sites are not using their share.

Pros
  • Even the smallest plan should have sufficient storage for us
  • Location would likely be in New Jersey, a good compromise for American and worldwide furs.
  • Real IP address, real server inasmuch as we can run what we like on it, full control.
Cons
  • MediaWiki can be rather CPU-expensive as an application, and may also strain the memory. We are already close to the limits of the lowest plan. We can buy more RAM and bandwidth, but that will also cost more.
  • We would have to provide our own server administrator and spend more time running the server - time we could be spending improving or promoting the wiki.
Estimated cost
  • 360 plan (max sharing: 40, 360MiB RAM, 12/18GiB storage, 200 GiB/month bandwidth: $19.95 * 12 = $239.40 a year
  • 540 plan (max sharing: 30, 540MiB RAM, 18/27GiB storage, 300 GiB/month bandwidth: $29.95 * 12 = $359.40 a year

Use of dedicated server (Timduru)[edit]

Timduru (our French WikiFur administrator) has offered the use of his dedicated US server (Conroe 3040 dual-core, 2GB RAM, 750GB+500GB HD, 3TB/month, ~1.8TB free - FreeBSD 7.0) hosted at ThePlanet in Texas. This is the same one that hosts a number of fursuit-related sites (e.g. The Fursuit Archive, The Fursuit Database). It is also a streaming server for the Funday PawPet Show and FursuitTV.

Pros
  • Low-latency, relatively high-bandwidth (40MBps+) connectivity with a monthly limit that we are unlikely to max out anytime soon.
  • Server facilities appear relatively unused despite the existing services. There's plenty of CPU and memory available, even during periods of streaming. Initial tests indicate performance would be very good.
  • Ability to run daemons as required by the site, and perhaps other servers. SSH access. Our own IP.
  • A server administrator who intimately understands both our needs and the server.
  • A backup to his French server can be provided, and potentially activated there in an emergency.
  • The price is unbeatable.
Cons
  • Timduru has been a server administrator for 10 years, but the people he has to rely on to fix problems have sometimes been less than fully competent. While the control situation is now improved (a remote KVM is installed) we would still have to act on any low-level problems via Timduru.
  • There is the potential for degraded network performance during periods of streaming. This does not actually appear to be the case but it is possible that this will occur as viewership continues to increase.
  • Timduru's server is primarily for supporting and promoting fursuiting within the fandom. If push came to shove, WikiFur would be the site to be shoved - gently, with a reasonable time to arrange alternative hosting. (This situation is considered "very unlikely", as increased supply of bandwidth/storage/etc. has outpaced demand in recent years.)
Estimated cost
  • Nothing, unless we required services with a specific cost. However, as a significant user, we might well chip in now and then, and/or direct user donations to help cover yearly costs, which are currently in the $2000-3000 range.

Vote[edit]

This vote is now closed. A preference was expressed for Option 3 (Timduru).

Please indicate your preference by adding your vote to this table. If you have no preference between two options, average your vote. For example, if you preferred one option above two others, vote 1 for the first, and 2.5 for the others.

  • This vote is of an advisory nature. If there is a clear preference for an option, it will be taken. If not, GreenReaper will make the final choice.
  • The vote is open to all users, but the votes of administrators may be given more weight.
Option 1 (NFSN) Option 2 (Linode) Option 3 (Timduru) Signature/comments
2 3 1 I believe that Timduru's solution is the most effective in our case. Linode - as documented - will likely have problems running the MediaWiki software and would require an administrator to be available in the area in case something does go awry. NFS is not only expensive, but limited in it's application and control we have over the operating environment. Meanwhile, Timduru's option has the least severe "cons", while we can be assured that the interests of Timduru and WikiFur are aligned and understandable. And hey, better the devil you know. — beeps (talk, contribs) 21:11, 14 June 2008 (UTC)
1 3 2 I feel that NFSN is a good First Step, as it is easy to get started and they have a robust environment. If they fail to meet our needs, then Timduru would be the next best, due to cost (free) and the fact that there is already a server admin. --Douglas Muth 21:57, 14 June 2008 (UTC)
1.5 3 1.5 While I feel that Timduru may be our best option, I also feel that Mr. Muth has made a good case for NFSN. Linode is good for monetary cost, but needing our own server admin is an incidental cost we might not be able to afford right away. -- Siege(talk) 15:36, 15 June 2008 (UTC)
2 3 1 I'm quite sceptical about vhost providers. They often don't scale well. Mediawiki without shell access can be quite a PITA for certain admin tasks, thus I'm not conviced that NFSN suits us. Timduru, though, is a very reliable and experienced system administrator. o'wolf 15:58, 15 June 2008 (UTC)
Actually, NFSN does make shells available to their customers. --Douglas Muth 14:30, 16 June 2008 (UTC)
3 1.5 1.5 Timduru: NFSN infrastructure sounds interesting, and based on other sites hosted there it sounds like a good option, it is quite costly though. The main points that worries me about them is that as written in their FAQ, they don't allow processes to run for more than 2 to 5 minutes for shell and 3 minutes for php. Mediawiki maintenance scripts and import / export processes will take more time than that to complete, and we will need to run them on a regular basis. The initial xml import took more than 2.5 hours to complete on my server. Even if we get a DB export, that'll take more than 2 minutes to complete I think. The other aspect written in their FAQ is that it seems they don't expect you to use a lot of ressource as you would do on a dedicated server, otherwise they might cancel your hosting. If these 2 points could be cleared with them so that we are sure we can run a heavy mediawiki there, I think their redundant servers would be better than mine. About Linode it's difficult to know what power we would get, but based on the server specs it might be enough. The good point would be that we have full access to the server too. --Timduru 17:53, 15 June 2008 (UTC)
2 3 1 Unless something really cool pops up re: NFSN, I would be inclined to go with the resource we're more familiar with.  :) Carl Fox 03:23, 16 June 2008 (UTC)
1.5 1.5 3 I haven't got a detailed understanding of the technical requirements, so I won't try to figure out what would be better between NearlyFreeSpeech and Linode. I am uncomfortable with the scenario of being hosted as a favour. Sine 04:55, 16 June 2008 (UTC)
3 2 1 We're going to need a server admin no matter which we pick, so we may as well pick one familiar with the server. Rat 07:30, 16 June 2008 (UTC)
2 3 1 As per Rat's comments. Also, I agree with o'wolf as in virtual servers don't scale well; they're meant for starting up, which isn't our case. • Ekevu • 14:13, 16 June 2008 (UTC)
2 1 3 I don't really like any of the options presented, but the option for a dedicated server is the one I dislike the least. The first option isn't bad either, but discouraging the growth of the site is probably a bad idea. And, with all due respect to Timduru, hosting something like Wikifur on someone's personal server, with a single admin, is a very bad idea. This is why I didn't offer my hosting services, and I even have active staff besides myself, with more system resources than Timduru's quoted specs. Natasha Softpaw 23:42, 16 June 2008 (UTC)
0 0 0 Abstain. I will leave the final decision about this matter to more knowledgeable Admins. I can't bring anything to this discussion at present time Spirou 02:21, 17 June 2008 (UTC)
2 2 2 Abstain. I've read and pondered the pros and cons for each choice, but I just don't have any experience in hosting and maintaining a large website, and I think the decision is best left to those with expert knowledge.--Higgs Raccoon 20:54, 18 June 2008 (UTC)
3 2 1 While I don't really know a whole lot about servers, the third option has the most advantages in it's favor. And the only thing that I worry about is server stress (streaming) as we continue to grow. This just seems to be the best option available right now. We do of course have the other two as backup options. --Markus(talk) 21:38, 18 June 2008 (UTC)
3 2 1 I agree with Markus, in fact I would write something very similar. -- Xkun(talk) 22:33, 18 June 2008 (UTC)
3 1 2 Well, I would essentially rule out NFSN due to the nature of their hosting platform. Reasons for this include: Very limited server access, no possibility to host other services in the future, no persistent processes (which means we'd have to run mediawiki as a pure CGI program, which is very very very slow), and no memcached or squid (which is absolutely needed for WikiFur with it's level of activity). This leaves Timduru's offer and Linode.
Now to address my perceived advantages of each: Timduru: cost and setup; Linode: control, scalability, and independence. Timdurus offer, while generous, could be subject to withdrawal for any number of reasons (personal, business, other projects, etc). Dependence on another party would also lessen WikiFur's independence in hosting new and interesting services, and in making configuration changes, or reacting quickly to attacks, and potentially in meeting community demand. However, given all of these limitations you can't beat the cost and currently available capacity, and the real world experience of the administrator.
Now for the Linode solution: Linode sells what are essentially computer slices (pieces of bandwidth, storage, memory, and compute time) in variable chunks. The downside to this is that we're limited potentially by the other users of that particular machine. The good news is that we're always guaranteed a certain proportion of time there, so we can't be crowded out and we can run whatever software we need. The bad news is that we also have to provide our own server administrator, setup, and maintenance. However, I don't think this is something we should worry about -- it just means we get to appoint and agree on who should help to run the server. I have previously volunteered to help engineer the move and server administration regardless of the final decision of where we move. Regardless of where we choose to move to, I will always be happy to donate my time and experience to making sure WikiFur always remains online. I believe that the best advantage this arrangement provides is total independence and no conflict of interest with regard to any content we might eventually host. The reason I think Linodes second advantage is scalability is that we can bring additional servers online to meet unexpected demand as we grow and turn them off as needed to save money on costs. I have been a Linode customer (for my personal server) for almost a year and a half now and have absolutely no complaints about their level of service (I stand to gain nothing from recommending them here). In fact, the owner hangs out in their IRC channel and helps out (they've helped me out with some exceedingly tricky setups before). To summarize, I would choose Linode as our primary hosting platform because it provides us with an upfront specification of costs with a guaranteed level of service,quick present support, easy expansion, and complete independence and flexibility. - JSharp (talk) <staff /> 04:17, 19 June 2008 (UTC)
31 31 22 A preference has been expressed. We shall implement Option 3 (Timduru), bearing in mind the concerns raised above. --GreenReaper(talk) 06:42, 19 June 2008 (UTC)

Plan of action[edit]

Hosting setup[edit]

Timduru will provide hosting for WikiFur on his server. The specifics of the hosting environment are subject to change at any time.

The initial server setup includes:

The server contains one 1.8GHz dual-core Intel processor; this should be more than sufficient for our needs if the above software is used correctly (when streaming, around 20% is used). 2GB RAM is available to the server. Disk space is not expected to be an issue.

Maximum server bandwidth is 3TB/month, of which over half is still available. In practice, we are unlikely to use more than a small fraction of this. The server has a 100MBit connection; usable bandwidth to the net is known to be above 30MBit/sec.

Emergency and backup provisions[edit]

Giza and RainRat have access to change the wikifur.com domain name in the case that GreenReaper is unavailable.

Regular backups will be taken, on at least a weekly basis, and made available for public download.

Transfer (provisional)[edit]

Wikia shall provide a complete database dump, containing all revisions of all articles (including deleted revisions), and copies of all images. It should be possible to use these backups to directly create a copy of the website.

Hosting agreement[edit]

In this agreement, the Host is Timduru, an individual currently residing in France; WikiSystemAdmins are GreenReaper, an individual currently residing in the United States of America, and potentially one other person; and WikiAdmins are those with regular wiki system account access and user-level database access (likely to be a small subset of WikiFur's administrators).

  • The Host agrees to provide a server environment on which MediaWiki can be hosted, an IP on which it can be accessed, and any server-level configuration necessary to ensure public access.
  • The Host agrees to provide trusted WikiAdmins access to the server on a level necessary to make changes to WikiFur's software configuration, database and image store.
  • The Host agrees to provide trusted WikiSystemAdmins root access to the server's jailed OS where WikiFur is hosted. This access should only be used for maintenance tasks not possible with the regular WikiAdmins access.
  • The WikiAdmins and WikiSystemAdmins are in charge of keeping the MediaWiki system, extensions and server components up to date.
  • Additional components can be installed if needed, but they must be cleared by the Host first, and must not be a security risk or materially impact server performance.
  • When possible the Host will provide automated backup processes to WikiFurAdmins. Where automated backups are not possible, WikiFurAdmins have full access to the data and are responsible for backing up the data as they deem necessary. In any case, it is the responsibility of WikiFurAdmins to ensure that the data in their possession is sufficient for restoring WikiFur. The Host cannot be held responsible for any data loss that may occur.
  • The Host or WikiFurSystemAdmins may decide to terminate WikiFur hosting at any time and for any reason. If terminated by the Host, WikiFurSystemAdmins will be given one month's notice. The Host will provide necessary assistance in transferring all necessary data from the server. During the notice period, if WikiFur's usage is compromising the normal use of other services on the server, the Host can throttle usage in order to restore those services.
  • The Host will make no claim of ownership over the site or its content, other than that which he already has as a WikiFur administrator and editor, nor attempt to modify the site, its database, its associated files or its presentation against the will of WikiFur's administrators, except as required by law (e.g. DMCA takedown requests) and maintenance tasks (e.g. database, filesystem, OS).
  • The WikiAdmins and WikiSystemAdmins agree to not do anything with their access that could be harmful for the server or its owner, and to respect the Terms of Service of the hosting datacenter (currently EV1 Servers/The Planet).
  • The system jail given for WikiFur's needs is for the sole purpose of hosting MediaWiki and should not be used in other ways without asking the Host first. The system should not initiate outgoing network connections or send spam.
  • The Host agrees to take reasonable steps to ensure the operation of the wiki from a server perspective, including performing or arranging for timely maintenance of the server's non-jailed system software or hardware when problems arise. The Host is not responsible for problems caused by the datacenter where the server is hosted. The Host will help to solve problems, but is not responsible for damage caused by WikiSystemAdmins or WikiAdmins.
  • As consideration, WikiSystemAdmins guarantee the Host will receive assistance with hosting costs up to the percentage of the server's resources used by WikiFur, on an annual basis. For example, if WikiFur used 10% of server resources and server costs were $3000, assistance of $300 would be guaranteed. The initial metric for resource usage shall be bandwidth used by WikiFur as a proportion of the physical server's total permitted server bandwidth. One-off charges, such as the addition of equipment needed primarily to support WikiFur, may be considered separately. Donations to the Host by third parties made on WikiFur's behalf shall be considered part of this assistance.
  • This agreement shall be governed by the laws of the State of Michigan.
/Laurence "GreenReaper" Parry/ 08:55, 16 July 2008 (UTC)
I agree with the above terms --Timduru 09:12, 16 July 2008 (UTC)

Explanatory notes[edit]

These notes do not part of the agreement
  • The exact form of hosting is not specified to allow the Host some flexibility.
  • Termination of hosting will be performed by WikiSystemAdmins after consulting with the responsible body, currently the group of WikiFur administrators.