Thanks to Monty, I've learned something that will save me a lot of headache in the future. I had a bunch of random scripts I wrote myself to try to keep things in sync, turns out most of the work is already all done for me.
On the source host you want to clone:
dpkg --get-selections > file
On the destination host:
dpkg --get-selections < file
apt-get dselect-upgrade
Now your machines should be identical, package-wise.
I just realized when trying to use the try_files shortcut that either the behavior has changed or the code I've used it for has never had to take advantage of it, but what happens when you do something like this:
try_files $uri $uri/ /foo/index.php?u=$uri;
Is that the query string is stripped out and the only thing PHP sees is the $_GET['u']
to fix this, it's easy enough:
try_files $uri $uri/ /foo/index.php?u=$uri&$args;
I never noticed this behavior in WordPress (I've been using try_files with it for a while without noticable issue) but it was an issue with Drupal (which uses the Front-Controller Pattern just like WP does) and custom code we've written.
I haven't asked Igor if the behavior has changed slightly with it, but the changelogs have not mentioned any behavior changes, from what I can tell.
Anyway if you notice your pagination or other GET params are being dropped, you might want to take a quick look at that ![]()
OLD:
error_page 404 = /wordpress/index.php?q=$request_uri;
or:
if (!-e $request_filename) {
rewrite ^/(.*) /wordpress/index.php?uri=$request_uri last;
}
NEW:
try_files $uri $uri/ /wordpress/index.php?q=$uri;
Why make life more complicated if you don't need to?
Also thanks to Igor's patch you can have multiple of these, i.e.:
location /wordpress {
try_files $uri $uri/ /wordpress/index.php?q=$uri;
}
location /anotherapp {
try_files $uri $uri/ /anotherapp/controllerfile.php?q=$uri;
}
etc.
This is good, as Drupal, WordPress and many other packages (including anything I develop anymore) use the Front Controller pattern of development, which makes deploying applications a lot simpler and helps support a consistent framework across the entire application.
Typically, updates on the open source packages work without a hitch. However, my upgrade last weekend on my servers from Ubuntu Hardy to Intrepid wound up creating a couple major headaches, and at the same time, I noticed a handful of other snafoos happening to open source packages I use daily.
This wound up in server instability, client annoyance, and 20-30 hours solid of trial-and-error compiling, testing, debugging, etc. Even right now, if I forget to hold back the libgpac-dev package from being updated, all videos being converted lose their sound due to MP4Box crashing.
One thing most places forget to mention, at least clearly, is the need to update the LU tools before you run the upgrade.
This assumes you have the DVD .iso already on the system, and you are mounting it to a directory (in this example, /export/loop)
First update the LU tools off the new disc. This process wasn't really included in a lot of blogs I read:
mount -F hsfs /path/to/sol-nv-b101-x86-dvd.iso /export/loop
cd /export/loop/Solaris_11/Tools/Installers
./liveupgrade20
*Now* you can run all the LU commands:
lucreate -p rpool -n snv_101
luupgrade -u -n snv_101 -s /export/loop
luactivate snv_101
init 6
shutdown -i6 -g0 -y (if init 6 doesn't reboot - maybe I was impatient :))
P.S. Don't put the .iso on your root pool or it will be included in the filesystem forever and you won't be able to get that space back. Thanks Tim ![]()
I comment on a lot of random sites and blogs. I usually write down the URL in a text file and hope that someday I'll remember to return to see if there's a reply.
I believe a service exists - I know that "page change notification" services exist, but I'd rather be able to subscribe to an RSS feed of reply notifications - i.e. I post on a blog, I dump the URL into a textbox, and it monitors the site every so often for changes (probably the specific post's comment feed is the only thing that is worthwhile) - even better, someday maybe even automatically adding the URL when the browser notices I've commented.
Anyone got a site out there that does this yet? I've had this on my mental radar for a while. Of course, that doesn't really do anything if I can never get around to finishing anything.
Note: this has been outdated once again. Now it can be simplified with one simple directive shown here.
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 ![]()
I think I keep my machines pretty well up to date. I'm fixing up my girlfriend's computer right now, and I finally got all the updates applied except apparently one got missed. Okay, simple enough right?
Step #1: Install .NET Framework 1.0, click "Check for updates" - what? there's another update?
Step #2: Install .NET Framework 1.1 Service Pack 1, click "Check for updates" - what? ANOTHER one?
Step #3: Install .NET Framework 1.1 Service Pack 1 security update, click "Check for updates" ...
Really? Why couldn't we have a pre-packaged full install? Why do I have to run this "check for updates" over and over (and why does it take so goddamn long nowadays?)
Okay, looks like that really was the last update and this machine is now 100% up to date. At least for the moment...
Note: this has been outdated now. I have an updated post with the latest and Igor-approved method here.
When I was switching over to nginx, I found a handful of random and overkill config examples to make it work. I thought I had found the simplest solution already, but Igor (the creator of nginx) actually gave me an even "better" solution in nginx.
This is assuming WordPress is physically installed in /wordpress, and pages are served up using friendly URLs, /2008/02/03/post-title/ - just like this site. All the rewrites are off the root. I assume you've already got PHP setup to parse properly and you have a working server {} block. I'll post that info too if people really need it.
1st example (seems like overkill, can't figure out a reason why people are splitting up the rewrite rules - I guess because they assume "wp-anything" is all static?):
if (!-e $request_filename) {
rewrite ^([_0-9a-zA-Z-]+)?(/wp-.*) $2 break;
rewrite ^([_0-9a-zA-Z-]+)?(/.*\.php)$ $2 last;
rewrite ^ /index.php last;
}
2nd example (this was as good as I thought it could be, but I was wrong):
if (!-e $request_filename) {
rewrite ^(.+)$ /wordpress/index.php?q=$1 last;
}
3rd example (this is the best, according to Igor):
error_page 404 = /wordpress/index.php?q=$uri;
(Ref: http://article.gmane.org/gmane.comp.web.nginx.english/4739)
In the past, I've always been able to disable IPV6 in Linux with a simple line in any /etc/modprobe.d file:
alias net-pf-10 off
It appears though it has no effect anymore. I had to change it to this line:
blacklist net-pf-10
How annoying.