Last Day of Internship

Today was the last day of my internship at Preseed. I had great experience working here and the environment is great for development. I will miss days spent here. Time to go on a different road now. Also, report making is toughest job 😛

Testing of the Application

My coordinator pointed out some changes to be made in the application and also some errors he encountered during the testing. Today, I corrected those minor errors and made changes as suggested. As far as my report goes, I have completed first and second chapter of the report.

OpenShift: Installing Python/Django and MySql

In OpenShift cartridges are the packages and OpenShift comes with some pre-loaded packages/cartridges like python and mysql.

The Python Cartridges

The python cartridges provide Python on OpenShift. Currently OpenShift Online supports Python 2.6, 2.7, and 3.3. Creating different versions is as easy as just changing the number on the cartridge:

$ rhc app create my2_6app python-2.6

$ rhc app create my2_7app python-2.7

$ rhc app create my3_3app python-3.3


Getting  a MySQL backend deployed onto OpenShift is as easy as executing one command:

$ rhc cartridge add mysql-5.5 -a MyApp

Installing rhc client tools for using OpenShift

Finally, Today my project was complete and was ready to be deployed on OpenShift Server. Before Deploying the product, I have to install rhc client on my laptop to access it remotely.OpenShift rhc can be run on any operating system with Ruby 1.8.7 or higher assuming you have the requisite user permissions to install programs. The steps are as follow to install rhc client on Elementary OS(Ubuntu 12.04) :

 

Installing the Client Tools via dpkg

The quickest way of installing the tools is using the Debian package. It is available in Debian stable and Ubuntu vivid or later. If you use a previous version of Ubuntu, refer to the Ruby gem method.

From terminal, run the following command (requires sudoer or root access):

$ sudo apt-get install rhc



Installing the Client Tools via Ruby gem

Installing the client tools this way on Ubuntu or Debian requires sudoer or root access and comprises three steps:

Step 1: Install Ruby with RubyGems

Step 2: Install Git

Step 3: Install the client tools

Step 1: Install Ruby with RubyGems

From terminal, run the following command to install Ruby:

$ sudo apt-get install ruby-full

Run the following command to verify that Ruby has installed correctly:

$ ruby -e 'puts "Welcome to Ruby"'
Welcome to Ruby

Rubygems are now part of the ruby package. However, with older Ubuntu repositories, you may need to run the following command to explicitly install RubyGems:

$ sudo apt-get install rubygems

Step 2: Install Git

Run the following command to install Git version control:

$ sudo apt-get install git-core

After installation completes, run the following command to verify that Git has installed correctly:

$ git --version

This command returns the Git version number that was installed.

Step 3: Install Client Tools

When the required software has been successfully installed, run the following command to install the client tools:

$ sudo gem install rhc


Setting up Your Machine

After installation is complete, open a Terminal window and run:

$ rhc setup

The OpenShift interactive setup wizard displays and prompts you to complete the rest of the process.

You’ll be prompted for your OpenShift username and password:

Login to openshift.redhat.com: user@example.com
Password: password

You are then prompted to generate an authorization token. Answering yes stores a token in your home directory to be used on subsequent requests. When it expires, you are prompted for your password again.

OpenShift can create and store a token on disk which allows to you to access the server without using your password. The key is stored in your home directory and should be kept secret. You can delete the key at any time by running 'rhc logout'.
Generate a token now? (yes|no) yes
Generating an authorization token for this client ... lasts about 1 day

After creating a configuration file, setup will configure SSH keys so that your system can remotely connect to your applications, including deploying your applications using Git:

No SSH keys were found. We will generate a pair of keys for you.
Created: C:\Users\User1\.ssh\id_rsa.pub


After the new SSH keys are generated, the public key, id_rsa.pub, must be uploaded to the OpenShift server to authenticate your system to the remote server. Enter a name to use for your key, or leave it blank to use the default name. In the following example the default name is used.

Your public ssh key must be uploaded to the OpenShift server to access code.
Upload now? (yes|no) yes

Since you do not have any keys associated with your OpenShift account, your new key will be uploaded as the 'default' key

Uploading key 'default' from C:\Users\User1\.ssh\id_rsa.pub ... done

After verifying that Git is installed, you will be asked to set up your domain if you don’t already have one:

Checking for a domain ... none

Your domain is unique to your account and is the suffix of the public URLs we assign to your applications. You may configure your domain here or leave it blank and use 'rhc domain create' to create a domain later. You will not be able to create applications without first creating a domain.

Please enter a domain (letters and numbers only) |<none>|: MyDomain
Your domain name 'MyDomain' has been successfully created

Finally, the setup wizard verifies whether any applications exist under your domain. In the example below, no applications have been created. In this case the setup wizard shows the types of applications that can be created with the associated commands. The setup wizard then completes by displaying the current gear consumption along with the gear sizes available to the given user.

Checking for applications ... none

Run 'rhc app create' to create your first application.

Do-It-Yourself                            rhc app create <app name> diy-0.1
JBoss Application Server 7.1              rhc app create <app name> jbossas-7
JBoss Enterprise Application Platform 6.0 rhc app create <app name> jbosseap-6.0
Jenkins Server 1.4                        rhc app create <app name> jenkins-1.4
Node.js 0.10                              rhc app create <app name> nodejs-0.10
PHP 5.3                                   rhc app create <app name> php-5.3
PHP 5.4                                   rhc app create <app name> php-5.4
Perl 5.10                                 rhc app create <app name> perl-5.10
Python 2.6                                rhc app create <app name> python-2.6
Python 2.7 Community Cartridge            rhc app create <app name> python-2.7
Python 3.3 Community Cartridge            rhc app create <app name> python-3.3
Ruby 1.8                                  rhc app create <app name> ruby-1.8
Ruby 1.9                                  rhc app create <app name> ruby-1.9
Tomcat 6 (JBoss EWS 1.0)                  rhc app create <app name> jbossews-1.0
Tomcat 7 (JBoss EWS 2.0)                  rhc app create <app name> jbossews-2.0
Zend Server 5.6                           rhc app create <app name> zend-5.6

You are using 0 of 3 total gears
The following gear sizes are available to you: small

Your client tools are now configured.

You are now ready to create and manage an application using OpenShift.

OpenShift: Terminology

There is some basic terminology that is specific to OpenShift to describe the platform. It is important to clarify these terms since they will be used throughout your interactions with OpenShift:

Application:
This is your typical web application that will run on OpenShift. At this time, OpenShift is focused on hosting web applications. With this in mind, and to try to provide some security for your applications, the only ports exposed to incoming traffic are HTTP (80), HTTPS (443), and SSH (22). OpenShift also provides beta WebSocket support on HTTP (8000) and HTTPS (8443).

Gear:
A gear is a server container with a set of resources that allows you to run their applications. Your gears run on OpenShift in the cloud. There are currently three gear types on OpenShift Online: small, medium, and large. Each size provides 1 GB of disk space by default. The large gear has 2 GB of RAM, the medium gear has 1 GB of RAM, and the small and small.highcpu gears have 512 MB of RAM.

Cartridge:
To get a gear to do anything, you need to add a cartridge. Cartridges are the plug-ins that house the framework or components that can be used to create and run an application. One or more cartridges run on each gear, and the same cartridge can run on many gears for clustering or scaling. There are two kinds of cartridges:

Standalone:
These are the languages or application servers that are set up to serve your web content, such as JBoss, Tomcat, Python, or Node.js. Having one of these cartridges is sufficient to run an application.

Embedded:
An embedded cartridge provides functionality to enhance your application, such as a database or Cron, but cannot be used on its own to create an application.

For some of the OpenShift partner cartridges in the Marketplace, the cartridges only install environment variables that make it easier to connect to the partner hosted service.

Scalable application:
Application scaling enables your application to react to changes in traffic and automatically allocate the necessary resources to handle your increased demand. The OpenShift infrastructure monitors incoming web traffic and automatically brings up new gears with the appropriate web cartridge online to handle more requests. When traffic decreases, the platform retires the extra resources. There is a web page dedicated to explaining how scaling works on OpenShift.

 

Client tools, Web Console, or Eclipse plug-ins:
You can interact with the OpenShift platform via RHC client command-line tools you install on your local machine, the OpenShift Web Console, or a plug-in you install in Eclipse to interact with your application in the OpenShift cloud. The only time you must use these tools is when you are managing the infrastructure or components of your application. For example, you would use these tools when creating an application or embedding a new cartridge. The rest of your work with your application will happen through Git and SSH.

OpenShift Server: Introduction

The product I am working is going to be able to be deployed on OpenShift Server. I will be explaining a little about OpenShift in this blog. Without further adieu, Lets start.

What is OpenShift?

OpenShift Online is Red Hat’s public cloud application development and hosting platform that automates the provisioning, management and scaling of applications so that you can focus on writing the code for your business, startup, or big idea.

 

OpenShift Runtime Environments

OpenShift Online supports a variety of technologies through use of cartridges, including Java (Wildfly, JBossEAP, Tomcat), PHP,Node.js, Python, Perl, MySQL, PostgreSQL, MongoDB, Jenkins, Cron, and JBoss xPaaS Services (Fuse, BPM Suite, BRMS, Data Virtualization, Aerogear, and more).

 

The OpenShift Development Environment

There are a number of tools that can enhance your OpenShift experience and match your style of development. From command line scripts that you can use to automate tasks to the Web Console and even a fully integrated IDE. Below are links to a number of these tools along with getting started guides and other helpful documents to get you up and running fast.

Web Console

An easy to use resource for managing your applications from anywhere. You can create applications, add and remove cartridges and edit account details.

RHC Client Tools

The OpenShift client tools make it easy to create and deploy applications, manage domains, control access to your OpenShift applications, and give you complete control of your cloud environment.

JBoss Developer Studio

JBoss Developer Studio, with its Eclipse Based integrated development environment, gives developers everything they need to build rich web applications and transactional enterprise applications. Integrates with the OpenShift platform to put the ability to create, edit and deploy applications right at your fingertips.

Django method decorators for CBVs

To decorate every instance of a class-based view, you need to decorate the class definition itself. To do this you apply the decorator to the dispatch() method of the class.

A method on a class isn’t quite the same as a standalone function, so you can’t just apply a function decorator to the method – you need to transform it into a method decorator first. The method_decorator decorator transforms a function decorator into a method decorator so that it can be used on an instance method.

The login_required decorator

login_required(redirect_field_name=’next’, login_url=None)
As a shortcut, you can use the convenient login_required() decorator:

from django.contrib.auth.decorators import login_required

@login_required
def my_view(request):
    ...

login_required() does the following:

  • If the user isn’t logged in, redirect to settings.LOGIN_URL, passing the current absolute path in the query string. Example: /accounts/login/?next=/polls/3/.
  • If the user is logged in, execute the view normally. The view code is free to assume the user is logged in.

By default, the path that the user should be redirected to upon successful authentication is stored in a query string parameter called "next". If you would prefer to use a different name for this parameter, login_required() takes an optional redirect_field_name parameter:

from django.contrib.auth.decorators import login_required

@login_required(redirect_field_name='my_redirect_field')
def my_view(request):
    ...

Note that if you provide a value to redirect_field_name, you will most likely need to customize your login template as well, since the template context variable which stores the redirect path will use the value of redirect_field_nameas its key rather than "next" (the default).

login_required() also takes an optional login_url parameter. Example:

from django.contrib.auth.decorators import login_required

@login_required(login_url='/accounts/login/')
def my_view(request):
    ...

Note that if you don’t specify the login_url parameter, you’ll need to ensure that the settings.LOGIN_URL and your login view are properly associated. For example, using the defaults, add the following lines to your URLconf:

from django.contrib.auth.decorators import login_required
from django.utils.decorators import method_decorator
from django.views.generic import TemplateView

class ProtectedView(TemplateView):
    template_name = 'secret.html'

    @method_decorator(login_required)
    def dispatch(self, *args, **kwargs):
        return super(ProtectedView, self).dispatch(*args, **kwargs)

In this example, every instance of ProtectedView will have login protection.

Limiting access to logged-in users that pass a test

To limit access based on certain permissions or some other test, you’d do essentially the same thing as described in the previous section.

The simple way is to run your test on request.user in the view directly. For example, this view checks to make sure the user has an email in the desired domain and if not, redirects to the login page:

from django.shortcuts import redirect

def my_view(request):
    if not request.user.email.endswith('@example.com'):
        return redirect('/login/?next=%s' % request.path)
    # ...
user_passes_test(func, login_url=None, redirect_field_name=’next’)
As a shortcut, you can use the convenient user_passes_test decorator which performs a redirect when the callable returns False:

from django.contrib.auth.decorators import user_passes_test

def email_check(user):
    return user.email.endswith('@example.com')

@user_passes_test(email_check)
def my_view(request):
    ...

user_passes_test() takes a required argument: a callable that takes a User object and returns True if the user is allowed to view the page. Note that user_passes_test() does not automatically check that the User is not anonymous.

user_passes_test() takes two optional arguments:

login_url
Lets you specify the URL that users who don’t pass the test will be redirected to. It may be a login page and defaults to settings.LOGIN_URL if you don’t specify one.
redirect_field_name
Same as for login_required(). Setting it to None removes it from the URL, which you may want to do if you are redirecting users that don’t pass the test to a non-login page where there’s no “next page”.

For example:

class QuestionFormView(FormView):
form_class = QuestionForm
success_url = “/userdashboard/”
template_name = “form.html”

def test_isuser(user):
if user.is_org and not user.first_login:
return False
else:
return True

@method_decorator(user_passes_test(test_isuser,login_url=’/’))
def dispatch(self, *args, **kwargs):
return super(QuestionView, self).dispatch(*args, **kwargs)

Finishing Up the Project

Now, after completing all the modules, it is the time to link modules. To link modules, I used navigation links in html to keep everything look like connected to each other. Like after login user redirected to dashboard or after editing form going back to dashboard, stuff like this. Also, I have to restrict access to specific type of user. For this, i have used inbuilt method decorators like login_required etc.