statsd With nodejs On FreeBSD

Getting statsd to run on FreeBSD 8.2 was a breeze!

nodejs

$ sudo portmaster www/node

statsd

$ curl -C - -L -o statsd.zip https://github.com/etsy/statsd/zipball/master
$ unzip statsd.zip
$ mv <statsd unzip> statsd
$ cd statsd
$ cp exampleConfig.js yourmachineConfig.js
$ vi yourmachineConfig.js
$ node stats.js yourmachineConfig.js

supervisord Entry

[program:statsd]
command=/usr/local/bin/node stats.js yourmachineConfig.js
directory=/path/to/statsd/
user=someuser
autostart=true
autorestart=true

Good luck!

supervisor Entries For Graphite

TLDR

Below are entries for supervisor to start carbon and Graphite. I found some hints from this file on bitbucket.

supervisord.conf

[program:x] entries.

[program:graphite]
; django gunicorn instance for graphite
command=/home/someuser/devel/graphite/bin/gunicorn_django --config=/home/someuser/devel/graphite/etc/gunicorn.py --pid=/home/someuser/devel/graphite/var/gunicorn.pid webapp/graphite/
environment=PYTHONPATH="/home/someuser/devel/graphite"
user=someuser
autostart=true
autorestart=true
directory=/home/someuser/devel/graphite/

[program:carbon]
; this is the only way to get carbon to start
; in a manner that supervisor understands.
; --debug is REQUIRED (apparently)
command=/home/someuser/devel/graphite/bin/carbon-cache.py --debug start
directory=/home/someuser/devel/graphite/
environment=PYTHONPATH="/home/someuser/devel/graphite"
user=cdcd
autostart=true
autorestart=true

Some quick notes.

1. I tried to start carbon without "--debug," by specifying the virtualenv's python application, and a few other things I have since forgotten. This way is the first one that worked.
2. Everything is in a virtual environment. I explained the setup here.

Good luck!

Graphite In A virtualenv In A Jail

I am attempting to put Graphite in a virtualenv in a FreeBSD 8.2 jail. It is not that straight-forward. However, I have things working!

Follow for more.

Python Update Breaks virtualenv

Just a quick note that upgrading Python to version 2.7.3 will break current virtualenv's. There is a nice blurb on virtualenv.org.

The solution seems trivial enough: remove bin/python and rerun the virtualenv command. This process will also overwrite bin/activate, so be careful if you have made changes to this file.

$ cd /some/virtualenv/project
$ rm bin/python
$ cd ..
$ virtualenv project

Limit postgres User To A Schema

I am getting ready to launch a web site for public consumption. As a result, I want to restrict the database user my application will be using. Up to this point, I was testing with an admin user.

The goal is to restrict access to just one schema and a few objects.

postgres=# CREATE ROLE someuser WITH LOGIN PASSWORD 'password goes here';
CREATE USER
postgres=# GRANT CONNECT ON DATABASE somedatabase TO someuser;
GRANT CONNECT
postgres=# GRANT USAGE ON someschema TO someuser;
GRANT USAGE
postgres=# ALTER ROLE someuser SET search_path TO someschema;
ALTER ROLE
postgres=# GRANT SELECT ON sometable TO someuser;
GRANT SELECT

First, the role (user) is created with the ability to login. Next, the user is given permission to connect to a database and then use a specific schema. The user's search_path is then restricted to just the desired schema.

Finally, access to objects are granted. Remember to include sequences!

New PostgreSQL Databases And The Users That Own Them

A quick post on how to create new databases with owners other than 'postgres'.

$ psql postgres
postgres=# CREATE USER someuser WITH PASSWORD 'password goes here';
CREATE USER
postgres=# CREATE DATABASE newDatabase WITH OWNER = someuser;
CREATE DATABASE

A quick, random password can be created using /dev/random:

$ head -c 10 /dev/random | uuencode -m -