CentOS

Python 2.7, Django, Apache, and Gunicorn on CentOS 6.5

Posted on by Matt Woodward

I’m working on a little Django project for KPTZ Radio in Port Townsend and since this project has to talk to a serial relay board from a specific server that has other things running on it, I’ve been going through the process of installing Python 2.7 on CentOS 6.5, along with configuring Django, Apache, and Gunicorn.

Since I’m a lot more used to dealing with Nginx and Gunicorn on Ubuntu, getting this all up and running correctly took a lot more trial and error than I thought it would, but I finally got it figured out so figured I’d share since I found a lot of either incomplete or misleading information about this as I searched for solutions.

Installing Python 2.7

Your first question is probably why I’m not installing Python 3. In the case of this particular project, pyserial was not (when I first started the project) Python 3 compatible, so rather than fight that battle I decided to use Python 2.7.

The problem with Python 2.7 is on CentOS 6.5, Python 2.6.6 is the default, and since there’s other Python-related stuff running on the server already I didn’t want to run the risk of screwing anything else up, so I had to install Python 2.7 as an alternate Python installation. Luckily there were a couple of resources from people who had already been through this so it wasn’t an issue. Here’s the steps I took on a fresh CentOS 6.5 VM I was using to do some trial runs before doing everything on the production server (do all these as the root user).

  1. yum -y update
  2. yum -y groupinstall “development tools” –skip-broken
  3. yum -y install wget gcc gcc-c++ make httpd-devel git vim zlib-devel bzip2-devel openssl-devel ncurses-devel sqlite-devel readline-devel tk-devel gdbm-devel db4-devel libpcap-devel xz-devel
  4. wget https://www.python.org/ftp/python/2.7.10/Python-2.7.10.tgz
  5. tar xvf Python-2.7.10.tgz
  6. cd Python-2.7.10
  7. ./configure –prefix=/usr/local –enable-shared LDFLAGS=”-Wl,-rpath /usr/local/lib”
  8. make && make altinstall
  9. python2.7 -V (to confirm it’s working)
  10. cd ..
  11. wget –no-check-certificate https://pypi.python.org/packages/source/s/setuptools/setuptools-18.2.tar.gz
  12. tar xvf setuptools-18.2.tar.gz
  13. cd setuptools-18.2
  14. python2.7 setup.py install
  15. cd ..
  16. curl https://raw.githubusercontent.com/pypa/pip/master/contrib/get-pip.py | python2.7 –
  17. pip2.7 install virtualenv

Create a User to Own the Project

Depending on how you want to do things this could be considered optional, but I created a user to own the project files (again as root):
  1. useradd -m -s /bin/bash/someuser

Create a Python virtualenv and Install the Django Project

Next we’ll create a Python 2.7 virtualenv, grab the Django code, install the Django project’s requirements, and do a couple of other configuration things for the Django app.
  1. sudo su – someuser
  2. mkdir ~/.virtualenvs
  3. cd ~/.virtualenvs
  4. virtualenv foo –python=python2.7
  5. cd foo
  6. source bin/activate
  7. cd ~/
  8. git clone foo
  9. cd foo
  10. pip install -r requirements.txt
  11. python manage.py runserver (just to make sure things are working at this point)
  12. python manage.py collectstatic
  13. python manage.py migrate

Configure Upstart to Start the Gunicorn Process When the Server Boots

I suppose on the next version of CentOS this will be done with systemd but thankfully on CentOS 6.5 we can still use Upstart. Note that if you’re familiar with Upstart on Ubuntu the syntax is quite different on CentOS — thanks to my good friend and former coworker Brandon Culpepper for pointing that out before I lost my mind.
First, we’ll do a quick test to make sure everything’s working at this point:
  1. sudo su – 
  2. cd /home/someuser/foo
  3. /home/someuser/.virtualenvs/foo/bin/gunicorn –workers 4 –timeout 60 –bind 0.0.0.0:8000 foo.wsgi:application
  4. Hit Ctrl-C to kill the process if you don’t see any errors.
Next we’ll create the upstart file:
  1. vim /etc/init/foo.conf
  2. Put the following in the foo.conf file and save it:
    description “Gunicorn process for foo app”

    start on started sshd
    stop on shutdown

    script
      cd /home/someuser/foo
      /home/someuser/.virtualenvs/foo/bin/gunicorn –workers 4 –timeout 60 –log-level debug –bind 0.0.0.0:8000 foo.wsgi:application
    endscript

  3. start foo (to make sure the upstart process works)
  4. ps -wef | grep python (you should see some python processes running under your virtualenv)

Create Apache Virtual Host for the App

There’s a bunch of ways to set up Django apps with Apache. In my early days with Django I would have used mod_wsgi but since I’m way more used to Nginx and Gunicorn these days, I figured I’d set up Apache in similar fashion and have it proxy to Gunicorn.
  1. vim /etc/httpd/conf/httpd.conf
  2. Uncomment the NameVirtualHost *.80 line if it isn’t already uncommented
  3. Add a new VirtualHost section at the bottom of the Apache config file:
    <VirtualHost *:80>
      ServerName whatever
      DocumentRoot /home/someuser/foo

      # serve static files from Apache
      RewriteEngine on
      RewriteRule ^/static/.* – [L]

      # proxy everything else to the gunicorn process
      ProxyPreserveHost on

      RewriteRule ^(.*)$ http://127.0.0.1:8000$1 [P]
      ProxyPassReverse / http://127.0.0.1:8000/
    </VirtualHost>

  4. apachectl restart
At that point you should be all set! Hope that helps people who are in this same or a similar boat save some time.

Setting the Initial Root Password for MySQL on CentOS

Posted on by Matt Woodward

I was setting up a new CentOS server tonight and installed MySQL via yum. If you’re familiar with installing MySQL via apt-get on Debian-based systems, you’ll know that during the install it prompts you to set the MySQL root password. Not so on CentOS.

When I’ve installed MySQL on CentOS in the past, I could have sworn the default root password was blank, and that right after the installation is complete you set it like so:

mysqladmin -u root password NEW_PASSWORD

Either my memory is foggy, or something’s changed with how this is done. No matter what I tried I kept getting “access denied” messages from MySQL and of course since I never set a root password, I have no idea what it wants from me.

Luckily there’s a solution, at least one that worked for me, though I still feel like I may be missing something so although this worked, I’m happy to be told there’s a simpler way.

First, make sure no MySQL processes are running:

killall -9 mysqld

Next, start MySQL in safe mode and have it skip grant tables:

/usr/bin/mysqld_safe --skip-grant-tables &

This will let you get in as root without a password. After the process starts, log in and use the mysql database:

mysql -u root mysql

Next, set the root user password:

update user set password=PASSWORD('new_password') where user='root';

It should say 2 or 3 rows affected. Finally, flush the privileges:

flush privileges;

Quit MySQL, and then you’ll want to kill the process you started with mysqld_safe and start the regular MySQL process. You can either bring the process you started earlier by typing ‘fg’, hitting enter, and then hitting ctrl-C to kill it, or you can do a ps -wef | grep mysqld to find the process ID and kill it as per usual.

Finally, restart MySQL and test your new root password:

/etc/init.d/mysqld start
mysql -u root -p

When it prompts you for the password, enter the password you set earlier and you should be logged in successfully.

Note this process also works if you’ve forgotten the MySQL root password.

Hope that save someone else a bit of time, and as I said earlier, I’ll be very happy if someone has a better explanation of why I wasn’t able to log in without a password on a fresh MySQL install on CentOS.

Changing the Host Name on CentOS

Posted on by Matt Woodward

I'm working on a project that is leveraging a third-party Java library to handle payment processing. This library is a for-pay product and the license is tied to the machine name, so the original license was being used on a local development box but now that we want to move things to the production server, the license wouldn't be valid since the production server's host name isn't the same as the local development box.

Apparently the company who sells the payment processing library can update the license file, but it seemed even easier to simply change the host name of the production server to match what the license is expecting. This way we can move the payment processing functionality to a different machine as needed without having to wait for a new license key to be issued.

The production server in this case is CentOS, so to change the host name you simply update /etc/sysconfig/network with the new host name and reboot.

This is slightly different from Ubuntu, which stores the host name in /etc/hostname. On Ubuntu you can also use the hostname command to change the hostname temporarily, but it will revert back to the value in /etc/hostname when you reboot.