Category Archives: Linux - Page 3

My Play Framework Upstart script

Posted by on April 20, 2018 No comments

Recently I had to create a upstart script for a Play application and this was the result of that. I put it here so I don’t have to start from scratch next time 🙂

########################################################################################################
#
#                                       Upstart Script
#
# Upstart script for a play application. Put this into a file like /etc/init/myapp.conf
#
# This could be the foundation for pushing play apps to the server using something like git-deploy
# By calling service play stop in the restart command and play-start in the restart command.
#
# Usage:
#   sudo start myapp
#   sudo stop myapp
#   sudo restart myapp
#   sudo status myapp
#
#########################################################################################################
 
description "Upstart script for MyApp"
author "Niklas Ottosson"
version "1.0"
 
# Set environment variables
env HOME=/my/app/dir/
env LANG=en_US.UTF-8
 
# Start and stop runlevels
start on runlevel [2345]
stop on runlevel [06]
 
# Respawn parameters with limit: dies 3 times within 60 seconds
respawn
respawn limit 3 60
 
# Change directory to current version of Tankmin
chdir /my/app/dir/
 
# Delete any stray PIDs
pre-start script
  rm -f ${HOME}/RUNNING_PID
end script
 
# Upstart logging (/var/log/upstart/myapp.log)
console none
 
# TEST ENVIRONMENT (arguments here are what I'm using for this particular app - you should use what works best for your app)
exec bin/myapp -J-Xms256M -J-Xmx768m -J-server -Dhttp.port=80 -Dconfig.file=conf/application.conf -Dlogger.file=conf/application-logger_PROD.xml

Tested in a production environment on Ubuntu 14.04 and Play Framework 2.3

SSL Certificates: From CSR to a JKS storage

Posted by on November 24, 2014 No comments

I have started doing this quite a lot these days so I’d better put a post up here to get rid of all the Google searching 🙂 It’s not that complicated but I know I will forget if I don’t do it for a while.

Let’s start with creating the CSR
First we create a key

openssl genrsa -out domain.com.key 2048

This will create a private key called domain.com.key and with a key size of 2048 bits

Now it’s time to create the CSR

openssl req -new -sha256 -key domain.com.key -out domain.com.csr

When creating a CSR you need to input some details about the site/organisation that are going to use the certificate, eg.:

Country Name (2 letter code) [AU]:
State or Province Name (full name) [Some-State]:
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:my.domain.name
Email Address []:admin@domain.name

Out of these questions there is one that is CRUCIAL and that is the Common Name. For an SSL certificate this HAS to be the domain name with or without a subdomain that the certificate is going to be valid for, so if the URL that is called my.domain.com the Common Name should be “my.domain.com” and if it is called domain.com the Common Name should be “domain.com”

After these questions have been answered the openssl program creates a CSR file called domain.com.csr that we can send to our certificate supplier (DigiCert/Go-Daddy/Amazon and many others). The supplier will then get back to us with a certificate, root certificate and maybe some intermediate certificates

When we have received the certificates from our supplier it is time to start assembling the signed key .p12 file. For this we use the domain.crt (supplier) and domain.com.key_nopasswd (same key we created in the beginning) files.

First we remove any password from the key file (depending on application this might not always be necessary) 

openssl rsa -in domain.com.key -out domain.com.key_nopasswd

You will be prompted for the password of your .key file

Once the key file is without a password we can create the .p12 file

openssl pkcs12 -export -name somename -in domain.crt -inkey domain.com.key_nopasswd -out keystore.p12

Now we have the .p12 file. Time to put it into the jks container

keytool -importkeystore -destkeystore mykeystore.jks -srckeystore keystore.p12 -srcstoretype pkcs12 -alias somealias

Lastly we need the CA and any intermediate certificates (one command run per certificate file)

keytool -import -keystore mykeystore.jks -file someca.crt -alias someotheralias

The jks is now ready for use!

Tested on Ubuntu 16.04 (AWS) and Play Framework 2.3

Setup Trac project on Debian Wheezy with Apache using the mod_wsgi and Basic Authentication

Posted by on July 23, 2013 2 comments

I had a lot of trouble understanding the Trac install instruction on the Trac project homepage. Maybe I’m getting old 🙂 Anyhow, I decided to create this step by step tutorial so that I have something easy to return too the next time I need to setup a new Trac project. In this tutorial I assume that all the necessary programs (Apache (with mod_wsgi), Trac and SQlite) are already installed

So lets start off by creating a folder to put our project in:

mkdir /var/trac/my_project

I place my trac instances in /var/trac/ but you can use almost any location

Now lets use trac-admin to create the project

trac-admin /var/trac/my_project initenv
trac-admin /var/trac/my_project deploy /tmp/deploy

The project is now created and deployed, but I have deployed it to /tmp – strange? I certainly think so but it’s apparently the preferred way. Somehow trac-admin can not deploy the necessary script into you project folder. You have to copy them there yourself. Editors note: Why can’t this be done automatically in the creation of the project

mv /tmp/deploy/* /var/trac/my_project/

This now moves the created scripts in htdocs and cgi-bin folders to your project

Now we need to set the correct ownership (this is not my strong suite so please report any errors) of the project files:

chown -R www-data:www-data /var/trac/my_project

Now it’s time to create a password file for the project since I normally only use Basic Authentication for my Trac projects:

htpasswd -c /var/trac/my_project/.trac.htpasswd niklas

This creates the user niklas inside the password files (you will be promted for a password)

To add more users just drop the -c option like this

htpasswd /var/trac/my_project/.trac.htpasswd another_user

To tighten up the security somewhat we set owner and permission on the password file like this:

chmod 640 /var/trac/my_project/.trac.htpasswd
chown root:www-data /var/trac/my_project/.trac.htpasswd

Now lets add these users to the trac project also. First the admin, niklas

trac-admin /var/trac/my_project permission add niklas TRAC_ADMIN

and then a user with basic privileges (create tickets, read wiki, timeline, milestones and such):

trac-admin /var/trac/my_project permission add anotheruser authenticated

We are now finally done with the project files. Time to move on to the Apache configuration. For this I create a file in the conf.d folder of the Apache installation like this:

vim /etc/apache2/conf.d/my_project

In this file I put the following:

<Directory /var/trac/my_project/cgi-bin/trac.wsgi>
  WSGIApplicationGroup %{GLOBAL}
  Order deny,allow
  Allow from all
</Directory>

<VirtualHost *>
  WSGIScriptAlias /trac/my_project /var/trac/my_project/cgi-bin/trac.wsgi
  <Location '/trac/my_project'>
    AuthType Basic
    AuthName "Trac"
    AuthUserFile /var/trac/my_project/.trac.htpasswd
    Require valid-user
  </Location>
</VirtualHost>

Now its finally time to test the new project. Restart Apache

/etc/init.d/apache2 restart

If all goes well you should now be able to find your new Trac project at http://localhost/trac/my_project. You should also be promted for a login when you arrive there

Tested on Debian Wheezy v7.0 with Apache 2 v2.2.22-13 and Trac v0.12.3