Back to obscure technical topics for a moment.
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'
Restart Apache and voila, the above umask will give all files written by Apache a chmod of 777.
Use this particular example with caution.
If you are trying to get some custom macros to work with Outlook as outlined, for example, here and here, you may be befuddled to discover that that your macros fail silently; usually after restarting Outlook. This is because Outlook is quietly disabling all macros because it
hates youI mean, because it doesn’t trust you. That is to say, it doesn’t trust your self-signed cert.
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:
- Run certmgr.msc as an Administrator.
- Open the “Personal” tree node in the left pane.
- Open the “Certificates” node under the Personal node.
- Note that your self-signed certificate appears in the right pane. It may have a red “X” through it.
- 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.
- Hold down the control key and drag the cert into “Trusted Root Certification Authorities > Certificates” which should appear immediately below the Personal node.
- Follow any prompts to completion. The red “X” should disappear and your cert should know have a key icon attached to it.
- Inside Outlook, re-associate this cert with your macro.
- 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.
This comes to me word-of-mouth.
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:
# ::1 localhost
Go go backup brain:
$ find -type f ¦ wc -l
As found elsewhere on the net.
Recent versions of WordPress have taken a queue from Janis Elsts’ One Click Plugin Updater and made it *much* easier to keep plugins up-to-date without having to fire up FTP. The problem is that WP seems to use permissions of it’s script files to determine whether or not plugins and themes can be uploaded to the server or not. Really WP should be looking at the target directory rather than the executing script; consequently I assume most folks just assign web server ownership to the entire WP source tree. Which, frankly, kind of freaks me out security-wise.
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.
Getting the following message when trying to use Flymake with PHP?:
“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.
svn cleanup seems to do this when there is a partially completed update in a directory. (I think..) Try deleting the .svn/log file in the offending directory and doing
svn cleanup again.
Thank you stackoverflow.
Strange but true. And something that seems to trip me up once every other year or so.
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.
If you’re like me, back in the murky past your created a few (or several) Google Analytics accounts to track all manner of web sites and other online shenanigans. And now you want to consolidate without losing any data.
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:
- Create the new Google Account to which you want to transfer control.
- Log in as the original Google Analytics Administrator account.
- 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.
- Login to the new account.
- Change the original Administrator account to “User” (don’t forget this step)
- Delete the original account.
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.
There’s lots of recommendations floating around the net for this, but try the following first:
Make sure that the user and group permissions for the account and the home directory match. For example, if you are logging in as:
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.