Saturday, April 27, 2013

How do I set up Apache virtual hosts on a Debian based Linux machine and configure to support HTTPS?

Preliminary quick note, if you haven't enabled ssh keys between your local machine and your remote machine, I recommend that you do. I just posted a how to on this you can check out here: http://oneqonea.blogspot.com/2013/04/how-do-i-set-up-ssh-keys-and-turn-off_27.html

Okay, now on to virtual host configuration! Connect to your remote machine (hopefully via ssh keys!):
ssh -p your_port you@your_ip_address
Then run the following command:
sudo mkdir -p /etc/apache2/ssl/your_site.com
Then run the following command:
sudo openssl req -new -x509 -days 365 -nodes -out /etc/apache2/ssl/your_site.com/apache.pem -keyout /etc/apache2/ssl/your_site.com/apache.pem
You'll see the following output:
Generating a 1024 bit RSA private key
..++++++
...........................++++++
writing new private key to '/etc/apache2/ssl/your_site.com/apache.pem'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]: # your input here...
State or Province Name (full name) [Some-State]: # your input here...
Locality Name (eg, city) []: # your input here...
Organization Name (eg, company) [Internet Widgits Pty Ltd]: # your input here...
Organizational Unit Name (eg, section) []: # your input here...
Common Name (eg, YOUR name) []: # your input here...
Email Address []: # your input here...
Now enable ssl within apache:
sudo a2enmod ssl
You'll see the following output:
Enabling module ssl.
See /usr/share/doc/apache2.2-common/README.Debian.gz on how to configure SSL and create self-signed certificates.
Run '/etc/init.d/apache2 restart' to activate new configuration!
We don't need to restart apache at the moment as we still have work to do! Also note, you can open and read the file they recommend and get apache config info straight from the horse's mouth too if you want! Here's a blog post that shows you the content of that file: http://oneqonea.blogspot.com/2013/04/whats-best-place-to-look-for-how-to.html

While we're at it let's enable apache's mod_rewrite too:
sudo a2enmod rewrite
Again, it's not necessary to restart your server at this time.

Next we're going to set up our virtual hosts. Run the following command:
sudo cp /etc/apache2/sites-available/default /etc/apache2/sites-available/your_site.com
Then run:
sudo nano /etc/apache2/sites-available/your_site.com
Update it with your site's info (and set "AllowOverride" to "All" to enable .htaccess files):
<VirtualHost *:80>
        ServerAdmin admin@your_site.com
        ServerName your_site.com
        ServerAlias www.your_site.com

        DocumentRoot /home/admin/your_site.com/www
        <Directory />
                Options FollowSymLinks
                AllowOverride None
        </Directory>
        <Directory /home/admin/your_site.com/www/>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>

        ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
        <Directory "/usr/lib/cgi-bin">
                AllowOverride None
                Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
                Order allow,deny
                Allow from all
        </Directory>

        ErrorLog /error.log

        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn

        CustomLog /access.log combined
</VirtualHost>
Also, be sure to add ServerName your_site.com and ServerAlias www.your_site.com after the ServerAdmin line (so you'll be in a position to host multiple https sites on a single machine).

Now, we need to create almost the exact same thing in the same file but wrap the config settings in <VirtualHost *:443> rather than <VirtualHost *:80>, to do this easily, run the following series of commands:
su root
Then run the following TWO commands as root (we're appending to the new file so we want to run the same command twice):
cat /etc/apache2/sites-available/your_site.com >> /etc/apache2/sites-available/new_temp
cat /etc/apache2/sites-available/your_site.com >> /etc/apache2/sites-available/new_temp
Then exit from root:
exit
Then replace your old file:
sudo mv /etc/apache2/sites-available/new_temp /etc/apache2/sites-available/your_site.com
Now open your file for editing:
sudo nano /etc/apache2/sites-available/your_site.com
Scroll down to the second instance of <VirtualHost *:80> and replace it with:
<VirtualHost *:443>
Now add the following two lines within your :443 settings block:
SSLEngine on
SSLCertificateFile /etc/apache2/ssl/your_site.com/apache.pem
Next, you need to create your website's document root. I do this by running a git clone. If you don't have git installed on your server or you haven't yet linked your machine with your BitBucket/GitHub account, checkout the following post before continuing (it's easy): http://oneqonea.blogspot.com/2013/04/how-do-i-install-git-and-link-my-linux.html

Okay cool, you're back. After checking out that post you should now have your project cloned to your remote machine (i.e. the document root dir referenced in our vhost config file now points to a directory that exists).

Next, we need to edit our ports.conf file:
sudo nano /etc/apache2/ports.conf
Add the following line as depicted in the following image:
NameVirtualHost *:443
Now is a good time to double check and make sure "your_site.com" points to "your_ip_address" at the DNS level. Once you've double checked that all we need to do is enable our site, disable default, and restart apache:
sudo a2ensite your_site.com
Output will tell you to run a follow up command. You don't need to at this time. Next run:
sudo a2dissite default
Now restart apache (as opposed to reload):
sudo /etc/init.d/apache2 restart
Badda bing, badda boom! You're up and running with a secure site! Now let's test it!

Put a "test" info.php file inside your project's web root:
echo '<?php phpinfo();' > your_site.com/www/info.php
Now access your_site.com/info.php via http first and https second. The following screenshots show what you should see!




If your screens look like my screens then you rock! Let's wrap up by removing our test file:
rm your_site.com/www/info.php
After doing that you're done! You can exit your remote machine.
exit
Congrats!

In a future post we'll be looking at how to add a release management library I wrote called clitools to a CodeIgniter project and doing your first release to your new machine! Stay tuned!

How do I install git and link my Linux machine to my BitBucket/GitHub account?

To start things off, connect to your remote machine:
ssh -p your_port you@your_ip_address
Now, see if you already have git installed:
which git
If your machine has git installed you'll see its path printed to your screen. Else, you'll need to install it:
sudo aptitude install git
You'll be prompted regarding incoming file size. Enter "yes". Now run:
which git
You'll see the program's path printed to your screen:
/usr/bin/git
Now we need to check and see if you have an ssh key pair on your machine or if we need to create one. To start off, we need to examine your remote machine. Run the following command:
cat ~/.ssh/id_rsa.pub
If the above command prints "No such file or directory", then you'll need to generate an ssh key pair before continuing. If the previous command printed a bunch of funny looking letters and numbers, then you already have an ssh key pair on your local machine that we can make use of!

Okay, so if your machine doesn't already have an ssh key pair on file, we can easily create one. Enter the following command:
ssh-keygen -t rsa -C "your_email@your_domain.com"
You'll be prompted with the following:
Enter file in which to save the key (/Users/you/.ssh/id_rsa):
Just press enter and "~/.ssh/id_rsa" will be used (which is what we want).

Next, you'll be prompted with the following:
Enter passphrase (empty for no passphrase):
Press enter twice to generate a key pair without a passphrase.

Now, at this point, everybody should have an "~/.ssh/id_rsa.pub" file on their remote machine. Next, log in to your BitBucket or GitHub account.

For BitBucket follow these steps:

  • Step 3) Print your machine's id_rsa.pub file content on the command line so you can manually copy it into memory:
    cat ~/.ssh/id_rsa.pub
    After copying it, without getting a single extra character accidentally added, paste it into your BitBucket account as shown in the following screenshot:


For GitHub follow these steps:

  • Step 3) Print your machine's id_rsa.pub file content on the command line so you can manually copy it into memory:
    cat ~/.ssh/id_rsa.pub
    After copying it, without getting a single extra character accidentally added, paste it into your GitHub account as shown in the following screenshot:
Next, config git to use your BitBucket/GitHub email address:
git config --global user.name "Your Full Name Here"
git config --global user.email your_repo_email@your_domain.com
Now, clone your project!

For BitBucket:
git clone git@bitbucket.org:your_username/your_project.git your_domain.com
For GitHub:
git clone git@github.com:your_username/your_project.git your_domain.com
In either case, you'll be prompted about "The authenticity of host...", enter "yes".

Boom! You're done! Way to go!

Lastly, if you're coming from my post titled, "How do I set up Apache virtual hosts on a Debian based Linux machine and configure to support HTTPS?", you can get back to it here: http://oneqonea.blogspot.com/2013/04/how-do-i-set-up-apache-virtual-hosts-on.html

What's the best place to look for how to manage an Apache2 server running on a Debian-based Linux box?

If you don't already have apache2 installed on your machine, run the following command:
sudo aptitude install apache2
Then run:
sudo gunzip /usr/share/doc/apache2.2-common/README.Debian.gz
Followed up by:
cat /usr/share/doc/apache2.2-common/README.Debian
Which will print 399 lines of very helpful information:
Contents
========

 Apache2 Configuration under Debian GNU/Linux
  Files and Directories in /etc/apache2
  Tools

 Using mod_disk_cache

 SSL
  Enabling SSL
  Creating self-signed certificates
  SSL workaround for MSIE

 Suexec
 
 Documentation

 Upgrades

 Common Problems


Apache2 Configuration under Debian GNU/Linux
============================================

Debian's default Apache2 installation attempts to make adding and
removing modules, virtual hosts, and extra configuration directives as
flexible as possible, in order to make automating the changes and
administering the server as easy as possible.

Please be aware that this layout is quite different from the standard
Apache configuration. Due to the use of environment variables, apache2
needs to be started/stopped with /etc/init.d/apache2 or apache2ctl. 
Calling /usr/bin/apache2 directly will not work with the default
configuration. To call apache2 with specific command line arguments,
just call apache2ctl with the same arguments.

Files and Directories in /etc/apache2:
-------------------------------------

apache2.conf

 This is the main configuration file.

envvars

 This contains environment variables that may be used in the
 configuration. Some settings, like user and pid file, need to
 go in here so that other scripts can use them. It can also
 be used to change some default settings used by apache2ctl.
 Here is also the default LANG=C setting that can be changed
 to a different language.

conf.d/

 Files in this directory are included by this line in
 apache2.conf:

 # Include generic snippets of statements
 Include /etc/apache2/conf.d

 This is a good place to add additional configuration
 directives. Packages should not use configuration
 files that start with 'local-' or end with '.local'.
 The local administrator can use these filenames to make
 sure that there are no conflicts with files provided by
 packages.

 If the local administrator is not comfortable with packages
 activating their config files by default, it is possible
 to change the 'Include /etc/apache2/conf.d/' in apache2.conf
 into 'Include /etc/apache2/conf.d.enabled/' and create that
 directory. He can then put symlinks to the files in conf.d
 which he wants to enable into conf.d.enabled.

httpd.conf

 Empty file.

magic

 Patterns for mod_mime_magic. This is not compatible with the format
 used by current versions of the file/libmagic packages.

mods-available/

 This directory contains a series of .load and .conf files.
 The .load files contain the Apache configuration directive
 necessary to load the module in question.  The respective
 .conf files contain configuration directives necessary to
 utilize the module in question.

mods-enabled/

 To actually enable a module for Apache2, it is necessary to
 create a symlink in this directory to the .load (and .conf, if
 it exists) files associated with the module in
 mods-available/.  For example:

 cgi.load -> /etc/apache2/mods-available/cgi.load

ports.conf

 Configuration directives for which ports and IP addresses to
 listen to.

sites-available/

 Like mods-available/, except it contains configuration
 directives for different virtual hosts that might be used with
 apache2.  Note that the hostname doesn't have to correspond
 exactly with the filename.  'default' is the default host.

sites-enabled/

 Similar in functionality to mods-enabled/, sites-enabled
 contains symlinks to sites in sites-available/ that the
 admnistrator wishes to enable.

 Apache uses the first VirtualHost that matches the IP/Port
 as default for named virtual hosts. Therefore the 'default'
 site is linked to '000-default' so that it will be read first.

 Example:
 dedasys -> /etc/apache2/sites-available/dedasys

The Include directive ignores files with names that

- do not begin with a letter or number
- contain a character that is neither letter nor number nor _-.
- contain .dpkg

Other files
-----------

For historical reasons, the pid file is in /var/run/apache2.pid and not in
/var/run/apache2/apache2.pid.

Tools
-----

a2enmod and a2dismod are available for enabling and disabling modules utilizing
the above configuration system.

a2ensite and a2dissite do essentially the same thing as the above tools, but
for sites rather than modules.

apxs2 -a/-A is modified to use a2enmod to activate newly installed modules.


Using mod_disk_cache
====================

To ensure that the disk cache does not grow indefinitely, htcacheclean is
started when mod_disk_cache is enabled. Both daemon and cron (daily) mode
are supported. The configuration (run mode, cache size, ...) is in
/etc/default/apache2 .

Normally, htcacheclean is automatically started and stopped by
/etc/init.d/apache2. However, if you change the state of mod_disk_cache or the
configuration of htcacheclean while apache2 is running, you may need to
manually start/stop htcacheclean with "/etc/init.d/apache2 start-htcacheclean"
or "/etc/init.d/apache2 stop-htcacheclean".


SSL
===

Enabling SSL
------------

To enable SSL, type (as user root):

 a2ensite default-ssl
 a2enmod ssl

If you want to use self-signed certificates, you should install the ssl-cert
package (see below). Otherwise, just adjust the SSLCertificateFile and
SSLCertificateKeyFile directives in /etc/apache2/sites-available/default-ssl to
point to your SSL certificate. Then restart apache:

 /etc/init.d/apache2 restart

The SSL key file should only be readable by root, the certificate file may be
globally readable. These files are read by the Apache parent process which runs
as root. Therefore it is not necessary to make the files readable by the
www-data user.

Creating self-signed certificates
---------------------------------

If you install the ssl-cert package, a self-signed certificate will be
automatically created using the hostname currently configured on your computer.
You can recreate that certificate (e.g. after you have changed /etc/hosts or
DNS to give the correct hostname) as user root with:

 make-ssl-cert generate-default-snakeoil --force-overwrite

To create more certificates with different host names, you can use

 make-ssl-cert /usr/share/ssl-cert/ssleay.cnf /path/to/cert-file.crt

This will ask you for the hostname and place both SSL key and certificate in
the file /path/to/cert-file.crt . Use this file with the SSLCertificateFile
directive in the Apache config (you don't need the SSLCertificateKeyFile in
this case as it also contains the key). The file /path/to/cert-file.crt should
only be readable by root. A good directory to use for the additional
certificates/keys is /etc/ssl/private .

SSL workaround for MSIE
-----------------------

The SSL workaround for MS Internet Explorer needs to be added to your SSL
VirtualHost section (it was previously in ssl.conf but caused keepalive to be
disabled even for non-SSL connections):

 BrowserMatch "MSIE [2-6]" \
  nokeepalive ssl-unclean-shutdown \
  downgrade-1.0 force-response-1.0
 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

The default SSL virtual host in /etc/apache2/sites-available/default-ssl
already contains this workaround.


Suexec
======

Debian ships two version of the suexec helper program required by mod_suexec.
It is not installed by default, to avoid possible security issues. The package
apache2-suexec contains the standard version that works only with document root
/var/www, userdir suffix public_html, and Apache run user www-data. The package
apache2-suexec-custom contains a customizable version, that can be configured
with a config file to use different settings (like /srv/www as document root).
For more information see the suexec(8) man page in the apache2-suexec-custom
package.

Since apache2-suexec-custom has received less testing and might be slightly
slower, apache2-suexec is the recommended version unless you need the features
from apache2-suexec-custom.


Documentation
=============

The full Apache 2 documentation can be found on the web at

http://httpd.apache.org/docs/2.2/

or, if you have installed the apache2-doc package, in

/usr/share/doc/apache2-doc/manual/

or at

http://localhost/manual/

There is also a wiki that contains useful information:

http://wiki.apache.org/httpd/

Some hints about securing Apache 2 on Debian are available at

http://wiki.debian.org/Apache/Hardening


Upgrades
========

Changes in the Apache packages that require manual configuration adjustments
are announced in NEWS.Debian. Installing the apt-listchanges package is
recommended. It will display the relevant NEWS.Debian sections before
upgrades.


Multiple instances
==================

There is some support for running multiple instances of Apache2 on the same
machine. See /usr/share/doc/apache2.2-common/README.multiple-instances for more
information.


Common Problems
===============

1) Error message "Could not reliably determine the server's fully qualified 
domain name, using 127.0.0.1 for ServerName" during start

This can usually be ignored but it means that Apache httpd was unable to obtain
a fully-qualified hostname by doing a reverse lookup on your server's IP
address. You may want to add the fully-qualified hostname to /etc/hosts .
An alternative is to specify "ServerName 127.0.0.1" in the global server
context of the configuration, e.g. in /etc/apache2/conf.d/servername.local .

2) Error message "mod_rewrite: could not create rewrite_log_lock"

This probably means that there are some stale SYSV semaphores around. This
usually happens after apache2 has been killed with kill -9 (SIGKILL). You can
clean up the semaphores with:

 ipcs -s | grep www-data | awk ' { print $2 } ' | xargs ipcrm sem

3) Message "NameVirtualHost *:80 has no VirtualHosts" in error log

Probably the VirtualHost definitions have not been adjusted after the 
NameVirtualHost directive was changed in ports.conf. 
See /usr/share/doc/apache2.2-common/NEWS.Debian.gz

4) Message "File does not exist: /etc/apache2/htdocs" in error log

In most cases this means that no matching VirtualHost definition could be
found for an incoming request. Check that the target IP address/port and the
name in the Host: header of the request actually match one of the virtual
hosts.

5) Message "Couldn't create pollset in child; check user or system limits" in
  error log

On Linux kernels since 2.6.27.8, the value in

    /proc/sys/fs/epoll/max_user_instances

needs to be larger than

    for prefork/itk  MPM: 2 * MaxClients
    for worker/event MPM: MaxClients + MaxClients/ThreadsPerChild

It can be set on boot by adding a line like

        fs.epoll.max_user_instances=1024

to /etc/sysctl.conf.

There are several other error messages related to creating a pollset that can
appear for the same reason.

On the other hand, errors about to adding to a pollset are related to the
setting fs.epoll.max_user_watches. On most systems, max_user_watches should be
high enough by default.

6) Message "Server should be SSL-aware but has no certificate configured" in
   error log

Since 2.2.12, Apache is stricter about certain misconfigurations concerning
name based SSL virtual hosts. See NEWS.Debian.gz for more details.

7) Apache does not pass Authorization header to CGI scripts

This is intentional to avoid security holes. If you really want to change it,
you can use mod_rewrite:

 RewriteCond %{HTTP:Authorization} (.*)
 RewriteRule . - [env=HTTP_AUTHORIZATION:%1]

8) mod_dav is behaving strangely

In general, if you use mod_dav_fs, you need to disable multiviews and script
execution for that directory. For example:

    <Directory /var/www/dav>
        Dav on
        Options -MultiViews -ExecCGI
        SetHandler none
        <IfModule mod_php5.c>
            php_admin_value engine Off
        </IfModule>
    </Directory>

9) Message "apache2: bad user name " when starting apache2
   directly

Use apache2ctl (it accepts all options of apache2).

10) Apache is using a lot of memory and is not freeing it even when idle

By default, Apache will not give back unused memory but keep it around for
later use.

  * Tune StartServers, MaxRequestsPerChild, MinSpareThreads/MinSpareServers,
    MaxSpareThreads/MaxSpareServers in /etc/apache2/apache2.conf

  * If you are really starved for memory, try adding 'MaxMemFree 4' to your
    Apache configuration. This will reduce Apache's performance.
    Because of the way Apache's memory allocator interacts with glibc's malloc,
    higher values of MaxMemFree don't have much effect.

11) A PUT with mod_dav_fs fails with "Unable to PUT new contents for /...
[403, #0]" even if Apache has permission to write the file.

Apache also needs write permission to the directory containing the file, in
order to replace it atomically.

12) How to increase the ulimit for the max number of open files?

Add the following line to /etc/apache2/envvars:

 APACHE_ULIMIT_MAX_FILES='ulimit -n 65536'

How do I set up ssh keys and turn off password access on my new Linux box?

To start off, we need to examine your local machine. Run the following command:
cat ~/.ssh/id_rsa.pub
If the above command prints "No such file or directory", then you'll need to generate an ssh key pair before continuing. If the previous command printed a bunch of funny looking letters and numbers, then you already have an ssh key pair on your local machine that we can make use of!

Okay, so if your machine doesn't already have an ssh key pair on file, we can easily create one. Enter the following command:
ssh-keygen -t rsa -C "your_email@example.com"
You'll be prompted with the following:
Enter file in which to save the key (/Users/you/.ssh/id_rsa):
Just press enter and "~/.ssh/id_rsa" will be used (which is what we want).

Next, you'll be prompted with the following:
Enter passphrase (empty for no passphrase):
Press enter twice to generate a key pair without a passphrase.

Now, at this point, everybody should have an "~/.ssh/id_rsa.pub" file on their local machine. Next, connect to your remote machine using your password:
ssh -p your_port you@your_ip_address
Then, run the following command (to ensure you have an ".ssh" dir on file):
mkdir -p ~/.ssh
Now exit and return to your local machine:
exit
Next, copy your public key to your remote machine:
scp -P your_ssh_port ~/.ssh/id_rsa.pub your_user@your_ip_address:~/incoming_public_key.pub
Next, connect to your remote machine via username and password:
ssh -p your_port you@your_ip_address
Next, enter the following command:
cat ~/incoming_public_key.pub >> ~/.ssh/authorized_keys
Then remove the source file:
rm ~/incoming_public_key.pub
Now, exit your remote machine:
exit
SSH keys have now been set up! Now, with a single command you're into your remote machine:
ssh -p your_ssh_port you@your_ip_address
Boom! Time to disallow password-based ssh connections.

K, starting from within your remote machine, run the following command:
sudo nano /etc/ssh/sshd_config
Then, scroll down to the section that looks like this:
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication yes
and switch it to this:
# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no
Save the file. Now restart the ssh daemon:
sudo /etc/init.d/ssh restart
Boom. We're done, ssh key pair connections only! Before exiting the remote machine you can validate this yourself if you'd like by walking through the following process:
  • Step 0) Make sure you have an open connection to your remote machine.
  • Step 1) Open a new Terminal window.
  • Step 2) Run the following command on your remote machine:
mv ~/.ssh/authorized_keys ~/.ssh/authorized_keys_mimic_no_machines_authed
  • Step 3) In your other Terminal window (local machine), try to ssh into your machine:
ssh -p your_ssh_port you@your_ip_address
You'll see the following output:
Permission denied (publickey).
Boom! Now das wassup!

If you're interested in what's going on process-wise, here's the skinny: By moving the location of the "authorized_keys" file on the remote machine we're mimicking your local machine not having a "machine to machine ssh key connection" with your remote box. Therefore, when we run the above ssh command, ssh first tries to connect using your machine's local ssh key pair, but gets denied because the public key counterpart is "not on file" on our remote machine (remember that we moved the "authorized_keys" file to "authorized_keys_mimic_no_machines_authed" to create this scenario). Next, ssh looks to use a password picked up from the command line and gets rejected on that due to our latest sshd config update! Woo hoo! At this point you can test connecting with your root user too if you'd like and you'll see that not even root can log in to the remote machine! Now you see why I said, "Make sure you have an open connection to your remote machine." in "Step 0" above. Let's put things back now. Run the following command on your remote machine:
mv ~/.ssh/authorized_keys_mimic_no_machines_authed ~/.ssh/authorized_keys
Now, from your other Terminal window, you can run:
ssh -p your_ssh_port you@your_ip_address
And boom you'll be good to go.

Now das wassup! You're done! You can even exit your remote machine if you want!
exit
Lastly, if you're coming from my "How do I set up Apache virtual hosts on a Debian based Linux machine and configure to support HTTPS?" post, you can get back to it here: http://oneqonea.blogspot.com/2013/04/how-do-i-set-up-apache-virtual-hosts-on.html

Sunday, April 21, 2013

How do I install the latest versions of Apache, MySQL, and PHP on a Debian based Linux machine?

What up! So you want to know how to install the latest versions of Apache, MySQL, and PHP on a Debian based Linux machine? Sweet. Me too.

If you need help getting a Debian based Linux machine online, check out a post I did the other day titled: How do I set up a Next Generation Rackspace Cloud Server running Debian 7 (Wheezy)?

Okay, slap yourself in the face real quick. It's time to get started!

SSH into your machine.

Then walk through the following post: How do I install mysql-client, mysql-server, and libmysqlclient-dev on a Next Generation Rackspace Cloud Server running Debian 7 (Wheezy)? Note that you can skip the libmysqlclient-dev piece.

Great. You're back. Okay, now run the following command:
sudo aptitude install apache2
You'll be prompted to "ok" the amount of space that will be used after unpacking the archives. Enter "yes" to proceed.

Apache's default document root is /var/www on Debian, and the configuration file is /etc/apache2/apache2.conf. Additional configurations are stored in subdirectories of the /etc/apache2 directory such as /etc/apache2/mods-enabled (for Apache modules), /etc/apache2/sites-enabled (for virtual hosts), and /etc/apache2/conf.d.

If you enter your server's IP address into your browser, you'll see that we're on fire!
Okay, now on to installing php:
sudo aptitude install php5
PHP 5.4 will be installed. If you're setting up a Debian 6.0 (Squeeze) box and require php 5.4 (like I used to) then splash some hot coffee in your face because we've got an extra couple of steps to perform!

Run the following command:
sudo nano /etc/apt/sources.list
Add the following lines to the end of the file:
# http://www.dotdeb.org/instructions/ (but only for php54)
deb http://packages.dotdeb.org squeeze-php54 all
deb-src http://packages.dotdeb.org squeeze-php54 all
Now save the file. Next, run the following two commands:
wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | sudo apt-key add -
After doing that, we can now update our list of available packages via the following command:
sudo aptitude update
Ok, now we can install php 5.4 via the following command:
sudo aptitude install php5
Boom goes the dynamite! We can verify our install by running the following command:
php -v
Which will output:
PHP 5.4.14-1~dotdeb.1 (cli) (built: Apr 21 2013 05:21:34)
Copyright (c) 1997-2013 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies
Okay, sweet! Now that we have php installed we can put a dot php file in apache's default document root (/var/www), restart apache, and then test our new setup. To begin, run the following command:
sudo nano /var/www/info.php
Then enter:
<?php
phpinfo();
Save the file. Now restart apache (since we haven't done so yet since installing php) via the following command:
sudo /etc/init.d/apache2 restart
Now access your new info.php page. You'll see the following:
You'll see we now have php working via the "Apache 2.0 Handler" (see "Server API" line). If you do a search for "mysql" you'll see that "mysql" is nowhere to be found! We'll need to fix that (as well as install other useful php modules). To see your options, run the following command:
aptitude search php5
I recommend installing php5-mysql, php5-curl, php5-gd, php-pear, php5-imagick, php5-imap, php5-mcrypt, php5-memcache, php5-sqlite, php5-tidy, php5-xmlrpc, and php5-xsl via the following command:
sudo aptitude install php5-mysql php5-curl php5-gd php-pear php5-imagick php5-imap php5-mcrypt php5-memcache php5-sqlite php5-tidy php5-xmlrpc php5-xsl
Okay sweet. Now we're talking! Revisit your info.php page (aptitude will have already restarted apache for you), do a search for "mysql" and then revel in your success! You are on fire!
Okay, now if you're anything like me you'd like a web interface to your remote database. PHPMyAdmin has you covered... but only if we install it! Get started with the following command:
sudo aptitude install phpmyadmin
As usual you'll be prompted about incoming file size. Enter "yes" when prompted. Next, you'll be presented with the following package configuration screen:

Select "apache2". You'll then be prompted with a second package configuration screen:

Select "No". And boom! You've got PHPMyAdmin installed! Not! There's actually one more step. To see for yourself visit your /phpmyadmin page and observe the 404!
To fix this. Run the following command:
sudo nano /etc/apache2/conf.d/phpmyadmin.conf
Then add the following line to the file:
Include /etc/phpmyadmin/apache.conf
Save the file. Then, restart apache via the following command:
sudo /etc/init.d/apache2 restart
Now revisit your /phpmyadmin page and observe your awesomeness!
Now that we've got our system set up properly we can remove our info.php file via the following command:
sudo rm /var/www/info.php
Now das wassup! Congrats, you're done! You successfully installed the latest versions of Apache, MySQL, and PHP.

If you're interested in getting your Apache hosting environment set up you should check out a post I wrote the other day titled: How do I set up Apache virtual hosts on a Debian based Linux machine and configure to support HTTPS?

Saturday, April 20, 2013

How do I install mysql-client, mysql-server, and libmysqlclient-dev on a Next Generation Rackspace Cloud Server running Debian 7 (Wheezy)?

First things first, there are a lot of MySQL packages available for install. If you want to see a list, run the following command:
aptitude search mysql
In this blog post we'll be installing mysql-client, mysql-server, and libmysqlclient-dev. Each is described as follows:

mysql-client:
MySQL database client (metapackage depending on the latest version)

mysql-server:
MySQL database server (metapackage depending on the latest version)

libmysqlclient-dev:
MySQL database development files

To get started, run the following command:
sudo aptitude install mysql-client
You'll be prompted for your password. Enter it. You'll then be prompted to "ok" the amount of space that will be used after unpacking the archives. Enter "yes" to proceed.

Next, run the following command:
sudo aptitude install mysql-server
Again, you'll get prompted regarding disk space. Enter "yes". Next, you'll be presented with a blue package configuration screen prompting you to enter a password for the root mysql user (twice). Enter something insane. Here's what the package configuration screen will look like:

mysql-server package configuration screen (for setting root user password)
After entering your totally insane root user password the installation process will continue on and then wrap itself up.

Next, if you're interested in prepping your machine for master/slave replication, run the following command:
sudo aptitude install libmysqlclient-dev
Again, you'll get prompted regarding disk space. Enter "yes". Next, you'll be throwing yourself a frickin' party because you're done! Congrats!

In a future post we'll be looking at how to set up MySQL master/slave replication (hence the reason I've added the libmysqlclient-dev section above)! Brace yo self foo!

Lastly, if you came to this page from my "How to install the latest versions of Apache, MySQL, and PHP" post and want to get back, or you're interested in installing Apache and/or PHP as a next step in setting up your server, click here: http://oneqonea.blogspot.com/2013/04/how-do-i-install-latest-versions-of.html

Wednesday, April 17, 2013

How do I set up a Next Generation Rackspace Cloud Server running Debian 7 (Wheezy)?

First, launch a new Debian 7 (Wheezy) server by following the instructions found at:
http://www.rackspace.com/knowledge_center/article/rackspace-cloud-essentials-2-creating-a-cloud-server

After doing so, you should have a new root user, the root user's password, and an IP address.

Next, launch Terminal and run the following command (using your server's IP address rather than 165.210.5.238):
ssh root@165.210.5.238
You'll be prompted with the following message:
The authenticity of host '165.210.5.238 (165.210.5.238)' can't be established.
RSA key fingerprint is 9a:7d:4r:25:1b:30:a9:39:ft:b2:a1:99:t9:52:z6:99.
Are you sure you want to continue connecting (yes/no)?
Enter the following word:
yes
You'll then be prompted with the following message:
Warning: Permanently added '165.210.5.238' (RSA) to the list of known hosts.
Perfect. After that you'll be asked for the root user's password via the following prompt:
root@165.210.5.238's password:
Enter it.

Next we're going to update the root user's password to something insane. We'll do so by entering the following command:
passwd
You'll be prompted to input your new, totally insane, root user password via the following prompt:
Enter new UNIX password:
You'll enter it. Then you'll be prompted again. You'll enter it again.

At this point you should start to feel awesome.

But not too awesome because we're running commands as root right now which isn't awesome. So, let's fix that. Time to create a new user.

Enter the following command (this tutorial uses 'admin' throughout but you can name your user whatever you want... like tim, jane, bob, or even tbone_smith):
adduser admin
You'll see the following output:
Adding user `admin' ...
Adding new group `admin' (1000) ...
Adding new user `admin' (1000) with group `admin' ...
Creating home directory `/home/admin' ...
Copying files from `/etc/skel' ...
You'll then be prompted to enter the new user's password via the following prompt (twice):
Enter new UNIX password:
You'll enter the new password (twice). You'll then be prompted for some additional information:
passwd: password updated successfully
Changing the user information for admin
Enter the new value, or press ENTER for the default
 Full Name []: 
 Room Number []: 
 Work Phone []: 
 Home Phone []: 
 Other []: 
If you're working out of a hotel room make sure to enter your room number. After answering all the questions above (whichever ones you want) you'll be prompted with the following:
Is the information correct? [Y/n]
Enter:
yes
Now that's pretty cool, but not that cool. Our new user can't do much unless we grant them sudo privileges. So enter the following command:
visudo
You'll notice a section near the middle of the file that matches:
# User privilege specification
root    ALL=(ALL) ALL
Add an additional line after root for your new user like so:
# User privilege specification
root    ALL=(ALL) ALL
admin   ALL=(ALL) ALL
Save the file.

Now we need to update our ssh config file. We're going to update our ssh port number to be non-standard, enable password authentication, and white label (allow) the user we just created. Let's kick off this bad-ass-ness by running the following command:
nano /etc/ssh/sshd_config
Find the lines (near the top) that match:
# What ports, IPs and protocols we listen for
Port 22
Update the digit 22 to be something highly random like 30062. Next, find the lines that match:
# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes
Uncomment the 2nd line above to make it so we can ssh in to this machine using a password (you can set this directive to "no" later, after you get ssh keys set up). Save the file.

Now that's pretty bomb, but not that bomb. In order to go bomb-status we need to setup our software firewall using iptables. To get started run the following command:
nano /etc/iptables.test.rules
Then, copy and paste the following rules into your /etc/iptables.test.rules file:
*filter


#  Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT


#  Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT


#  Allows all outbound traffic
#  You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT


# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT


#  Allows SSH connections
#
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
#
-A INPUT -p tcp -m state --state NEW --dport 30062 -j ACCEPT


# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT


# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7


# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT
We're basically accepting localhost traffic, outbound traffic, http, https, ssh (on our custom port), pings, and rejecting everything else.

Note: The above template is an exact copy of a SliceHost reference doc located at http://articles.slicehost.com/assets/2007/9/4/iptables.txt (with the exception of line 27 which you can see I've updated to match our highly random custom ssh port of 30062).

To apply this bomb-status-ness run the following command:
iptables-restore < /etc/iptables.test.rules
To review our work we can run the following command:
iptables -L
Which should output:
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             loopback/8          reject-with icmp-port-unreachable 
ACCEPT     all  --  anywhere             anywhere            state RELATED,ESTABLISHED 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
ACCEPT     tcp  --  anywhere             anywhere            state NEW tcp dpt:30077 
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
LOG        all  --  anywhere             anywhere            limit: avg 5/min burst 5 LOG level debug prefix `iptables denied: ' 
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
REJECT     all  --  anywhere             anywhere            reject-with icmp-port-unreachable 

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
Pretty cool, right? Wrong! Well not totally wrong, we just need to save these rules as our default configuration and then wire them up so when we restart the server we don't lose them!

There are a few ways to go about this. You can either edit your interfaces file directly or create a special script that gets run when your network interfaces are started. I've been told the scripting approach is superior. I'll cover both approaches ("editing your interfaces file directly" first, "scripting" second).

With either approach, we begin by saving our rules to a file via the following command:
iptables-save > /etc/iptables.up.rules
Okay, if you'd like to edit your interfaces file directly, start by opening your network interface config file via the following command:
nano /etc/network/interfaces
The first 5 lines will be as follows:
# Used by ifup(8) and ifdown(8). See the interfaces(5) manpage or
# /usr/share/doc/ifupdown/examples for more information.
# The loopback network interface
auto lo
iface lo inet loopback
Add a sixth line right after 'iface lo inet loopback' that says:
pre-up iptables-restore < /etc/iptables.up.rules
Then, save the file. Now we won't lose our software firewall rules on reboot. Now that's pretty cool!

Okay, that concludes the "edit your interfaces file directly" approach. If you want to take the "scripting" approach (which, again, I've been told is a superior method), follow these steps:
nano /etc/network/if-pre-up.d/iptables
Add the following lines to the new file:
#!/bin/sh
/sbin/iptables-restore < /etc/iptables.up.rules
Save your changes, then make the new script executable:
chmod +x /etc/network/if-pre-up.d/iptables
Okay cool, now we won't lose our software firewall rules on reboot! Yay!

Alright, we're almost done with our root account and we're about to switch over to operating via our new admin user. Before we do that though, since we made changes to our ssh config file, we need to apply them. You can do so via the following command:
/etc/init.d/ssh reload
Now exit:
exit
Then, ssh back into the machine via our new admin user account using our custom ssh port:
ssh -p 30062 admin@165.210.5.238
And if you successfully connected to the machine... we can officially say, "Boom goes the dynamite".

We're done right? Wrong! It's time get down with some personal preference style settings in our bash config file (you can skip this step if you'd like). Start by running the following command:
nano ~/.bashrc
Then, find the following line:
#force_color_prompt=yes
Remove the # character, save the file, then reload your config file via the following command:
source ~/.bashrc
Boom. Your terminal prompt just got jacked! Well I don't even know exactly what that means but you'll notice your prompt is now printed in a fatty daddy green color which helps distinguish it from command output.

At this point you're probably whining like a little baby wondering if we're done yet. No!

Time to update our server so we're not running code that's like 40 thousands years old. To do this, run the following command:
sudo aptitude update
Next, we'll want to set up our region information. First, let's start with installing locales. Run the following command:
sudo aptitude install locales
After doing that, let's reconfigure it:
sudo dpkg-reconfigure locales
A blue screen should pop up. Select en_US.UTF-8 until you're back in your regular command prompt (should take two selections of en_US.UTF-8 to complete).

Next we're going to set up our timezone info:
sudo dpkg-reconfigure tzdata
A blue screen should pop up. I selected America then Chicago (since my server is in Chicago). After completing this step you'll see the following information printed to your screen:
Current default time zone: 'America/Chicago'
Local time is now:      Wed Apr 17 08:56:45 CDT 2013.
Universal Time is now:  Wed Apr 17 13:56:45 UTC 2013.
Now that we've updated our software listings from the repositories (in a previous step), it's time to run the actual upgrade (we'll do this via two commands starting with a safe upgrade first):
sudo aptitude safe-upgrade
You'll get prompted about disk usage (incoming file size) along the way. Say yes to these prompts. Once that's done we'll run the full upgrade:
sudo aptitude full-upgrade
Now we're pretty much done except for one thing. Let's install the build essential package to help resolve future dependencies... that is, unless you'd rather spend your time in dependency hell rather than getting barreled in some sick surf.
sudo aptitude install build-essential
Now das wassup! Our server is on lock down & ready to go! You now have proof that you're awesome!

Way to go!

Now that you've got your server set up and on lock down you may be interested in setting up the rest of the LAMP stack (Apache, MySQL, & PHP). If so, checkout a post I recently published that walks you through the process step by step: http://oneqonea.blogspot.com/2013/04/how-do-i-install-latest-versions-of.html

Final note: The vast majority of this tutorial was derived from a YouTube video by ckeck. So props there! Thx dude!

Thursday, April 11, 2013

What's the MySQL process/syntax for renaming a field that's wired up as a foreign key?

ALTER TABLE `your_referencing_table` DROP FOREIGN KEY `your_existing_fk_name`;
ALTER TABLE `your_referencing_table` CHANGE `existing_field_name` `new_field_name` INT( 11 ) UNSIGNED NULL DEFAULT NULL COMMENT 'fk';
ALTER TABLE `your_referencing_table` DROP INDEX `existing_index_name`, ADD INDEX `new_index_name` (`new_field_name`);
ALTER TABLE `your_referencing_table` ADD CONSTRAINT `your_new_fk_name` FOREIGN KEY (`new_field_name`) REFERENCES `your_existing_reference_table` (`your_existing_reference_table_field`) ON DELETE CASCADE ON UPDATE CASCADE;

What's the MySQL syntax for dropping a foreign key?

ALTER TABLE `your_referencing_table` DROP FOREIGN KEY `your_existing_fk_name`;

What's the MySQL syntax for adding a foreign key?

ALTER TABLE `your_referencing_table` ADD CONSTRAINT `your_new_fk_name` FOREIGN KEY (`your_referencing_table_field`) REFERENCES `your_foreign_table` (`your_foreign_table_field`) ON DELETE CASCADE ON UPDATE CASCADE;
Note that `your_referencing_table_field` must be indexed.

Wednesday, April 3, 2013

About Me

My photo
I code. I figured I should start a blog that keeps track of the many questions and answers that are asked and answered along the way. The name of my blog is "One Q, One A". The name describes the format. When searching for an answer to a problem, I typically have to visit more than one site to get enough information to solve the issue at hand. I always end up on stackoverflow.com, quora.com, random blogs, etc before the answer is obtained. In my blog, each post will consist of one question and one answer. All the noise encountered along the way will be omitted.