A buddy of mine sent me an email the other day wishing me a happy Squirrel Appreciation Day. That holiday has come and gone with a minimum of squirrel suicide, but here’s a squirrel video I actually can appreciate. (In case you’ve already seen the video, which has made it’s way around the world via email of all things, I found a long-play version with a little more info and footage of a second clever thief.) Apparently the perpetrator of the video added obstacles one at a time, with this as the final result.
It is purely coincidental that the next two links are by the last two people to comment on this blog as of this writing.*
My favorite climate scientist has given us all reason to fight global warming: the supply of chocolate is threatened! This is a must-read, kids.
And earlier today I popped over to a blog and read an article about… blogs. It’s an interesting read about the blog life-cycle, how they grow and why they die, to which I can add a few musings. Muddled Ramblings is an outlier in blog taxonomy, I think; it lies outside the regular life-cycle, in a place where many blogs die. It’s a blog without any clear theme, and without any real growth in readership. The bloggcomm is small but strong; the comments provide a huge lift in value for everyone. But gone are the days of the Millennial Office Holder and similar hijinks, and no insider silliness has grown to replace them. Still I blog along, more than eight years and 1800 episodes worth. It’s a blog that will not die — a blog zombie!
After reading that article I’m pondering ways to better foster community here at MR&HBI. I don’t want to lose what we already have going, or to diminish in any way the contributions of the faithful, but it seems like there’s more stuff we could do together. I think the collaborative writing experiment It Goes Without Saying was on the right track, but the barrier to participation was a little too high – you had to know what was going on. Something collaborative that people could just drop by and toss in a contribution without too much effort would be really cool. (The Fantasy Novelist’s Scoreboard awaits your input!)
The writers of Web comics often have events where they write episodes for each others’ strips. That would be fun, to have guest posts from other bloggers here, while I blog there. Fun for me, certainly, but would it be compelling for readers? In the comic world, the guest artist borrows the characters from the strip and puts a new twist on them. It would be pretty hard for someone to take such an unfocussed forum as this one and put any sort of twist on it. Then again, since when has ‘not fun for the readers’ stopped me before?
I enjoy writing challenges; Elephants of Doom was the most elaborate response to one such challenge, and just a few days ago I cranked out The Secret Life of Sporks. That was a hoot, and I wouldn’t mind a bit if there were more challenges like that. I’d formalize something (“Wacky prompt Thursday!”) but I’m petrified that no one would suggest anything and the sound of crickets chirping would be embarrassing.
Also, I need to get the Muddled Calendar back up and running. Maybe we can finally name all the holidays.
But now I’m rambling far, far off the “post a few links” intent of this episode, staggering around the blogosphere like a drunken beachcomber with a broken metal detector, looking for answers but really too lazy to find them.
I haven’t mentioned in these pages yet that Harlean Carpenter (who is a fiction) and I are making a magazine. Not some web-zine, either, but a nice, substantial print magazine called The Poetic Pinup Revue. The magazine is large, printed on good, heavy paper, and built to last. As you might guess by the title, it’s a book that juxtaposes beautiful images (that lean toward the pinup genre) and carefully-matched poetry. Harlean painstakingly laid the text into the images so that each enhances the other.
Yes, I am aware that I just took the Post Office to task for encouraging the slaughter of trees. This is the kind of thing paper should be used for. It’s bold, sturdy, and carries the impact that only an 11×17-inch spread can. Some of the pages are simply awesome.
At least, I think they are. My contribution to the Revue was mainly technical, laying out the pages in Adobe Illustrator and for some images tweaking the color balance after converting from RGB to CMYK.
But… did I do it right? Should I have tweaked all the images, not just the ones that didn’t look right onscreen in the .pdf file? Black works a little funny in CMYK; will the images lose their richness and depth on the printed page? Is some awesome photographer out there going to cringe to see her own work poorly reproduced? Or, on the other hand, will the images be so beautifully rendered that we are flooded with submissions for the next issue? There’s really no way to know if I got the colors right until we see the actual magazine sprayed onto dead trees a few days from now.
The first print run had to be of a certain size to be cost-effective. That means each mistake is repeated that many times, but it also means that each gorgeous page will create a whole bunch of smiles and thoughtful expressions. Please, oh please, gods of ink and pulp, let them all be gorgeous.
No matter how it turns out, I’ll be letting you know here. For the lowdown on the magazine itself, swing on by PoeticPinupRevue.com.
Not very long ago, 200 visitors to this blog in a single day was an event worthy of my turning to my sweetie and saying, “hey, I got 200 visitors yesterday”. Now here it is before noon on a Sunday and the magic number has already been surpassed. What gives? Ladies and Gentlemen and others of the blogging community, I call your attention to exhibit A (click to see a bit bigger):
surging demand for egg-frying advice
This is the number of loads of a single episode on my blog: my tutorial on cooking eggs over-easy. That episode has been around a long time, but you don’t need an advanced degree in statistics to see that lately its popularity has been gong through the roof.
The blogger’s lament: “If only I could figure out how to turn those visitors into regular readers!” Still, I can console myself that perhaps out there a few more people are experiencing delicious egg breakfasts.
I suspect Google’s +1 has something to do with the precipitous rise in popularity; if a few people have endorsed the page, Google’s going to move it closer to the top of its rankings. It is a pretty damn good tutorial, I have to say, even if the promised video is currently AWOL.
I’m a little surprised, because I suspect the +1 thingie at the bottom of each page doesn’t work for everyone. The code tries to load a script in a way that violates the security policies of my browser (and should violate that policy on all of them, though obviously it doesn’t). I’ve found another, no-script button set that I could use instead, but in my naïvety about how that all stuff works, I don’t know if I’ll lose my current mojo if I switch. Will Google see the next + the same way? I’m probably fretting over nothing.
Showing kindness to others is its own reward – especially when the ‘other’ is a three-headed kitten.
[podcast]
The long-overdue third in the series; I almost forgot how to do all this stuff. I did figure out why the audio quality was so different last time, but hell if I kept having problems with plosives this time around.
I also learned once more that writing for a performance and writing for readers is different. In some places I made edits to the story to help keep it clearer who was talking, and perhaps I should have done that a little more. Still, I’m pretty happy with the result. One of the downsides to using my favorite stories first is that I make my mistakes on them. Once I’m rich and famous I’ll go back and redo the first ones as well.
The United States Postal Service has opened up a new campaign. “Isn’t paper great!” they tell us. You can put your records in a filing cabinet and everyone loves that!
Way to go green, semi-governmental entity! While I’m at it, should I make stacks of tear-off sheets for this blog, so people can save what I wrote in a filing cabinet, too?
Aren’t the players supposed to run? ‘Cause most of them don’t. Shambling faster than the other guys makes you ‘up-tempo’. I don’t think the players are as coked-up as the networks want us to believe.
Maybe the league should rewrite the traveling rule to reflect what’s actually enforced. Better yet, enforce the current rule.
Mr. Defender* – are you angry that the guy who had the ball blocked you from getting out of his way? The way you twisted and forced your way past the guy with the ball was inspirational. You had someplace to go. Someplace far from the play.
Number two wasn’t a question. Neither is this.
Do you really expect me to watch this? I mean, obviously I see enough of the activity (sport, not so much) to form judgements, but do you really think you have a good product?
Sorry, NBA, that was two questions. You don’t have to answer the second.
* He’s the guy who inspired this screed. He fought his way past the guy with the ball to get into open space so the enemy could get a basket. Don’t ask me who he was; he’s not exceptional. This is how they play the game.
Side note to Memphis: Your yellow shirts and dark green shorts are the Worst Uniform Ever, in any sport (except maybe the Padres and Astros in the ’70’s). The awfulness is amplified by your total disregard for your team identity. Grizzly? Hardly. How much did you pay your marketing team? I’ll do better for half as much.
“Half-breed” they’re called, and far worse names. Not a true spoon, not a true fork, but some bastard hybrid from a 1950’s science fiction movie.
The only cutlery that’s always plastic. The only cutlery whose name isn’t also a verb. They are the sporks. A group so marginalized that my spelling checker suggests ‘sparks’.
They don’t have a place in the drawer, even though they replace two of the implements already there. They can lift soup to your mouth and they can hoist up a nice chunk of steak. It’s no wonder spoons and forks feel so threatened.
But perhaps you didn’t know this: Sporks are doing just fine, thankyouverymuch. They have their own culture, their own traditions, and they’re not pining for our acceptance. Recently I had the privilege of witnessing a Spork-out, a celebration of spork by sporks. While I agreed to not reveal the sacred rituals, I can relate a few impressions.
Presiding over all was the Elder Spork, coffee-stained and partially melted, bowing to confer his blessing on the gathered youth. How he laughed to the song, “whatcha gonna do with that one-inch tine, forky?”
The youth, so energetic and idealistic, chanting “we can do it all!”
The uproar when revolutionary Sporkicus suggested they adopt serrated edges and “bring down the knives.” What followed can only be called a riot.
There is more, so much more, but if I don’t want my heart to be slowly and inefficiently removed from my body I must stop now.
Getting Apache, PHP, and MySQL installed and talking to each other is pretty simple — until something doesn’t come out right. This guide takes things one step at a time and checks each step along the way.
NOTE: At this moment (November 4, 2017), some of the file paths given below are out-of-date. The new organization is better, but until I have a chance to verify the new stuff, you may have to do a little poking around to find what you’re looking for.
The good new is that because of the changes, you may not need this guide anymore, but I’ll update it when I get a chance to do a new install, just to keep my own head on straight.
March 8, 2016 (added 'select' during php install)
March 8, 2016
Using MacPorts to build a LAMP server from scratch
About this tutorial:
There are other step-by-step guides out there, and some of them are pretty dang good. But I’ve never found one that I could go through and reach the promised land without a hitch. (Usually the hitches happen around MySQL.) Occasionally key points are glossed over, but I think mostly there are things that have changed, and the tutorials haven’t updated. Now however I’ve done this enough times that there are no hitches anymore for me. Since MacPorts occasionally changes things, I’ll put up at the top of this page the last time this recipe was last used exactly as written here.
This guide breaks things down into very small steps, but each step is simple. I include tests for each stage of the installation, so problems can be spotted while they're easy to trace. We get each piece working before moving on to the next. I spend a little time telling you what it is you accomplish with each step, because a little understanding can really help when it’s time to troubleshoot, and if things are slightly different you have a better chance of working through them.
Audience: This guide is designed to be useful to people with only a passing familiarity with the terminal. More sophisticated techno-geeks may just want to go through the sequence of commands, and read the surrounding material only when something doesn't make sense to them. The goal: follow these steps and it will work every damn time.
MacOS X versions: Tiger, Leopard, Snow Leopard, Lion. Maybe others, too. The beauty of this method is it doesn’t really matter which OS X version you have.
The advantages of this approach
There are multiple options for setting up a Mac running OS X to be a Web server. Many of the necessary tools are even built right in. Using the built-in stuff might be the way for you to go, but there are problems: It’s difficult to customize (Search on install apc Mac and you’ll see what I mean), you don’t control the versions of the software you install, and when you upgrade MacOS versions things could change out from under you.
Also simple to set up is MAMP, which is great for developing but not so much for deployment. For simple Web development on your local machine, it’s hard to beat.
But when it comes right down to it, for a production server you want control and you want predictability. For that, it’s best to install all the parts yourself in a known, well-documented configuration, that runs close to the metal. That’s where MacPorts comes in. Suddenly installing stuff gets a lot easier, and there’s plenty of documentation.
Holy schnikies! A new timing exploit on OpenSSL! It may be months before Apple's release fixes it. I want it sooner!
What you lose:
If you’re running OS X Server (suddenly an affordable option), you get some slick remote management tools. You’ll be saying goodbye to them if you take this route. In fact, you’ll be saying goodbye to all your friendly windows and checkboxes.
Also, I have never, ever, succeeded in setting up a mail server, MacPorts or otherwise, and I’ve tried a few different ways (all on the same box, so problems left over from one may have torpedoed the next), and no one I've ever met, even sophisticated IT guys, likes this chore. If serving mail is a requirement, then OS X Server is probably worth the loss of control. Just don’t ever upgrade your server to the next major version. (Where’s MySQL!?! Ahhhhhh! I hear frustrated sys admins shout.)
So, here we go!
Document conventions
There are commands you type, lines of code you put in files, and other code-like things. I've tried to make it all clear with text styles.
This is something you type into the terminal
Do not type the ; it's just to represent the prompt in your own terminal window. Once you've typed the text (or pasted it in from here), hit return.
This is a line of code in a file.
Either you will be looking for a line like this, or adding a line like this.
This is a reference to a file or a path.
Prepare the Box
Turn off unneeded services on the server box. Open System Preferences and select Sharing.
turn on remote login
(optional) turn on Screen Sharing
Turn off everything else - especially Web Sharing and File Sharing
Install XCode. This provides tools that MacPorts uses to build the programs for your machine. You can get XCode for free from the app store. It’s a huge download. Note that after you download it, you have to run the installer. It may launch XCode when the install is done, but you can just Quit out of it. Lion and Mountain Lion require an extra step to install the command-line tools that MacPorts accesses.
Install MacPorts. You can download the installer from http://www.MacPorts.org/install.php (make sure you choose the .dmg that matches the version of MacOS you are running). Run the installer and get ready to start typing.
Now it’s time to make sure MacPorts itself is up-to-date. Open terminal and type
sudo port selfupdate
password: <enter your admin password>
MacPorts will contact the mother ship and update itself.
If you're not familiar with sudo, you will be soon. It gives you temporary permission to act as the root user for this machine. Every once in a while during this process you will need to type your admin password again.
May as well get into the habit of updating the installed software while we’re at it. Type
sudo port upgrade outdated
and you will most likely see a message that looks like an error but really says that there was nothing to upgrade. No biggie.
Make a habit of running these commands regularly. One of the reasons you're doing this whole thing is to make sure your server stays up-to-date. This is how you do it.
Install Apache
Now it’s time to get down to business. All the stuff we’ve installed so far is just setting up the tools to make the rest of the job easier. Let’s start with Apache!
sudo port install apache2
This may take a little while. It’s actually downloading code and compiling a version of the server tailored to your system. First it figures out all the other little pieces Apache needs and makes sure they’re all installed correctly. Hop up and grab a sandwich, or, if you're really motivated, do something else productive while you wait.
When the install is done, you will see a prompt to execute a command that will make Apache start up automatically when the computer is rebooted. Usually you will want to do this. The command has changed in the past, so be sure to check for the message in your terminal window. As of this writing, the command is:
sudo port load apache2
Create an alias to the correct apachectl. apachectl is a utility that allows you to do things like restart Apache after you make changes. The thing is, the built-in Apache has its own apachectl. To avoid confusion, you can either type the full path to the new apachectl every time, or you can set up an alias. Aliases are commands you define. In this case you will define a new command that executes the proper apachectl.
In your home directory (~/) you will find a file called .profile - if you didn’t have one before, MacPorts made one for you. Note the dot at the start. That makes the file invisible; Finder will not show it. In terminal you can see it by typing
ls -a ~/
You will get back a list of all the files in your home directory, including the hidden ones that start with ..
Edit ~/.profile and add the following line:
alias apache2ctl='sudo /opt/local/apache2/bin/apachectl'
Edit how? See below for a brief discussion about editing text files and dealing with file permissions.
~/.profile isn't the only place you can put the alias, but it works.
You need to reload the profile info for it to take effect in this terminal session.
source ~/.profile
Now anywhere in the docs it says to use apachectl, just type apache2ctl instead, and you will be sure to be working on the correct server.
Start Apache:
apache2ctl start
You might see a warning or two, probably a notification about the server's name. That's fine.
Test the Apache installation. At this point, you should be able to go to http://127.0.0.1/ and see a simple message: “It works!”
MILESTONE - Apache is up and running!
Install PHP
Use MacPorts to build PHP 5:
sudo port install php56-apache2handler
Time passes and I don't always update the php version number. At this moment the latest php version is 5.6, so you use php56 everywhere. If you want to install php 7.0, you would use php70. You get the idea.
MacPorts will know it needs to install php56 before it can install the apache2 stuff.
You could install the MySQL extensions to PHP now (sudo port install php56-mysql), but that will cause MySQL to be installed as well. It’s no biggie, but I like to make sure each piece is working before moving on to the next. It makes problem-solving a lot easier. So, let’s hold off on that.
Choose your php.ini file. There are a couple of different options that trade off security for convenience (error reporting and whatnot). As of this writing there is php.ini-development (more debugging information, less secure) and php.ini-production. Copy the one you want to use and name it php.ini:
You will be editing this file a little bit later, but mostly it’s just a bunch of settings you’ll never need to understand.
Test the PHP install
On the command line, type
php56 -i
A bunch of information will dump out. Hooray!
Make your new php the default. This will allow you to run scripts from the command line just by typing 'php', rather than having to specify 'php56'.
On the command line, type
sudo port select --set php php56
Test this by typing
which php
You will see /opt/local/bin/php, which is where MacPorts keeps a pointer to the version you specified.
Now it’s time to get Apache and PHP talking to each other. Apache needs to know that PHP is there, and when to use it. There’s a lot of less-than-ideal advice out there about how to do this.
httpd.conf is the heart of the Apache configuration. Mess this up, Apache won’t run. It’s important, therefore, that you MAKE A BACKUP (there’s actually a spare copy in the install, but you never rely on that, do you?)
cd /opt/local/apache2/conf
sudo cp httpd.conf httpd.conf.backup
First run a little utility installed with Apache that supposedly sets things up for you, but actually doesn’t do the whole job:
cd /opt/local/apache2/modules
sudo /opt/local/apache2/bin/apxs -a -e -n php5 mod_php56.so
The utility added the line in the Apache config file that tells it that the PHP module is available. It does not tell Apache when to use it. There is an extra little config file for that job, but it’s not loaded (as far as I can tell), and it’s not really right anyway. Let's take matters into our own hands.
It won't let me save! See below for a brief discussion about editing text files and dealing with permissions.
Time to edit! Open /opt/local/apache2/conf/httpd.conf with permission to edit it. We need to add three lines; one to tell it that PHP files are text files (not strictly necessary but let’s be rigorous here), and two lines to tell it what to do when it encounters a PHP file.
Search for the phrase AddType in the file. After the comments (lines that start with #) add:
AddType text/html .php
Search for AddHandler (it’s just a few lines down) and add:
AddHandler application/x-httpd-php .php
AddHandler application/x-httpd-php-source .phps
The second of those is just to let you display PHP source code in a Web page without actually running it.
Finally, we need to tell Apache that index.php is every bit as good as index.html. Search in the config file for index.html and you should find a line that says DirectoryIndex index.html. Right after the html file put index.php:
Before:
DirectoryIndex index.html
After:
DirectoryIndex index.html index.php
(Optional) As long as we’re in here, let’s make one more change for improved security. Search for the line that specifies the default options for Apache and remove Indexes:
Before:
Options Indexes FollowSymLinks
After:
Options FollowSymLinks
This prevents outsiders from seeing a list of everything in a directory that has no index file.
Save the file.
Check the init file syntax by typing
/opt/local/apache2/bin/httpd -t
You will probably get a warning about the server’s name again, but that’s OK, as long as you see the magical Syntax OK message. If there is an error, the file and line number should be listed.
Restart Apache:
apache2ctl restart
Test whether PHP and Apache can be friends. We will modify the “It Works!” file to dump out a bunch of info about your PHP installation.
Currently the default Apache directory is /opt/local/apache2/htdocs
Start by renaming index.html to index.php:
cd /opt/local/apache2/htdocs
sudo mv index.html index.php
Edit the file, and after the It Works! bit add a PHP call so the result looks like this:
<html>
<body>
<h1>It works!</h1>
<?php echo phpinfo(); ?>
</body>
</html>
Save the file
Go to http://127.0.0.1 - you should see a huge dump of everything you wanted to know about your PHP but were afraid to ask.
MILESTONE - Apache and PHP are installed and talking nice to each other.
Install and configure MySQL
Use MacPorts to install MySQL database and server and start it automatically when the machine boots:
sudo port install mysql55-server
sudo port load mysql55-server
Now we get to the trickiest part of the whole operation. There's nothing here that's difficult, but I've spent hours going in circles before, and I'm here so you won't find yourself in that boat as well. MySQL requires some configuration before it can run at all, and it can be a huge bother figuring out what’s going on if it doesn’t work the first time. We start by running a little init script:
As with Apache, you can create a set of aliases to simplify working with MySQL. There are some commands you will run frequently; things get easier if you don’t have to type the full path to the command every time. Open up ~/.profile again and add the following three lines:
alias mysqlstart='sudo /opt/local/share/mysql55/support-files/mysql.server start'
alias mysql='/opt/local/lib/mysql55/bin/mysql'
alias mysqladmin='/opt/local/lib/mysql55/bin/mysqladmin'
#TEMPORARY addition to the path so the next step will work
export PATH=/opt/local/lib/mysql55/bin:$PATH
When you're done, save and
source ~/.profile
Next we need to deal with making the database secure and setting the first all-important password. The most complete way to do this is running another utility that takes you through the decisions.
The script offers to delete some test users and databases that in my experience are totally useless anyway. Take the advice offered and get rid of all that junk.
Remember the password you set for the root user!
You now have a MySQL account named root which is not the same as the root user for the machine itself. When using sudo you will use the machine root password (as you have been all along), but when invoking mysql or mysqladmin you will enter the password for the database root account.
As with PHP above, MySQL has example config files for you to choose from. The config file can be placed in a bunch of different places, and depending on where you put it, it will override settings in other config files. If you follow this install procedure, you don’t actually need to do anything with the config files; we’ll just be using the factory defaults. But things will work better down the road if you choose a config that roughly matches the way the database will be used.
Find where the basedir is. As of this writing it’s /opt/local, and that’s not likely to change anytime soon, but why take that for granted when we can find out for sure? Let's make a habit of finding facts when they're available instead of relying on recipes like this one.
mysqladmin -u root -p variables
password: <enter MySQL root user's password>
A bunch of info will spew across your screen. At this moment, there are two interesting nuggets: basedir and socket. Make a note of them for later.
Now it’s time to choose which example config file you want to start with. The examples are in /opt/local/share/mysql55/support-files/, and each has a brief explanation at the top that says what circumstances it’s optimized for. You can read those, or just choose one based on the name. If you have no idea how big your database is going to be, medium sounds nice. You can always swap it out later.
Fill in <basedir> with the basedir you learned in the previous step.
Test MySQL
On the command line, type
mysql -u root -p
password: <enter MySQL root user's password>
and enter the MySQL root user password when prompted. No errors? Cool. We’re done here. Type
exit
at the prompt.
MILESTONE - MySQL server is running and happily talking to itself.
Teach PHP where to find MySQL
The database is up and running; now we need to give PHP the info it needs to access it. There's a thing called a socket that the two use to talk to each other. Like a lot of things in UNIX the socket looks like a file.
The default MySQL location for the socket is in /tmp, but MacPorts doesn’t play that way. There are a couple of reasons that /tmp is not an ideal place for the socket anyway, so we’ll do things the MacPorts way and tell PHP that the socket is not at the default location. To do this we edit /opt/local/etc/php56/php.ini.
There are three places where sockets are specified, and they all need to point to the correct place. Remember when you saved the socket variable from MySQL before? Copy that line and then search in your php.ini file for three places where is says default_socket:
pdo_mysql.default_socket = <paste here>
. . .
mysql.default_socket = <paste here>
. . .
mysqli.default_socket = <paste here>
In each case the whatever = part will already be in the ini file; you just need to find each line and paste in the correct path.
While we’re editing the file, you may want to set a default time zone. This will alleviate hassles with date functions later.
Finally, we need to install the PHP module that provides PHP with the code to operate on MySQL databases.
sudo port install php56-mysql
Restart Apache:
apache2ctl restart
Test the connection.
Typing
php56 -i | grep -i 'mysql'
Should get you a list of a few mysterious lines of stuff.
Second test: The whole bag of marbles. You ready for this?
In the Apache’s document root (where the index.php file you made before lives), create a new file named testmysql.php
DELETE THE FILE. It's got your root password in it!
sudo rm /opt/local/apache2/htdocs/testmysql.php
MILESTONE - Apache, PHP, and MySQL are all working together. High-five yourself, bud! You are an IT God!
Set up virtual hosts.
Finally, we will set up virtual hosts. This allows your server to handle more than one domain name. Even if you don't think you need more than one domain, it's a safe bet that before long you'll be glad you took care of this ahead of time.
We will create a file that tells Apache how to decide which directory to use for what request. There is an example file already waiting for us, so it gets pretty easy.
Tell Apache to use the vhosts file. To do this we make one last edit to httpd.conf. After this, all our tweaks will be in a separate file so we don’t have to risk accidentally messing something up in the master file.
In /opt/local/apache2/conf/httpd.conf, find the line that says
#Include conf/extra/httpd-vhosts.conf
and remove the #.
The # told Apache to ignore the include command. Take a look at all those other files it doesn’t include by default. Some of them might come in handy someday...
Save the file and restart Apache - the warnings you see will make sense soon.
Forbidden! What the heck!?! Right now, that's actually OK. The vhosts file is pointing to a folder that doesn't exist and even if it did it would be off-limits. All we have to do is modify the vhosts file to point to a directory that actually does exist, and tell Apache it's OK to load files from there.
Before going further, it's probably a good idea to figure out where you plan to put the files for your Web sites. I've taken to putting them in /www/<sitename>/public/ - not through any particular plan, but this gives me full control over permissions if I should ever need to chroot any of the sites. The Apple policy of putting sites in User can be useful, but really only if you plan to have one site per user. Otherwise permissions get tricky. The public part is so you can have other files associated with the site that are not reachable from the outside.
Set up the default host directory
Open /opt/local/apache2/conf/extra/httpd-vhosts.conf for editing.
You will see two example blocks for two different domains. Important to note that if Apache can’t match any of the domains listed, it will default to the first in the list. This may be an important consideration for thwarting mischief.
The examples provided in the file accomplish one of the two things we need to get done — they tell Apache what directory to use for each domain, but they do nothing to address what permissions Apache has in those directories. A lot of people put the permissions stuff in the main httpd.conf, but why not keep it all in one place and simplify maintenance while we reduce risk?
You can see where it sets what directory to go to, where it says to treat www.mydomain.com the same as mydomain.com, and then in the Directory block it sets permissions. The actual permissions instructions are pretty arcane. The most important thing to note is the line
AllowOverride none
This is not typical, but it's better, as long as you don't forget you did it.
Here's the skinny: A lot of web apps like WordPress and Drupal need to set special rules about how certain requests are handled. They use a file called .htaccess to set those rules. By setting AllowOverride none you're telling Apache to ignore those files. Instead, you can put those rules right in the <Directory> blocks in your vhosts file. It saves Apache the trouble of searching for .htaccess files on every request, and it's a more difficult target for hackers. .htaccess is for people who don't control the server. You do control the server, so you can do better.
If others will be putting sites on the server and you don't want them fiddling with the config files, you can allow .htaccess to override specific parameters. Read up in the Apache docs to learn more.
If you are using SSL, you also need to set up a VirtualHost entry for port 443. That entry will also include the locations of the SSL certificates.
Add further blocks that match the domains you will be hosting.
Restart Apache and test your setup. http://127.0.0.1 should go to your default directory. Testing the domains is trickier if you don’t have any DNS entries set up for that server. I’ll write up a separate document about using /etc/hosts to create local domains for this sort of test.
MILESTONE - You have done it. A fully operational LAMP environment on your Mac, suitable for professional Web hosting.
(Optional) Install phpMyAdmin
phpMyAdmin makes some database operations much easier. There have been security issues in the past, so you might reconsider on a production machine, but on a development server it can be a real time saver.
sudo port install phpMyAdmin
Update your Virtual Hosts with the domain you want to use to access phpMyAdmin, which is by default at /opt/local/www/phpmyadmin/
test - log in as root.
Configure - configuring phpMyAdmin fills me with a rage hotter than a thousand suns. It just never goes smoothly for me, whether I use their helper scripts or hand-roll it while poring over the docs. Maybe if I do it a few more times I’ll be ready to write a cookie-cutter guide for that, too. In the meantime, you’re better off getting advice on that one elsewhere.
Wrapping Up
I hope this guide was useful to you. I'm he kind of guy who learns by doing, and I've made plenty of mistakes in the past getting this stuff working. Funny thing is, when it goes smoothly, you wonder what the big deal was. Hopefully you're wondering that now.
If you find errors in this guide, please let me know. Things change and move, and I'd like this page to change and move with them.
Keep up to date: One of the big advantages of this install method is that updates to key software packages get to your server faster. Use that power. Run the update commands listed in step one regularly.
In the UNIX world, access to every little thing is carefully controlled. There's only one user who can change anything they want, and that user is named root.
When you log in on a Mac, you're not root, and good thing, too. But as an administrator, you can temporarily assume the root role. You do this by preceding your command with sudo. (That's an oversimplification, and you will have earned another Geek Point when you understand why. In the meantime, just go with it. sudo gives you power.)
When you use sudo, you type your password and if the system recognizes you as an administrator it will let you be root for that command.
For convenience, you only have to type your password every five minutes, but you do need to repeat 'sudo' for each command.
Just remember, as root you can really mess things up.
Jerry told me to edit the file, you lament, but he didn't say how. Kind of strange, considering the minute detail of the rest of the guide. The thing is, there's not one easy answer.
Let's start with the two kinds of text editors. There are editors like vim and pico that run right in terminal. They are powerful, really useful for editing files on a remote box, and if you know how to use them you're not reading this footnote. The other option is a windowed plain-text editor. TextEdit is NOT a plain-text editor. There are a lot of plain-text editors out there, and they all have their claims to fame. You can use any of them to edit these files.
Whoops! That brings us to the gotcha: permissions. In UNIX, who can change what is tightly controlled. Many of the files we need to edit are owned by root, the God of the Machine, so we need to get special permission to save our changes. Many of the plain-text editors out there will let you open the file, but when it comes time to save... they can't. You don't have permission.
Some editors handle this gracefully, however, and let you type your admin password and carry on. BBEdit and its (free) little brother TextWrangler give you a chance to type your password and save the file. I'm sure there are plenty of others that do as well.
BBEdit and TextWrangler also allow you to launch the editor from the command line, so where I say above edit ~/.profile, you can actually type edit ~/.profile and if you have TextWrangler installed, it will fire right up and you'll have taken care of the permissions issue. (If you decided to pay for BBEdit, the command is bbedit ~/.profile.) I'm sure there are plenty of other editors that do that too.
I'm really not endorsing BBEdit and TextWragler here; they just happen to be the tools I picked up first. Over time I have become comfortable with their (let's call them) quirks. Alas, finding your text editing answer is up to you. If you're starting down this path, it's only a matter of time before you pick up rudimentary vim or pico skills; eventually you'll be using your phone to tweak files while you're on the road. It's pretty empowering. But is now the time to start learning that stuff? Maybe not. It's your call.
The Caldecott and Newbery winners for literature have been announced… for 2012. The year’s barely under way and they already know who’s going to be the best! Science Fiction in action!
How would Magellan measure latitude if the sky were filled with clouds all the time? I’m thinking of measuring Coriolis effect, but I’d hate to dive into that if there’s a more obvious answer.
Several times a week I hop on the ol’ elliptical trainer and chug away for half an hour. When I’m done the glowing readout informs me I’ve burned off somewhere north of 500 Calories.
While recognizing that the number is little more than a wild-ass guess, I find myself wondering as I plod along, “Just how much does 500 Calories weigh?”
Well, of course it’s not that simple. Calories are a measure of energy, and while I haven’t done the math, if we apply M=E/C2 we end up with a very, very small number. But we’re not annihilating matter to produce energy, we’re oxidizing organic molecules. So, let’s think about the weight of the fuel required to produce 500 Calories.
Since we’re only dealing in wild-ass approximations anyway, let’s round things off to make the math easy. If all the molecules used to produce that energy were fat, we’re talking about 50 grams. That’s something like a shot of vegetable oil.
Not bad! If I burn off a shot-glass of fat each time I exercise, I’ll be skinny in a month!
Alas, even after many months, I’m not skinny. First problem, only a tiny fraction of those 500 Calories come from fat. Fat is long-term storage and my body hangs onto it tenaciously, saving against the month when there’s no food. For most of the history of our organism and its ancestors there have been such stretches, and the ones who held onto their fat when times were good survived when things were bad. So, when energy is needed, the first to burn is the short-term storage.
But hey! Great news! The sugars and other carbohydrates used for short-term storage weigh even more! Instead of burning 50 grams of fuel, I might be burning more like 100g.
Which are quickly and efficiently replaced by the food I eat. And while my body is at it, if I’m going to insist on burning all that energy, it’s going to build up muscle mass so I can burn the fuel more easily next time. Which increases the dense muscle tissue and makes me heavier — but healthier. Ahhh! It’s all so complicated! But I’m digressing here.
Regardless of the source of the fuel and whether I actually lose weight, I metabolize something like 100g of hydrocarbons while I exercise.
Where does it go?
The answer is pretty simple, but kind of cool. A lot of the weight I lose goes right out my nose. We breathe oxygen in, and, through a ridiculously complex system of events, that oxygen gets mixed up with hydrogen and carbon from our food. The carbon atoms, now hooked up with oxygen, are carted back to the lungs and exit each time we exhale. Food in, CO2 out.
The hydrogen atoms from the food also hook up with oxygen to form water, which leaks out of our bodies in a dozen different ways (mammals are live-fast-and-squander-water creatures). There are some other byproducts of our metabolisms, like nitrogen from burning protein, that make their way out in our pee.
But most of the mass (and hence weight) oxidized due to my time on the trainer flows out my nose. When the gentle chime tells me my travails are done, I’ve exhaled enough carbon to make a 500-carat diamond*. And each time, it’s a little bit easier.
If you read fantasy novels, you already know that there are a lot of writers who aren’t able or can’t be bothered to create settings and characters of their own. Perhaps even more annoying are the ones who just take the same old tired characters and put some transparent and irrelevant ‘twist’ on them. It doesn’t take a detective to unmask these efforts. In fact, it only takes a few questions. It’s a bonus if the questions are funny.
In the top section of the sidebar over there you will now find a link called Fantasy Novelist’s Exam Scoreboard. If you’ve been around a while you’ve heard me refer to the exam before; it’s a list of questions all aspiring fantasy novelists should ask before they get too far writing their epic. It’s a tongue-in-cheek list of seventy-five reasons to drop your project and start over. If you answer ‘yes’ to any question, it’s time to scrap the story.
Alas, there are dozens of stories published every year that do not follow this advice, and are riddled with lazy world-building and tired clichés. The creatures that occupy those worlds are defined in Dungeons and Dragons manuals.
Often as I’m reading these stories I’ve wished that I could have a checklist on hand to tally up the score as I read. Orc – check. Mysterious parentage – check. As the party for the quest (check) assembles, a few stock characters appear (check, check, check). There have even been a couple of stories I’ve read to the end only to see how many more recycled ideas drift through.
Now I have the technology! I can add a story to the database and as I encounter each example of literary laziness I can fire up the iPad or any other handy computer and add to the tally.
And you can, too! I’ve got it mostly set up so other people can add novels to the scoreboard as well. If anyone asks nicely, I’ll get them set up to add their experiences to what promises to be an important database in the world of literature. Or something like that.
As I write this, the only novel in the database is my unfinished fantasy parody, which weighs in at a whopping 17 points (so far). I’ll be adding a couple more titles shortly, and I also intend to integrate the code with Amazon, so the covers and other info will display automatically. That’s going to have to wait for a bit, however.
Anyway, take a look! I’ll probably put up a notification here or with a comment when I add a new novel, and you can watch the score increase as I read. What fun! The questions (the actual creative part of this endeavor) are from here; I just added the buttons.
I’d heard good things about Steig Larssen’s The Girl with the Dragon Tattoo, and when the movie came out my sweetie and I both thought we’d rather read the book before watching the movie. So, as a Christmas gift from us to us, we bought the book and its two sequels, and packed them along with us on the train.
IMPORTANT: If you don’t want to know who wins, STOP READING NOW! But really, you know already.
The books, all three of them, are pretty good. My sweetie and I may differ on which is the best; she hasn’t read them all yet, and so far I get the feeling our opinions diverge.
The first book is a mystery, while the second leans toward thriller. The third… I’ll get to that.
The Girl with the Dragon Tattoo puts a disgraced journalist in a position to solve a decades-old mystery and at the same time vindicate himself. The only problem is that a lot of talented people have spent a lot of time trying to solve the mystery, and all have failed. However none of those people had a 90-lb. dragon-tattooed social basket case who can hack just about anything helping them. Salander is pretty damn messed up. And with reason. Messed-up enough to carry a trilogy.
The start of the book is devoted to setting up the mystery. There’s tons of backstory about most of the main characters, long expositional dialogs, and then Blomkvist (the disgraced writer) gets a chapters-long exposition about the events of long ago.
I have to admit I got tired of all the exposition, especially since much of the backstory was then covered again in the natural discourse. At last all the setup is done and we can get on with the story. It’s a good story. As Blomkvist closes in on the answer to the original question, a new, larger evil looms, one still alive decades later and ready to kill any who come too close. It gets intense. Gritty, tight, anything-can-happen intense.
Then the book ends with five chapters or maybe more of literary masturbation. Let’s not talk about those.
Book two, The Girl Who Played with Fire was my favorite. It gets going and keeps going all the way through to the end. Funny thing here — it could be argued that this volume doesn’t end, which would put it right into my pet peeve wheelhouse. But the book does end, I say. Without giving too much away, the bad guys are stopped, the good guys are bleeding but probably not going to die, and if there was no third book, you could stop there and fill in the masturbatory chapters yourself.
What carries the story on is Salander’s past. She was not treated well, and it turns out the people responsible have a lot to lose. Book Three starts with a rapid undo of the conclusion of Book Two. Bad guys caught? Whoops! No! The cops were incompetent and for some reason see no problem with letting two people who tried to kill each other hang out in a hospital together without anyone watching them. Anyway, action resumes.
Then we get procedural. While I liked The Girl Who Kicked the Hornet’s Nest, it was my least favorite of the bunch. We see a lot of people doing a lot of things, and then other people doing other things, but for much of the book I didn’t get the feeling that the stakes were rising. Not for the central plot, anyway. I suppose this was supposed to be a chess match between the good guys and the bad guys, but the only source of tension was that the author deliberately withheld key parts of the good guys’ plan. Things got interesting after a while, when the bad guys start living up to their bad guy reputations. There’s also a crime that involves a gun that no one seems interested in tracing. Hm.
On the plus side, some of the character relationships do not follow the usual script. Alas, I can’t tell you about them. Just know that with my writer-cap on, I smiled.
I wonder if Steig Larssen heard the bell tolling and rushed the third book. It feels like a decent draft of a pretty good story. He just needed to go back and put Blomkvist’s balls into a slowly-closing vise, and find a better threat against Salander (top choice, Salander herself).
The end is reasonably satisfying, with a little more literary masturbation on the side. Maybe that’s why I like book two the most: Since Larssen planned to undo the ending anyway, he didn’t spend a lot of time adding public adulation towards the main characters. They fight through, and with talent and sheer will they prevail, and the story ends while they’re still bleeding. Maybe dying. But they won. We don’t have to know who made a bunch of money for a photo of a corrupt official being arrested, or how the television news validated our disgraced journalist. They won against evil, at terrible cost. The worldly rewards cheapen the victory.
A buddy of mine recently said (something like), “I read your reviews, and I like them, but it seems like you don’t like anything.” That’s actually not that close to what he said, but I have to admit I dwell on the negative more than the positive. Understand that the primary purpose of these critiques is to make myself a better writer (or at least a better editor). And honestly I have nothing against masturbation, it’s just that I don’t enjoy watching some Swedish guy do it.
All that said, these are good books. I liked them.
On a barely-related side note, while setting up the Amazon links above, I also found
I’ve had a bit of a tangle with Adobe recently. When it comes right down to it, their Web site makes it very difficult to find what you’re looking for, or even to figure out what product is best for you. This has led to a few frustrating days of going around in circles, trying to find someone to help me rectify a mistake caused by the “click Mac and get Windows” feature of the site.
This is apparently a pretty common problem for people to have, and there are instructions telling just what to do about it. Much of the time the instructions are not very helpful, however. After a day of futility I decided that I would do whatever it took to get a human on the line.
Easier said than done. For instance, the “Schedule a callback for another time” feature invariably returns with the message “No immediate callback available. Try again later.” I thought maybe the more-secure settings in Safari were causing a problem, so I tried again with Firefox. Same result.
Finally I connected by chat with a nice guy who was not empowered to execute the obvious, simple, and immediate solution to the problem. We had to do it the hard way.
Somewhere during my latest futile rummaging around on the site (“Click here for instructions”, then the instructions saying to go right back where you were, and so forth), a window popped up asking if I wanted to answer some questions about my experience.
You’re damn skippy I wanted to answer some questions. When my latest exercise in circular navigation was complete, the survey came up. “Neutral third party,” I was assured. “No specific identity info recorded.” I took the survey, being sure to give credit in the few places it was due. I answered the essay questions with specifics. In the end, I clicked ‘submit’.
“System not working at this time,” the message said.
Many of you out there have heard me rail against the verb ‘login’. You would never say ‘I loginned to the Interwebs.’
‘Log’ is the verb. In the case of technology the verb is followed by a prepositional phrase starting with ‘in’ or ‘into’ to describe where the logging happened.
Thank you, Adobe Systems, for taking my pet peeve to the new absurdity. In an official communication I have been instructed as follows (copy-paste here, so the capitalization is also theirs): Login into Your Account with the ID listed above
Yeah. Login into. Is anybody reading this before it goes out?
, or a new car), I get a kickback.