Expat-IT Tech Bits




Search this site:


/ (289)
  Admin/ (123)
    Apache/ (10)
      HTTPS-SSL/ (4)
      PHP/ (3)
      performance/ (2)
    Cherokee/ (1)
    LAN/ (4)
    LVM/ (6)
    Monitoring/ (2)
      munin/ (2)
    SSH/ (6)
    SSL/ (1)
    Samba/ (1)
    VPN-options/ (7)
      OpenVPN/ (1)
      SSH-Proxy/ (3)
      Tinc/ (1)
      sshuttle/ (1)
    backups/ (17)
      SpiderOak/ (1)
      backuppc/ (5)
      dirvish/ (1)
      misc/ (6)
      rdiff-backup/ (1)
      rsync/ (1)
      unison/ (2)
    commandLine/ (24)
      files/ (8)
      misc/ (10)
      network/ (6)
    crontab/ (1)
    databases/ (15)
      MSSQL/ (2)
      MySQL/ (8)
      Oracle/ (3)
      PostgreSQL/ (1)
    dynamicDNS/ (2)
    email/ (11)
      Dovecot/ (1)
      deliverability/ (1)
      misc/ (1)
      postfix/ (7)
      puppet/ (1)
    iptables/ (3)
    tripwire/ (1)
    virtualization/ (9)
      VMware/ (1)
      virtualBox/ (8)
  Coding/ (14)
    bash/ (1)
    gdb/ (1)
    git/ (3)
    php/ (5)
    python/ (4)
      Django/ (2)
  Education/ (1)
  Hosting/ (27)
    Amazon/ (18)
      EBS/ (3)
      EC2/ (10)
      S3/ (1)
      commandline/ (4)
    Godaddy/ (2)
    NearlyFreeSpeech/ (3)
    Rackspace/ (1)
    vpslink/ (3)
  Linux/ (31)
    Android/ (1)
    Awesome/ (3)
    CPUfreq/ (1)
    China/ (2)
    Debian/ (8)
      APT/ (3)
      WPA/ (1)
    audio/ (1)
    encryption/ (3)
    fonts/ (1)
    misc/ (6)
    remoteDesktop/ (1)
    router-bridge/ (3)
  SW/ (45)
    Micro$soft/ (1)
    browser/ (2)
      Chrome/ (1)
      Firefox/ (1)
    business/ (28)
      Drupal/ (9)
      KnowledgeTree/ (6)
      Redmine/ (2)
      SugarCRM/ (7)
      WebERP/ (2)
      WordPress/ (1)
      eGroupware/ (1)
    chat/ (1)
    email/ (1)
    fileSharing/ (2)
      btsync/ (1)
      mldonkey/ (1)
    graphics/ (2)
    research/ (2)
    website/ (6)
      blog/ (6)
        blosxom/ (3)
        rss2email/ (1)
        webgen/ (1)
  Security/ (15)
    IMchat/ (2)
    circumvention/ (2)
    cryptoCurrency/ (1)
    e-mail/ (4)
    greatFirewall/ (1)
    hacking/ (1)
    password/ (1)
    privacy/ (2)
    skype/ (1)
  Services/ (1)
    fileSharing/ (1)
  TechWriting/ (1)
  xHW/ (14)
    Lenovo/ (1)
    Motorola_A1200/ (2)
    Thinkpad_600e/ (1)
    Thinkpad_a21m/ (3)
    Thinkpad_i1300/ (1)
    Thinkpad_x24/ (1)
    USB_audio/ (1)
    scanner/ (1)
    wirelessCards/ (2)
  xLife/ (17)
    China/ (9)
      Beijing/ (5)
        OpenSource/ (3)
    Expatriation/ (1)
    Vietnam/ (7)


  • 2019/06
  • 2016/07
  • 2016/05
  • 2016/02
  • 2016/01
  • 2015/12
  • 2015/11
  • 2015/06
  • 2015/01
  • 2014/12
  • 2014/11
  • 2014/10
  • 2014/09
  • 2014/07
  • 2014/04
  • 2014/02
  • 2014/01
  • 2013/12
  • 2013/10
  • 2013/08
  • 2013/07
  • 2013/06
  • 2013/05
  • 2013/04
  • 2013/02
  • 2013/01
  • 2012/12
  • 2012/10
  • 2012/09
  • 2012/08
  • 2012/07
  • 2012/06
  • 2012/05
  • 2012/04
  • 2012/03
  • 2012/01
  • 2011/12
  • 2011/11
  • 2011/10
  • 2011/09
  • 2011/08
  • 2011/07
  • 2011/06
  • 2011/05
  • 2011/04
  • 2011/02
  • 2010/12
  • 2010/11
  • 2010/10
  • 2010/09
  • 2010/08
  • 2010/07
  • 2010/06
  • 2010/05
  • 2010/04
  • 2010/03
  • 2010/02
  • 2010/01
  • 2009/12
  • 2009/11
  • 2009/10
  • 2009/09
  • 2009/08
  • 2009/07
  • 2009/06
  • 2009/05
  • 2009/04
  • 2009/03
  • 2009/02
  • 2009/01
  • 2008/12
  • 2008/11
  • 2008/10
  • 2008/09
  • Subscribe XML RSS Feed

    Creative Commons License
    This work is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License.

    This site has no ads. To help with hosting, crypto donations are accepted:
    Bitcoin: 1JErV8ga9UY7wE8Bbf1KYsA5bkdh8n1Bxc
    Zcash: zcLYqtXYFEWHFtEfM6wg5eCV8frxWtZYkT8WyxvevzNC6SBgmqPS3tkg6nBarmzRzWYAurgs4ThkpkD5QgiSwxqoB7xrCxs

    Thu, 24 Dec 2015

    /Admin/Apache/PHP: Best Practices for Custom PHP Parameters

    First, do not edit php.ini, instead add a file to


    called something like php_ini_local.ini, for instance. Place parameters you would like to customize like upload_max_filesize in there, and they will take precedence over those in the php.ini file(s). And this way php.ini will in future also upgrade gracefully to newer versions without manual intervention.

    To test parameter changes (before and after) the simple way, use PHP CLI in a terminal:

    # php -a <?php echo ini_get('upload_max_filesize'); ?> Ctrl-d

    posted at: 03:47 | path: /Admin/Apache/PHP | permanent link to this entry

    Sat, 11 May 2013

    /Admin/Apache/performance: Apache/PHP Modules to Increase Performance

    Note that one can monitor progress with these changes using Google's analysis page at https://developers.google.com/speed/pagespeed/insights


    One of the cheapest things you can do server-side is leverage browser caching with mod_expires[1]. Apparently[2], even if a file is already in the browser cache, the browser will still query the server on every hit to see if the file has changed. No, the file is not transferred if it has not changed, but yes, there is still a demand made of the server. Unless you turn on mod_expires, which tells the browser in advance how long the file is good for. And thereafter, until the file expires, the browser will not bother the server to check if it has changed. Other then turning it on, there is little to configure with mod_expires except possibly to specify the expiry times in your VirtualHost or in global config file in the conf.d directory, for example:

            ExpiresActive on
            ExpiresDefault "access plus 1 hour"
            ExpiresByType image/jpg "access 1 week"
            ExpiresByType image/jpeg "access 1 week"
            ExpiresByType image/gif "access 1 week"
            ExpiresByType image/png "access 1 week"
            ExpiresByType text/css "access 1 week"
            ExpiresByType application/pdf "access 1 week"
            ExpiresByType text/x-javascript "access 1 week"

    Caching: mod_cache / mod_disk_cache:

    Here my reading[4] would seem to indicate that if the server is not proxying, ie. all content is already in the local file system, the kernel can be expected to do a fine job of memory-caching of files without any need for help from Apache. So in the absence of proxying, I have NOT turned on mod_mem_cache, just mod_disk_cache[3]. Debian/Ubuntu, as usual, comes fitted with sane defaults which include turning on the htcacheclean[5] daemon to prune cache content. The only configuration required is, again, to turn on caching for specific VirtualHosts by adding:
    CacheEnable disk /

    PHP Opcode Caching: APC:

    There are three commonly mentioned possibilities for PHP opcode caching: eAccelerator, APC[6], and XCache. I do not see much to choose from between them performance-wise, but APC seems to be a very native PHP project, so I will go with that:

    apt-get install php-apc

    The first thing you will want to do is copy apc.php into some web root and have a look. There, apparently the most important thing to check[7] is "Cache full count" which you want to keep pretty close to zero. To get there, I increased my cache size in /etc/php5/conf.d/apc.ini to:


    Google Page Speed Module:

    Get and install your preferred version of the module from [8], ie.

    wget https://dl-ssl.google.com/dl/linux/direct/mod-pagespeed-stable_current_amd64.deb
    dpkg -i mod-pagespeed-stable_current_amd64.deb
    /etc/init.d/apache2 restart

    [1] https://httpd.apache.org/docs/2.0/mod/mod_expires.html
    [2] http://bytes.com/topic/apache/insights/740981-advanced-caching-mod_expires
    [3] https://httpd.apache.org/docs/2.2/mod/mod_cache.html
    [4] https://httpd.apache.org/docs/2.2/caching.html
    [5] https://httpd.apache.org/docs/2.2/programs/htcacheclean.html
    [6] http://php.net/apc
    [7] http://php.net/manual/en/apc.configuration.php
    [8] https://developers.google.com/speed/docs/mod_pagespeed/download

    posted at: 05:28 | path: /Admin/Apache/performance | permanent link to this entry

    Sat, 12 May 2012

    /Admin/Apache/PHP: How to Disable PHP Errors in a Specific Apache VirtualHost

    Add this line to the VirtualHost:

    php_value error_reporting 0

    [1] http://www.php.net/manual/en/function.error-reporting.php
    [2] http://www.php.net/manual/en/errorfunc.constants.php

    posted at: 06:23 | path: /Admin/Apache/PHP | permanent link to this entry

    Sun, 12 Dec 2010

    /Admin/Apache/performance: Apache Performance Tuning

    I am running my personal server on a rather small Rackspace Cloud machine with 256M of memory. A default LAMP (plus a couple Python web apps) install seems to occasionally (my websites are usually not THAT busy) choke and force a reboot. Let's try and avoid that:

    First thing I did was install a PHP op code cache called php5-xcache that I have used before. It is a zero configuration slam-dunk, and my spidy sense suggests that it produces a tangible speed improvement.

    All of the reading I am doing (see references below) prominently mention unloading unused Apache modules so as to reduce the memory footprint of Apache processes, so this seems like the first place to start. This is a minimal (not requiring hacking my default Ubuntu server Apache configuration too much) list of Apache modules I can get by on at the moment:

    alias.conf cgi.load dir.conf mime.conf php5.load ssl.load wsgi.conf alias.load deflate.conf dir.load mime.load rewrite.load status.conf wsgi.load authz_host.load deflate.load headers.load php5.conf ssl.conf status.load

    Now into the murky world of Apache MPM (Multi-Processing Modules). Reading the "Compile-Time Configuration Issues" section in [4], one is left with the definite impression that the worker MPM would be a better choice then the prefork MPM in a limited memory situation. So why does prefork always seem to be installed? A little experiment tells all:

    apt-get install apache2-mpm-worker

    will result in the removal not only of apache2-mpm-prefork, but also all PHP modules! [5] has the answer:

    "Apache PHP module is reputed to be unstable in multi-threaded environments"

    [5] goes on to describe a somewhat complicated procedure for making the multi-threaded apache2-mpm-worker module work with PHP. Maybe later, if all else fails. Or maybe switch to lighttpd as a web server. Now back to the stodgy old Apache prefork MPM....

    [6] gives some nice details on how one might go about optimizing the prefork MPM configuration. top is telling me that my Apache processes are currently consuming roughly 30+M per process. My current default configuration is this:

    <IfModule mpm_prefork_module> StartServers 5 MinSpareServers 5 MaxSpareServers 10 MaxClients 150 MaxRequestsPerChild 0 </IfModule>
    which I am going to crank WAY down to this:
    <IfModule mpm_prefork_module> StartServers 1 MinSpareServers 1 MaxSpareServers 2 MaxClients 5 MaxRequestsPerChild 200 </IfModule>

    Interesting that the default value of MaxRequestsPerChild was zero. Apparently the point of setting this value to non-zero is to periodically force Apache processes to be killed and recreated, to combat memory bloat (aparently they do not release memory?). It is also worth noting that my server's CPU usage tends to hangout near zero, while memory is always maxed out and swapping is a regular cause of problems. In top I have seen a single Apache process top out at as high as 50% of memory. I think killing processes frequently to reduce memory overhead is probably the way to go.

    And finally, [6] recommends setting a really small KeepAliveTimeout of 2. And [7] recommends keeping "Timeout" small, since I have so few processes and do not want them all to be waiting for a timeout at the same time. So I went for a Timeout of only 10 seconds.

    [1] http://wiki.vpslink.com/Low_memory_MySQL_/_Apache_configurations
    [2] http://docs.quantact.com/tuning-mysql-apache-for-low-memory
    [3] http://groups.drupal.org/node/27174
    [4] http://httpd.apache.org/docs/2.0/misc/perf-tuning.html
    [5] http://blog.fosketts.net/2010/07/30/high-performance-memory-apache-php-virtual-private-server/
    [6] http://www.devside.net/articles/apache-performance-tuning
    [7] http://www.360doc.com/content/07/1210/14/15540_883932.shtml

    posted at: 22:05 | path: /Admin/Apache/performance | permanent link to this entry

    Sat, 02 Oct 2010

    /Admin/Apache: Django on Apache Using mod_wsgi on CentOS 5

    These [1][2] would indicate mod_wsgi is the best way to server Django sites using Apache.

    mod_wsgi does not seem to exist in the CentOS 5 repositories. Using this[3] as my guide, I installed from source as follows:

    cd /usr/lib/python2.4/config
    ln -s ../../../lib64/libpython2.4.so .
    wget http://modwsgi.googlecode.com/files/mod_wsgi-3.3.tar.gz
    tar -xf mod_wsgi-3.3.tar.gz
    cd mod_wsgi-3.3
    yum install httpd-devel
    ./configure --with-python=/usr/bin/python2.4
    make install

    That all seemed to go well, and now I see this file: /usr/lib64/httpd/modules/mod_wsgi.so

    Turn this module on in Apache, by adding the following lines to /etc/httpd/conf/httpd.conf:

    LoadModule wsgi_module /usr/lib64/httpd/modules/mod_wsgi.so
    AddHandler wsgi-script .wsgi

    After "/etc/init.d/httpd restart" apache is still working. A very good sign.....

    It is worth noting that the reference[3] I am using for this also installed Python2.5 from source at the start of the whole process. CentOS 5 only has Python2.4. The reference did not justify why this was done, lets just cross our fingers and hope it will not be necessary.

    Now lets see if we can get Apache to server up my helloWorld Django site. This[4] seems to be the most authoritative document I can find on the subject.

    cd /var/www/html/django/chinawanderer
    mkdir apache
    Create file /var/www/html/django/chinawanderer/apache/django.wsgi which contains the following:
    import os, sys
    os.environ['DJANGO_SETTINGS_MODULE'] = 'chinawanderer.settings'
    import django.core.handlers.wsgi
    application = django.core.handlers.wsgi.WSGIHandler()
    Add this to /etc/httpd/conf/httpd.conf:
    WSGIScriptAlias / /var/www/html/django/chinawanderer/apache/django.wsgi <Directory /var/www/html/django/chinawanderer/apache/> Order deny,allow Allow from all </Directory>
    And it works. Django in action: http://domain.com/django/chinawanderer/

    [1] http://docs.djangoproject.com/en/dev/howto/deployment/
    [2] http://docs.djangoproject.com/en/dev/howto/deployment/modwsgi/
    [3] http://taoyh163.blog.163.com/blog/static/19580356200971104043225/
    [4] https://code.google.com/p/modwsgi/wiki/IntegrationWithDjango

    posted at: 09:46 | path: /Admin/Apache | permanent link to this entry

    Fri, 09 Oct 2009

    /Admin/Apache/PHP: Increase File Upload Limit in php.ini

    (Note: php.ini changes apply to *all* PHP apps on the server.)

    If you are getting the error:

    Upload larger than maximum POST size (post_max_size variable in .htaccess or php.ini)

    There is no simple one parameter solution. I found some good posts here:

    I made the following changes in /etc/php5/apache2/php.ini:

    post_max_size = 300M
    upload_max_filesize = 300M
    max_execution_time = 3600
    max_input_time = 3600

    which should present a maximum file upload limit of 300M and a timeout of one hour.

    posted at: 23:26 | path: /Admin/Apache/PHP | permanent link to this entry

    Wed, 16 Sep 2009

    /Admin/Apache/HTTPS-SSL: Desktop Apache https Quick Start

    I expect to be accessing some services on my laptop via Apache over an untrusted network in the near future, so I need to turn on SSL.

    As usual, turn on the Apache SSL module:

    cd /etc/apache2/mods-enabled/
    ln -s ../mods-available/ssl.conf .
    ln -s ../mods-available/ssl.load .
    and the default SSL configuration:
    cd /etc/apache2/sites-enabled/
    ln -s ../sites-available/default-ssl 001-default-ssl

    Now restart Apache and it just works!? Apparently there is a "snakeoil" certificate already in place to get the job done. Trivial. Thank you, Debian Apache packagers.

    posted at: 09:23 | path: /Admin/Apache/HTTPS-SSL | permanent link to this entry

    Thu, 02 Apr 2009

    /Admin/Apache/HTTPS-SSL: SSL Certificates 101

    Generally speaking, it would appear that a vanilla single root SSL certificate, self-signed or otherwise, is only good for exactly one domain that corresponds exactly to the "common name" used in creating the certificate.

    Some vendors[1] sell something called a "wildcard" certificate, where the common name on the certificate takes the form of "*.domain.com", and can be used to secure multiple sub-domains. Such a "wildcard" certificate, not suprisingly, seems to be considerably more expensive then a single root certificate. Apache even provides a built-in mechanism using a document root wildcard[2] for mapping each sub-domain to a different document root.

    Some vendors like Godaddy[3] sell multiple domain certificates which seem to provide a discount to purchasing the same number of single root certificates.

    A good source for a free certificate is cacert.org[4]. cacert.org will sign a certificate for you for a domain if your e-mail address is in the whois record for the domain (this is an automated process on their end, they verify your identity by sending you a link in an e-mail ....) The Apache website[5] has a nice concise explanation of how to create a server key and certificate signing request for cacert.org (or anyone else....)

    Basically the process is[7]:

    cacert.org certificates seem to be good for six months. They send you an e-mail in advance of expiry.

    For a particular SSL-enabled Apache virtual host, force users to always use https by placing a redirect in http virtual host, ie.:

    <VirtualHost *:80> DocumentRoot /var/www/vsc/apps ServerName apps.vancouversolidcomputing.com ServerAlias apps.vancouversolidcomputing.com ServerAdmin ckoeni@gmail.com CustomLog /var/log/apache2/access.log combined Redirect / https://apps.vancouversolidcomputing.com/ </VirtualHost>

    [1] http://www.sslshopper.com/best-ssl-wildcard-certificate.html
    [2] http://phaseshiftllc.com/archives/2008/10/27/multiple-secure-subdomains-with-a-wildcard-ssl-certificate
    [3] http://www.godaddy.com/gdshop/ssl/ssl.asp?ci=9039
    [4] https://www.cacert.org/
    [5] http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#realcert
    [6] http://httpd.apache.org/docs/2.0/ssl/ssl_faq.html#removepassphrase
    [7] http://www.cacert.org/help.php?id=6
    [8] http://www.cacert.org/help.php?id=4

    posted at: 00:57 | path: /Admin/Apache/HTTPS-SSL | permanent link to this entry

    /Admin/Apache/HTTPS-SSL: Multiple SSL Certificates in Apache

    As I noted in an earlier post, name-based virtual hosting "seemed" to be working. "Seemed". In fact, the virtual hosts were finding the correct web root and loading the correct site, but browsers were consistently giving an error to the effect that the domain name in the certificate and the domain name the browser was pointed to were not the same.

    Someone on the cacert.org e-mail list[1] set me straight:

    From: Pete Stephenson
    To: cacert-support@lists.cacert.org
    Subject: Re: Certificate somehow associated with wrong sub-domain?
    Both subdomains share the same IP address.
    SSL is IP-based, rather than name-based. Specifically, when a client
    connects to a server, it establishes the SSL connection prior to
    sending the HTTP Host header, so the server has no idea which specific
    certificate to send. Depending on the server, it may send the first
    certificate mentioned in the configuration file or do something else
    You can solve this by adding multiple SubjectAltNames to a certificate
    (e.g. you'd have a SAN for apps.vancouversolidcomputing.com and
    another one for vsc.vancouversolidcomputing.com all in a single
    certificate) and telling your server to use the same certificate for
    both subdomains.
    More details, including a handy shell script which can generate the
    required CSR (some options, like the RSA key length are manually
    configurable in the shell script; it doesn't prompt the user for the
    keylength), are available here:

    So what I take from this is:

    This page[2] talks about the issue in general, and the various somewhat fuzzy and partially supported options -- "Currently the different browsers, servers and CAs all implement different and incompatible ways to use SSL certificates for several VHosts on the same server" -- this situation has not been entirely standardized yet!

    This page[3] seems to recommend the cacert.org way to setup Apache with the right kind of multiple SubjectAltName certificate, complete with a script[4] for generating an appropriate Certificate Request and associated key. I used the script to generate the request, and sure enough:

    # openssl req -noout -text -in vancouversolidcomputing_csr.pem Certificate Request: Data: Version: 0 (0x0) Subject: CN=www.vancouversolidcomputing.com <snip> Requested Extensions: X509v3 Subject Alternative Name: DNS:www.vancouversolidcomputing.com, DNS:vancouversolidcomputing.com, DNS:printshopdemo.vancouversolidcomputing.com, DNS:vsc.vancouversolidcomputing.com , DNS:solid.vancouversolidcomputing.com, DNS:apps.vancouversolidcomputing.com, DNS:ofri.vancouversolidcomputing.com <snip>

    out comes a Certificate Request with multiple SubjectAltNames.

    I then replaced *all* certificates in my Apache virtual hosts with this new certificate, ie.

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/vancouversolidcomputing_crt.pem
    SSLCertificateKeyFile /etc/apache2/ssl/vancouversolidcomputing_privatekey.pem

    in each virtual host block for each sub-domain / web root.

    The certificate now works flawlessly in Iceape (which apparently contains the cacert.org Certificate Authority information) and Internet Explorer still complains about an untrusted Certificate Authority. Neither complains about domain names not matching, which was happening before.

    [3] contained several other directives in each of the SSL virtual host blocks:

    UseCanonicalName On
    SSLCipherSuite HIGH
    SSLProtocol all -SSLv2

    but I have so far found these unnecessary.

    [1] https://lists.cacert.org/wws/info/cacert-support
    [2] http://wiki.cacert.org/wiki/VhostTaskForce
    [3] http://wiki.cacert.org/wiki/CSRGenerator
    [4] http://svn.cacert.org/CAcert/Software/CSRGenerator/csr

    posted at: 00:30 | path: /Admin/Apache/HTTPS-SSL | permanent link to this entry

    Sat, 14 Mar 2009

    /Admin/Apache/HTTPS-SSL: Turn on SSL in Apache

    Turn on the SSL module:

    cd /etc/apache2/mods-enabled/
    ln -s ../mods-available/ssl.conf .
    ln -s ../mods-available/ssl.load .
    /etc/init.d/apache2 restart

    In Debian, /etc/apache2/mods-enabled/ports.conf should already have logic to listen on the default port 443 if the SSL module is loaded.

    Now create a self-signed certificate (tinyca is a nice simple GUI that will do the job....) Just enter minimal information, and export the newly generated cert and key to files, being careful to set the expiration date nice and long, and export the key WITHOUT a password (otherwise you will have to provide a password every time apache is restarted).

    Copy the exported certificate files to your server, into directory /etc/apache2/ssl. Now create an SSL block in the Apache Virtual Host where you would like SSL. The *:80 block will respond to normal http requests, and the *:443 block will respond to https (SSL) requests:

    <VirtualHost *:80> DocumentRoot /var/www/webroot ServerName subdomain.domain.com ServerAlias subdomain.domain.com ServerAdmin webmaster@domain.com CustomLog /var/log/apache2/access.log combined </VirtualHost> NameVirtualHost *:443 <VirtualHost *:443> DocumentRoot /var/www/webroot ServerName subdomain.domain.com ServerAlias subdomain.domain.com ServerAdmin webmaster@domain.com CustomLog /var/log/apache2/access.log combined SSLEngine on SSLCertificateFile /etc/apache2/ssl/cert.pem SSLCertificateKeyFile /etc/apache2/ssl/key.pem </VirtualHost>

    I am not sure why the 443 block requires a NameVirtualHost line and the 80 block does not. Interestingly enough, this[2] says "Name-based virtual hosting cannot be used with SSL secure servers because of the nature of the SSL protocol", which might have something to do with it? But despite this[3] I currently HAVE got name-based virtual hosting working on SSL, unless there is something I do not understand here.

    Here is a useful reference[1], in addition to the installed apache docs.

    [1] http://www.debian-administration.org/articles/349
    [2] http://httpd.apache.org/docs/2.2/vhosts/name-based.html
    [3] http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts

    posted at: 02:01 | path: /Admin/Apache/HTTPS-SSL | permanent link to this entry