Django Setup for CentOS 7
install.sh
Variables
when you open install.sh you'll see these variables at the top:
# vars
yumlogloc="/root/logs/yum.log"
yumlogmsg="See logs/yum.log for more info."
firelogloc="/root/logs/firewall.log"
firelogmsg="See logs/firewall.log for more info."
pylogloc="/root/logs/python.log"
pylogmsg="See logs/python.log for more info."
pylink="https://www.python.org/ftp/python/3.7.0/Python-3.7.0.tar.xz"
# Django Project Settings
user="centos"
djalog="/root/logs/django.log"
djamsg="See logs/django.log for more info."
projectname="mysite"
hostname="centos.duco.net"
# if you are doing this on a personal install you will prob need this.
install_epel_release=False
These can (and should) be changed to match your configuration needs. For example: any of the "logloc" log location variables can be changed to log somewhere else. The "logmsg" log message variables can be changed to reflect different log locations or output a custom message.
The Django Project Settings variables should be changed to match your configuration. You have (essentially) 3 options for user configuration:
- user = "[primary (sudo) user here]"
- user = "nginx"
- user = "[other user]"
My recommendation is to use nginx as the user. The installer takes care of creating a home directory for nginx and setting permissions. Of course there is no problem with specifying another user. You could "adduser django" and set django as the user. The installer will automatically assign permissions as needed. Setting the user to the primary sudo account is risky but the installer won't complain if you do it quietly.
The projectname variable can be whatever you want. When django starts the project it will use this name.
The hostname will be inserted into "ALLOWED_HOSTS" in your app settings. Multiple hosts are not supported at the moment so set this to the address you'll test with. You can add additional hosts by manually editing settings.py.
Dependencies
In order for this script to work its magic you'll need a few packages provided by Yum. This part is likely to break due to Yum's inconsistency accross distributions, firewall and proxy configurations, and whether CentOS had its morning coffee. There are a few measures you can take to prevent this. One of those is understanding exactly what this script does.
install_epel_release=True
If you are installing this on a system with the minimal CentOS build you'll need install_epel_release to be True. Epel_release includes, among other things, nginx. Kinda hard to run the site without that.
# check if root
if [[ $EUID -ne 0 ]]; then
echo "This script must be run as root"
exit 1
fi
cd /root/
echo "Installing dependencies..."
# create necessary dirs
if [ ! -d "/root/scripts" ] ; then
mkdir scripts
fi
if [ ! -d "/root/logs" ] ; then
mkdir logs
fi
if [ $install_epel_release = True ] ; then
yum -y install epel-release
fi
The first part of the script is fairly straight forward. If you aren't root, the installer can't use yum and won't work. It then creates the necessary directories to prevent future complaints and installs the aforementioned epel-release package if you want it.
yum -y install gcc wget nginx libsqlite3x-devel.x86_64 postgresql-server postgresql-devel postgresql-contrib bzip2-devel zlib-devel libffi-devel openssl-devel policycoreutils-python.x86_64 >> $yumlogloc
firewall-cmd --zone=public --add-port=80/tcp --permanent >> logs/firewall.log
firewall-cmd --zone=public --add-port=443/tcp --permanent >> logs/firewall.log
firewall-cmd --reload >> logs/firewall.log
semanage permissive -a httpd_t >> logs/firewall.log
These are the 5 commands the script runs next (without all the error checking and logging). If there were any commands I would recommend you run manually: it's these. Definitely read through the yum install logs to make sure everything went smoothly. Like I mentioned earlier: yum doesn't like to behave.
The firewall commands are specific to a CentOS 7 minimal install. You may not need them. They may not work at all. The installer doesn't really care if they fail because they aren't mission critical. It'll yell at you and that's about it.
The semanage command fixes an issue where the websocket would be inaccessible after an install causing 502 errors and loud swearing.
wget $pylink > $pylogloc
tar xf Python-3.7.0.tar.xz >> $pylogloc
cd Python-3.7.0
./configure --prefix /usr/src/python37 >> $pylogloc
make >> $pylogloc
make altinstall >> $pylogloc
/usr/src/python37/bin/python3.7 -m pip install --upgrade pip >> $pylogloc
/usr/src/python37/bin/python3.7 -m pip install virtualenv >> $pylogloc
cd /root/
rm Python-3.7.0.tar.xz >> $pylogloc
If you've ever installed Python from source this part should look familiar. Right now it grabs the latest version of Python 3.7 and installs it to /usr/src/python37/. It uses alt install to prevent conflict with previous versions of python (I've been told CentOS will break if it can't find python 2, a real problem if you use make install).
You could get rid of this section and do it yourself with another version of python. As long as python can be found at /usr/src/python37 and it has django support the installer will continue to chug along happily.
echo "Starting Django project..."
if [ ! -d "/home/$user" ] ; then
mkdir /home/$user
chown -R $user:$user /home/$user
fi
mkdir /home/$user/$projectname
cd /home/$user/
/usr/src/python37/bin/python3.7 -m virtualenv $projectname/venv >> $djalog
source $projectname/venv/bin/activate >> $djalog
pip install django gunicorn psycopg2-binary >> $djalog
cd $projectname
django-admin startproject $projectname >> $djalog
cd /home/$user/
sed -i "s/ALLOWED_HOSTS = \[\]/ALLOWED_HOSTS = \[\"$hostname\"\]/" $projectname/$projectname/$projectname/settings.py
echo "STATIC_ROOT = os.path.join(BASE_DIR, 'static')" >> $projectname/$projectname/$projectname/settings.py
python $projectname/$projectname/manage.py collectstatic
python $projectname/$projectname/manage.py makemigrations
python $projectname/$projectname/manage.py migrate
deactivate
chown -R $user:$user $projectname
cd /root/