I recently needed to add a wildcard SSL certificate, purchased from Network Solutions, to an AWS EC2 instance running Ubuntu 12.04. Here’s the steps I followed for success:
I recently worked on a project where we dynamically displayed page content with a single PHP script. But we didn’t want to display the PHP script name, variables and their values in the URL.
Apache runs very slowly in Mac OS X 10.7.1 Lion. I checked out the /etc/apache2/httpd.conf file and noticed that Apple shipped Lion with every single module turned on, meaning Apache is chewing up a lot of memory and CPU cycles on modules that (typically) aren’t needed!
Here’s how to reclaim the speed of Snow Leopard in Mac OS X Lion’s Apache configuration:
First, make a backup of /etc/apache2/httpd.conf.
Next, edit /etc/apache2/httpd.conf in your favorite editor.
Search for LoadModule.
Then, comment out the modules that you don’t need by adding a hash character (#) at the beginning of the line. Be judicious in what you turn off. For example, I turned off mod_userdir.so, which then caused Apache to fail on startup.
Running httpd -t from the terminal showed that Apple’s default httpd.conf file is using the mod_userdir.so module, so I left it on (since it presumably supports using home directories for serving Sites).
For me, the modules I turned off are:
#LoadModule authn_dbm_module libexec/apache2/mod_authn_dbm.so
#LoadModule authn_anon_module libexec/apache2/mod_authn_anon.so
#LoadModule authn_dbd_module libexec/apache2/mod_authn_dbd.so
#LoadModule authn_default_module libexec/apache2/mod_authn_default.so
#LoadModule authz_groupfile_module libexec/apache2/mod_authz_groupfile.so
#LoadModule authz_user_module libexec/apache2/mod_authz_user.so
#LoadModule authz_dbm_module libexec/apache2/mod_authz_dbm.so
#LoadModule authz_owner_module libexec/apache2/mod_authz_owner.so
#LoadModule authz_default_module libexec/apache2/mod_authz_default.so
#LoadModule auth_basic_module libexec/apache2/mod_auth_basic.so
#LoadModule auth_digest_module libexec/apache2/mod_auth_digest.so
#LoadModule dbd_module libexec/apache2/mod_dbd.so
#LoadModule mime_magic_module libexec/apache2/mod_mime_magic.so
#LoadModule unique_id_module libexec/apache2/mod_unique_id.so
#LoadModule proxy_connect_module libexec/apache2/mod_proxy_connect.so
#LoadModule proxy_ftp_module libexec/apache2/mod_proxy_ftp.so
#LoadModule proxy_scgi_module libexec/apache2/mod_proxy_scgi.so
#LoadModule proxy_ajp_module libexec/apache2/mod_proxy_ajp.so
#LoadModule dav_module libexec/apache2/mod_dav.so
#LoadModule dav_fs_module libexec/apache2/mod_dav_fs.so
#LoadModule bonjour_module libexec/apache2/mod_bonjour.so
#LoadModule fastcgi_module libexec/apache2/mod_fastcgi.so
Good news out of Cupertino. Apple’s new operating system, Mac OS X 10.7 Lion ships with a newer version of PHP (5.3.6), which has been compiled with GD, freetype, tidy (libtidy), and lots of other goodness.
Additionally, Apple has chosen to compile PHP with Suhosin Patch 0.9.10, which purports to substantially harden PHP. From the Suhosin web site: “It was designed to protect your servers on the one hand against a number of well known problems in PHP applications and on the other hand against potential unknown vulnerabilities within these applications or the PHP core itself.”
Apache on Mac OS X is configured with security in mind. Apple has chosen to ship it with a setting that causes the x-frame-options header to be sent, which has the effect of causing content hosted on a Mac OS X server to not show up inside and iframe on another site.
Well-written web apps (like WordPress) already send the x-frame-options header. My personal preference is to turn this off globally and then ensure that my web apps send it as needed.
Here’s how to disable it:
So, you need GD for your killer PHP web app, and you’re running Mac OS X 10.5? A quick look shows that GD doesn’t ship with Leopard. No worries. It’s pretty simple to install.
Apple’s new Mac OS X 10.5 (Leopard) changes how web sharing is set up. Thankfully, they’ve moved us all to Apache 2 codebase (a good thingâ?¢). But in doing so, they’ve disabled the ability to serve web pages contained in your home Site directory.
If you turn on Web Sharing from the System Preferences panel, it works for the main computer (http://localhost) but not for user accounts (http://localhost/~username/). Most perplexing is that Apple’s graphical interface confirms that web sharing is turned on for your personal account, but it doesn’t work. This is *very* un-Apple.
Even if you turn on web sharing from the System Preferences panel, you’ll still receive the dreaded
403 Forbidden. You don't have permission to access /~username/ on this server.
Thankfully, it’s a simple oversight on Apple’s part. Your options are two-fold. You can either set it up to activate the Sites directory in all your user accounts, or just for individual ones. I’ll cover both. Continue reading