PostgreSQL Remote Connections

The default value is localhost, which allows only local connections to be made. While client authentication allows fine-grained control over who can access the server, listen_addresses controls which interfaces listen for connection attempts, which can help prevent repeated malicious connection requests on insecure network interfaces. This parameter can only be set at server start.

To enable remote access to PostgreSQL, you have to get the server listening on an interface with routing capability and add a trust entry to permit connections from specific hosts or networks. This is done in the file /var/lib/pgsql/data/postgresql.conf.

listen_addresses = '*'

This will get the server process listening on the other interfaces. Alternatively, you could specific the IP addresses to listen, if you want only specific interfaces to listen for client connections.

listen_addresses = ''

Next, add trust entries for clients that need network access. This is done in the file /var/lib/pgsql/data/pg_hba.conf.

host    all             all            trust
host    all             all            trust

This will get you started with PostgreSQL.

Oct 13th, 2018 • Filed under Databases, PostgreSQL

Django Bootstrap Extra Form Buttons

This is how I have been implementing extra buttons on my forms via Django Bootstrap.

# In context of form model
class XUpdateForm(forms.ModelForm):
def clean(self):
	cleaned_data = super(XUpdateForm, self).clean()

	# Add action to clean data
	cleaned_data['action'] =['action']

	return cleaned_data

Now in the view responsible for this form

form = XUpdateForm(request.POST)

obj =
obj = q_id
obj = user_id

# Process valid forms only
if form.is_valid():
	action = form.cleaned_data['action']

In the template that renders the form and buttons, we add name and value arguments to our boostrap_button calls.

{% bootstrap_button "Update" name="action" value="update" button_type="submit" %}
{% bootstrap_button "Remove" name="action" value="remove" button_type="submit" %}

Happy coding!

Dec 9th, 2017 • Filed under Django, Python

Connect to Virtual Machine Console from XenServer Command Line

Simple shell script to help with connecting to VM console from the command line.

DOMID=$(xe vm-list uuid=$1 params=dom-id --minimal)
HOSTUUID=$(xe vm-list uuid=$1 params=resident-on --minimal)
NAMELABEL=$(xe host-list uuid=$HOSTUUID params=name-label --minimal)
XL=$(which xl)

if [ "${MYHOSTNAME}-" == "${NAMELABEL}-" ]; then
        echo "locally resident"
	ps aux | grep vnc | grep "/$DOMID/" | awk '{print $2}' | xargs kill >/dev/null 2>/dev/null
        echo "Connecting, use Ctrl-] to disconnect."
	$XL console $DOMID
        echo "resident on $NAMELABEL, domid=$DOMID"

A session would something like this.

[[email protected] ~]# ./ 2718f399-e4b5-cbcc-e924-c9464ccaf343
locally resident
Connecting, use Ctrl-] to disconnect.
login: timed out after 60 seconds

dev login:

The script can be found in the Downloads section.

Nov 7th, 2017 • Filed under XenServer

Django Multiple Settings Structure

In my Django projects, I tend to break out into multiple files. This keeps settings for different environments separate from each other. You might want to have debug settings for development environments only. Example settings structure:

(cormier) [[email protected] cormier]$ ls cormier/settings/
(cormier) [[email protected] cormier]

At the top of settings files import base settings.

from .base import *

The settings can be used in two ways, from the command line using –settings parameter.

python manage runserver --settings=cormier.settings.development

or using the environment variable DJANGO_SETTINGS_MODULE.

export DJANGO_SETTINGS_MODULE=cormier.settings.development

If you are experiencing an error message similar to the following:

ImportError: No module named settings.development

Note when you create the settings directory, add an empty file or Python will fail to recognize it as a module.

Happy coding!

Oct 12th, 2017 • Filed under Django, Python

API Gateway Path Parameters to Lambda Functions

I have been poking around AWS API Gateway and was trying to access the path parameters from a NodeJS Lambda function handler. To achieve this access we need to create a mapping. Resources -> Integration Request. Expand Body Mapping Templates.

Type application/json and include something like the following:

     "param1": "$input.params('param1')"

This would map the request parameter param1 to event variable param1, the names aren’t important, and don’t have to match.

Retrieve value from within NodeJS handler function:

var param1 = event.param1;

More information can be found here.

Note: Lambda proxy integration will pass all parameters from the HTTP(S) request to the Lambda function.

Mar 8th, 2017 • Filed under Amazon Web Service, API Gateway, Lambda