I dislike wikis. At work we were using them. Now we're changing from wikis to an article management system. The idea on paper sounded great, but I'm realizing the pitfalls about the implementation.
There are some traits that wikis have that I like. There's also plenty of bad traits. Also, I'm thinking of MediaWiki when I say this stuff.
Pros:
Cons:
So now that I've said that - I have to say that the ideal approach would be to take the existing CMS approach but add in a few wiki features. Specifically the interlinking. We already have a comment feature on every page. Attachment management is per-page too.
Late night half dazed thoughts:
Link syntax couldn't be something like foo:bar - since javascript:foo would conflict. Perhaps something like [foo:bar] would be a good idea? For links to file attachments, [file:fileID] or [article:slug-title]. This would make life simpler for tracking what files are orphans, can display information about the file in-line in the documents (file type, size, etc.)
For a while I was looking into and hoping to go the eSATA route. Immature chipsets and lack of OS support have somewhat kept that idea frozen.
I want to use ZFS for a filesystem. Or a filesystem -like- ZFS. Currently there are no others out there like it. There is Btrfs, and there is another one I thought picking up steam (although I can't remember it now for the life of me) - both of those however aren't stable yet. ZFS is still not as stable as I wish on FreeBSD. It won't run natively on Linux, and I don't think it's very stable either. The only true way to get a stable filesystem like ZFS is to in fact run ZFS on Solaris.
I was not excited to try Solaris. It used to be a joke to call it "Slowaris" - I remember the old days of using random UNIX shells and hating Solaris boxes because I couldn't run hardly anything or compile anything. However, that's changed somewhat now. I took the plunge and installed SXCE (Nevada build 94) since Solaris 10u5 did not support the new CIFS implementation. So far, I've learned a little bit here and there about Solaris system administration and I've been using ZFS to create some snapshots, filesystems, etc. It is so easy even my mom could handle it. Not to mention Solaris has some pretty neat tools like the Solaris Fault Manager, which I have crontabbed to run every 30 minutes and email me if -any- hardware/faults get reported. So I have this great box sitting there running the best filesystem possible integrity-wise, and it is also damn quiet. It's not a small form factor which I would have liked, though.
So I begin looking into trying to get a small form factor ZFS box. I might be able to, if I want to hack up a Shuttle style case (see Udat at Mashie Design - there are mini-itx motherboards now with 6 SATA ports onboard which would allow for a 5 drive RAIDZ1 + maybe use a Compact Flash card for a boot drive. However, that requires case modding and can only fit 5 drives. I'm not sure I really want to try all that.
Instead, even Mashie himself has admitted to moving into larger form factors for storage boxes (I believe he's using a CM Stacker nowadays) - and from a space perspective, it probably does make the most sense.
Currently I'm exploring going with a full-size case that could hold 15 drives, or a mid-size case that could hold 10 drives (not including optical + boot)
I think I may have found a winner, for the mid-size option. Lian-li has a self-proclaimed "silent" chassis that has 9 bays (which means 6 bays for 2x5-in-3 modules) + optical + 1 boot disk in the spare 5.25" bay. Roughly 8-9TB usable in a mid-size case that would be about as silent as it can get. It even has a front door on it. Actually, there's a second place one - this one is much more extensible, but has no door on it, which I think would help shield any noise coming from these 5-in-3 modules. See here. Cooler Master also has a case like that too - again, no door on the front. I wish I had local access to all of these cases to try each of them out. Right now I have to order them online, and then pay possible restocking fees, and at least the cost of shipping the product back. I'm tired of that back and forth game. I've had to do it too many times in the past.
Lian-li also has a full-size chassis that already includes 10 internal drive bays, + 5x 5.25" front bays. Those extra bays could be used for more drives too. So many options... I'm trying to determine the amount of space I want to use in my office and how large and bulky I want these machines to be. Ideally I would like as little CPUs as possible - no need to have full-out operating systems installed and having to manage all that. I'm just tired of all my equipment making noise, getting hot, failing, and data corrupting due to failure or bit-rot. It's time to upgrade and streamline.
I've pretty much examined every chassis at Lian-li, Coolermaster and Antec. I have an Antec P182 right now. It's great and quiet, but does not support as many drives as I want for these next boxes. Stay tuned as I pull the trigger and build another storage box soon. Perhaps I'll share some pictures and specifications with my existing storage box I just built, which is for "off site" daily snapshots of my hosting infrastructure and some other servers I administer.
These next machines will be for my own personal use... and now I've gained some good knowledge on what to expect. It's been a while since I've built a normal-sized machine, as I've been a Shuttle XPC user for years now ![]()
There's been a minor tweak required in my original WordPress+nginx rewrite rule post.
I think we've finally got it right now. I've been exchanging emails ad nauseum with Igor and I believe the behavior now works properly (part of the exchange was regarding PHP+basic http auth, there were some bugs around the regexps/nested location blocks or something)
Anyway, here is a perfect working example, running this very website:
server {
listen 80;
server_name michaelshadle.com;
index index.php;
root /home/mike/web/michaelshadle.com/;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
error_page 404 = /wordpress/index.php?q=$request_uri;
location ^~ /wordpress/wp-admin {
auth_basic "wordpress";
auth_basic_user_file /home/mike/web/michaelshadle.com/.htpasswd;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
Likewise, you can also omit the basic HTTP authentication if you don't think you need it:
server {
listen 80;
server_name michaelshadle.com;
index index.php;
root /home/mike/web/michaelshadle.com/;
include /etc/nginx/defaults.conf;
include /etc/nginx/expires.conf;
error_page 404 = /wordpress/index.php?q=$request_uri;
location ~ \.php$ {
fastcgi_pass 127.0.0.1:11000;
}
}
Note: this does require a patched version of 0.7.10 - I assume he will put these changes into 0.7.11. Some of the changes required include the basic HTTP auth stuff. Also, when using error_page 404, it generated logfile noise in the error log. That was fixed as of 0.7.9 or 0.7.10, so no longer will you receive script-handled 404's in your error log.
This should be the last and final need to run WordPress properly under nginx. This has the approval of Igor, the creator - you cannot get better than that. (Note: this is WordPress 2.6.1, but I have not seen any reason the rewrite rule would be different since even before 2.x)
Let me know if it doesn't work! Or better yet, let the nginx mailing list know ![]()