Figuring out how to set umask for Apache on Ununtu was faaar more difficult than it needs to be. Even though it’s not an environmental variable, the “Ubuntu Way” seems to be to add this to the end of /etc/apache2/envvars like so:

...
## Some packages providing 'www-browser' need '--dump'
#export APACHE_LYNX='www-browser -dump'
umask 000


Restart Apache and voila, the above umask will give all files written by Apache a chmod of 777.

Use this particular example with caution.

In Windows 7 it appears as though self-signed certs have to first be copied into a “trusted” group before they can be used. Here’s how to do it:

1. Run certmgr.msc as an Administrator.
2. Open the “Personal” tree node in the left pane.
3. Open the “Certificates” node under the Personal node.
4. Note that your self-signed certificate appears in the right pane.  It may have a red “X” through it.
5. Double-click the certificate in the right pane to see instructions about copying the certificate to the “Trusted Root Certification Authorities” store.  Good thing these important details are so easy to discover.
6. Hold down the control key and drag the cert into “Trusted Root Certification Authorities > Certificates” which should appear immediately below the Personal node.
7. Follow any prompts to completion.  The red “X” should disappear and your cert should know have a key icon attached to it.
8. Inside Outlook, re-associate this cert with your macro.
9. Restart Outlook for the new cert to be applied.

And voila, Outlook trusts you again.

Not, of course, that you should every fully trust it back.

It seems there’s a longstanding bug/feature in the firewall routemap that causes the ipv6 localhost link to fail, and then the v4 link is tried, and succeeds. Apache is bound to both, but Windows won’t route the v6 link correctly.

There are a couple of solutions here, including turning off ipv6 in Windows. It’s probably easiest just to explicitly define “localhost” in C:\Windows\System32\drivers\hosts. Uncommment the 127.0.0.1 line:

127.0.0.1 localhost
# ::1 localhost


As found elsewhere on the net.

If you’d also rather avoid recursively chown’ing the WordPress tree to your web server, then simply give web server ownership to three files in the wp-admin directory: plugin-install.php, plugins.php, and update.php. Of course the web server will also need to own the plugins directory (and everything therein), the upgrade directory, as well as the wp-content directory itself. The “upgrade automatically” links should now work without kicking you to the “Connection Information” screen.

“Flymake: Configuration error occurred while running. Flymake will be switch OFF”

This threw me, though it probably shouldn’t have. If you’re seeing it as well, double check two settings in your php.ini file:

1. The error_reporting setting needs to include E_PARSE. I personally like to use error_reporting = E_ALL | E_STRICT. This shows everything that the PHP compiler thinks you are doing wrong.

2. Also double check your php.ini file for display_errors = On. I almost always forget about this when setting up on a new box because I tend to override php.ini with .htaccess values.

Finally, triple check your command line php settings with a quick $ php -i, which dumps the content of phpinfo() to the command line.

Thank you stackoverflow.

If you use the -e/–execute option while loading a dump, MySQL silently ignores -f/–force.  In other words, MySQL will not execute force.

But if you pass the same data in via a pipe, MySQL will beat the hell out of anything malformed and cram whatever it can into the database.

MySQL:  The Gandhi of databases… unless armed.

For some reason Google’s patent reply to this (probably) common interest is to state that transferring account data is not possible.  But actually it’s quite easy.  At least, it’s quite easy once you’ve played around with your various Google accounts for a few hours and finally figured out how administrator assignment works.

To do a “transfer”, all you have to do is:

1. Create the new Google Account to which you want to transfer control.
2. Log in as the original Google Analytics Administrator account.
3. Assign a the new account “Administrator” access.  (Edit -> Users with Access to Profile -> Add User)  Be sure to give this new user the “Administrator” access type.
4. Login to the new account.
5. Change the original Administrator account to “User” (don’t forget this step)
6. Delete the original account.

Easy peasy.

Just note that if you have a bunch of analytics site data all tied together under one profile, then all of it will transfer together.  As far as I can tell, there is no way to uncouple this.  And this is probably what Google is referring to when they say that ownership cannot be transferred.

Make sure that the user and group permissions for the account and the home directory match. For example, if you are logging in as:

account:x:521:500::/some/directory:/sbin/nologin

then make sure that the home directory defined for “account” is at least readable and executable by user 521 and group 500.

I posted about this previously but this time I also ran into directory permissions. Ugh.