In WordPress 3.3.1 the extra ‘return’ now stays in your text after saving your pages and posts.

Ever wanted to have an extra white line in your post just because it looks nice? Searched the forums and all you got was replies to go straight into the CSS code? … But I just want that 1 line d*mned …

Mind you, It’s beyond dirty but very effective. Here’s how:

Put a “.” (dot) on a new line and give it the same color as the background.

.

Regards,

Gerard.

P.S. noticed the space above “Regards,” …

Ever had the pleasure of supporting a development team in their efforts to reach deadlines and therewith smoothing out the deployment process? It can be a complex task when the deployment covers multiple servers at once. From a sysadmin point of view you are concerned with network and naming conventions of your web-, database- and possibly other servers.

The context

Nevertheless, you need to communicate with the developers about this without overloading them with network details. Practically a set of server names should be enough for their deployment configuration. Of course I’m primarily talking about framework based application deployment running on Django, Rails and so on.

When handling SSL only websites there’s the IP address per website restriction (not taking SNI into account). Then there’s the gray area; The configuration parts that are both server and application related. Doing an article on Apache 2.x trickery I’m talking about the VirtualHost setup, but there are others to consider like logrotation, cron vs. application framework jobs, etc.

Having peeked, this article indeed describes a setup that involves Apache and how to ease the work of the development team. Before taking of I’d like to add one more detail into the mix. For design reasons I consider it good practice to have a seperate IP to address a server besides the ones you use for your services as web, database, file uploads or any other. This separates traffic to your server for e.g. monitoring, backups, abuse filtering, security, etc. next to your regular service traffic.

Having such a clean setup, but also for security reasons, setting up Apache with 0.0.0.0:443 or *:443 doesn’t fit in my opinion (better explicit then implicit).

Having set the context I’ll get into the technical details.

The setup

As was written we need a ‘VirtualHost’ setup that is transparent to the developers but should contain all information for Apache to operate properly.  Besides necessary modules and what not the snippet below displays the minimal required configuration directives.

NameVirtualhost 1.2.3.4:443
Listen 1.2.3.4:443

<Virtualhost 1.2.3.4:443>

    # Your vhost config

</Virtualhost>

Note: I’m putting the listen statement in the virtualhost config file and not in Apache’s ports.conf to keep things contained with the application’s configuration. Here’s the first conflict because this would mean different configs in de developers codebase for every server they deploy on. We’ll resolve that in a minute.

Apache symlink intermezzo

More on keeping things contained along side your application, mainly for upscale portability, we put the file with Apache’s vhost config in an etc directory under the application codebase. E.g: [app basedir]/etc/apache.conf

Usually, with Apache, site configurations are stored in /etc/apache2/sites-available and they are enabled when symlinked to from /etc/apache2/sites-enabled.

When putting the vhost configuration under your app codebase you simply link from ‘sites-enabled’ to that location.

$ cd /etc/apache2/sites-enabled
$ ls -l
total 0
lrwxrwxrwx 1 root root   74 2011-05-04 19:47 www.example.com -> /home/appuser1/sites/www.example.com/config/etc/apache.conf
lrwxrwxrwx 1 root root   79 2011-05-04 19:48 www.other.com -> /home/appuser2/sites/www.other.com/config/etc/apache.conf
lrwxrwxrwx 1 root root   71 2011-06-10 15:22 another.other.com -> /home/appuser2/sites/another.other.com/config/etc/apache.conf

The thing to lookout for when running multiple apps: the symlink sourcename must be set different from the name ‘apache.conf’ otherwise you get a name conflict in the /etc/apache2/sites-enabled directory. This is done with the ‘ln’ command in de following manor:

$ cd /etc/apache2/sites-enabled
$ ln -s /home/appuser1/sites/www.example.com/config/etc/apache.conf www.example.com

Now that we know what goes where we can work on the relation between the IP adresses and the different applications or vhosts.

Installing the glue

We need mod_define for this, found here: mod_define. With this module we have the ability to set $variables within the Apache configuration files.

Installation is rather simple. Download it and run (as root):

$ apxs2 -i -a -c mod_define.c

Good chance the module is automatically enabled using the apxs2 command but that might depend on your distro. Otherwise you can either use a2enmod or simply symlink between /etc/apache2/mods-available and /etc/apache2/mods-enabled. The file your looking (linking) for contains the following:

$ cat /etc/apache2/mods-enabled/define.load
LoadModule define_module      /usr/lib/apache2/modules/mod_define.so

Enable the module linking it like so:

$ cd /etc/apache2/mods-enabled
$ ln -s ../mods-available/define.load

Note that your installed module, as configured in ‘define.load’, might end up elsewhere under ‘/usr/…. ‘ depending on your distro.

The glue in effect

Besides the seemingly complicated context it simply comes down to a list of variable names containing IP adress/port number combinations. The below example should explain this.

<IfModule define_module>
    # IP's are example public addresses
    Define bind_address_www_example_com 1.2.3.4:443
    Define bind_address_www_other_com 2.3.4.5:443
</IfModule>

After making sure the module is enabled we place the ‘vhost_bind_adresses.conf’ file in ‘/etc/apache2/conf.d’. After this file has been set up we can use the defined variables in our VirtualHost configuration. These are about the only thing that the development team should stick to (assuming the vhost file is included in their codebase). Considering the file wherein we defined the variables a vhost file looks like this:

Listen $bind_address_www_example_com
NameVirtualHost $bind_address_www_example_com

<VirtualHost $bind_address_www_example_com>

    ServerName www.example.com
    ServerAdmin webmaster@example.com

    LogLevel warn
    CustomLog /home/appuser1/sites/www.example.com/log/apache.access.log combined
    ErrorLog /home/appuser1/sites/www.example.com/log/apache.error.log

    DocumentRoot /home/appuser1/sites/www.example.com/

    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/www.example.com.cert
    SSLCertificateKeyFile /etc/ssl/certs/www.example.com.key

    # <-- SNIP -->

</VirtualHost>

Note: As said, the Listen and NameVirtualHost directives are in de vhost file instead of the ports.conf.

The beauty of this setup is that we can shuffle our server configuration without any changes to the developers code base. Creating/deploying new apps simply means adding a variable to ‘vhost_bind_adresses.conf’ and updating the development team about the name.

Gotcha’s

Not much I can think of. If you agree on a variable name with the development team that is unambiguous, for instance: $bind_addr_www_domain_com there’s not much that can go wrong.

One more tip: Learn yourself to use apache2ctl -t after changing stuff because restarting Apache while having syntax errors results in only stopping Apache. Which in it’s turn causes already running websites being unavailable for your audience.

Any comments or questions are welcome.

GrtzG

Case exploration

In this example I use my own setup but it should be doable on any host/guest OS combination. My setup is a Macbook running OSX snow leopard with a guest OS running Ubuntu server. Before getting into the details; The trick is to hook up Ubuntu’s eth0 to one of your normal interfaces (physical or wifi) and link Ubuntu’s eth1 to a virtual network device in your host OS. In this setup you always have local (back-end) access to your virtual guest OS and whenever you have Internet access so does your guest OS.

The details

I’m assuming you’re already running Virtualbox on OS X and an Ubuntu installation as guest OS. First we need to create a virtual network interface to which we can ‘link’ our eth1. For this we need a driver that emulates a network device. Typically we need a tun/tap driver. Therefore download and install Tuntap for OS X. In the Virtualbox network configuration for the guest OS we need to configure (and enable) the second ethernet adapter and set it as ‘host only’.

NB: the name vboxnet0 will be changed to be tap0 but that will be handled in a minute.

To setup the virtual interface you need to download and run the following script: tap.sh. Running tap.sh (as root) will create a virtual network device that can be used for Ubuntu’s eth1 to hook into. Whilst having the tap0 device operational with IP address 10.10.10.1 the following commands will set the Virtualbox settings for Ubuntu to bind to it.

List your VM’s and pick the right one:

$ VBoxManage list vms

Enable the 2nd network interface of your VM

$ VBoxManage modifyvm [VM name] --intnet2 hostif

Set the interface to ‘host only’:

$ VBoxManage modifyvm [VM name] --hostonlyadapter2  tap0

Note: The last command(s) seem obsolete since the release of Virtualbox version 4.0.4 r70112 or later. In older versions the tap0 used to fallback to vboxnet0 after closing Virtualbox. But the network configuration is now persistent when set to device tap0. So, depending on the version you use your mileage may vary. Test it with restarting Virtualbox and see if your VM network config looks similar to this:

Running that last command once will suffice for the long run instead of between every Virtualbox or workstation startup (besides the tap.sh script that is).

That being said, you’re now ready to start the Ubuntu VM. You should probably access Ubuntu via the front-end nic the first time since the back-end nic in the guest OS isn’t configured yet. Having logged into Ubuntu you should setup your interfaces as follows. For eth0 you can either choose static or dhcp, whatever runs easiest on your network. Setup Eth1 as static in network segment 10.10.10.0/24, e.g. 10.10.10.2 with 10.10.10.1 being your tap0 hosts OS interface.

Either reboot your Ubuntu VM, or nicer, restart the network with:

$ /etc/init.d/networking restart

You should now be able to login on Ubuntu with:

$ ssh you@10.10.10.2

Now unplug your physical network connection in your host OS (that’s Ubuntu’s eth0) and you can still login on your VM via the 10.10.10.0/24 network.

Gotcha’s

The only one I can think of is the need to manually add the default route to the outside world over etho. This happens when the host OS’s physical network has been disconnected. I assume it’s because Ubuntu’s eth0 has been down with which the route is dropped. You can easily resolve this with the following command:

$ ip route add default via [your gateway's IP]

If you have any questions or comments please feel free to drop me a line.

References

- The inspiration for this article: http://tinyurl.com/6z29w45
- OSX’s TunTap driver: http://tuntaposx.sourceforge.net/
- Tun/Tap info on wikipedia: http://en.wikipedia.org/wiki/TUN/TAP
- The tap.sh script: tap.sh

I Developed this commandline tool to make it easier to maintain stuff on a groing amount of servers. nexec is a tool that can help you gather ad-hoc info when it’s needed quickly. nexec is written in python, it depends on codespeak’s pylib, and does all it’s communication over SSH. The only thing you need on ‘the other side’ is a python interpreter. (that’s right, no further libs or modules). Oh, and you need your SSH key pairs in place, otherwise it’s ‘password galore’.

Of course, the bash-ers out there would say that the same functionality can be achieved with a for loop. True! But that’s exactly what nexec does for you so you can concentrate on what you’re doing remote. And ofcourse you can have nightly cron-ed scripts in place that do this every day. But nexec aids in all those things that are not ‘in place’.

Examples

Before getting into any details, first some tricks of the ‘nexec’ trade to get you warmed up …

Are my server systems running the proper time:

$ ./nexec.py -n 'server1 server2  server3' -c 'date'
server2: Fri May 23 16:21:18 CEST 2008
server1: Fri May 23 16:21:17 CEST 2008
server3: Fri May 23 16:21:19 CEST 2008

See if all your servers are running ssh protocol 2 only:

$ ./nexec.py -n 'server1 server2  server3' -c 'cat /etc/ssh/sshd_config | grep -v ^# | grep Protocol' | sort
server1: Protocol 2
server2: Protocol 2
server3: Protocol 2

(You could also do a “-n ALL”, then nexec reads your server list from a config file. More on that in a minute)

Get a list with all different kernel versions that are running on your systems:

$ ./nexec.py -n ALL -q -c 'uname -r' | sort -u
2.6.18-5-686
2.6.18.8-xen

(The “-q” parameter suppresses the ‘per line’ hostname prefix).

See if ‘john’ is a member of the sudo group on servers 1 and 2:

./nexec.py -v -q -n 'server1 server2' -c 'cat /etc/group | grep sudo | grep -v john'
Host:  server1.example.com
sudo:x:27:jane,jerry
Host:  server2.example.com
sudo:x:27:jane

(The”-v” adds the “Host: ….” header, per server output. Note that “-v” and “-q” are interchangeable)

As you can see, by combining local and remote greps and using the -v and/or -q parameters there are some interesting ways to obtain live data from your server.

Lets look at the configuration.

Configuration

Run without parms, nexec shows help output. Furthermore the only two files nexec depends on (and not even necessarily) are a “~/.nexec.conf” file and a possible “~/.ssh/config”.

The “~/.nexec.conf” does not contain much, just “key: value” pairs under a hosts section. The actual ‘value’ is only obtained when using the “-v” option to display the header above each server output “Host: server1.example.com“.

$ cat .nexec.conf
[hosts]
server1:   server1.example.com
server2:   server2.example.com
#server3:   server3.example.com

Other then that, nexec simply expands “-c ALL” to all available keys under the “[hosts]” section, skipping the usual hashsign ‘#’ being a comment. In this case the “ALL” parameter given to “-c” would be expanded to “server1 server2″ in the previous example. After that the full name is taken from the “~.ssh/config” file.

$ cat .ssh/config
# server1
Host server1
Hostname server1.example.com
User john
Port 4321
# server2
Host server2
Hostname server2.example.com
User john
Port 4321

I deliberately left all that in there so other usernames and port numbers can be specified. Besides, that’s all access related and shouldn’t be anywhere else anyway.

Then one more note on the “-q” and “-v” option. What they basically do is mark (or suppress mark’s) on the output that get’s returned. So you can mark output per server adding the “-v”, and output get’s marked per line (default) if not suppressed with “-q”.

Download

The script can be downloaded here: nexec-10.tgz

Set the ‘execute’ bit with chmod and put it in your $PATH somewhere. And for the “ALL” parameter, set up the config file as the example shows in the Configuration section.

Gotcha’s

Escape your backticks with with a backslash if you want remote expansion.

This runs the uname part locally and then sends the command to the other side.

$ nexec.py -n ALL -c "date | mailx -s `uname -n` root"

This also executes the uname command on the other side.

$ nexec.py -n ALL -c "date | mailx -s \`uname -n\` root"

Todo

There’s two things still on my list.

• Catch a non-existing hostname when taken from the “.ssh/config” file. The script breaks if a host is not resolvable. (Being a sysadmin you should know what your doing ..
• Make the “Host: server1.example.com” header not show when no output is returned from a host. That is when using the “-c ALL”.

New tricks might be added in the future, so if there’s stuff that you think should be added drop me a reply.

That’s all folks …

I needed this functionality for a web application. There are some variations found on the net from which I constructed this simple but effective python function to get ‘the other’ value.

Based on the original image dimensions “i_…” it figures out whether the image is portrait or landscape and calculates either the width or height.

def calculate_image_resize(i_width, i_height, max=0):

    i_width = float(i_width)
    i_height = float(i_height)
    ratio = i_width / i_height

    print 'w:', i_width, 'h:', i_height, 'r:', ratio

    if i_width < i_height:
        print 'portrait'
        c_height = max
        c_width = max * ratio
    else:
        print 'landscape'
        c_width = max
        c_height = max / ratio

    c_width = int(c_width)
    c_height = int(c_height)

    return c_width, c_height

Dropping the function in a python shell and calling it results in this output:

In [2]: calculate_image_resize(1700, 330, max=150)
w: 1700.0 h: 330.0 r: 5.15151515152
landscape
Out[2]: (150, 29)

In [3]: calculate_image_resize(170, 330, max=150)
w: 170.0 h: 330.0 r: 0.515151515152
portrait
Out[3]: (77, 150)

I deliberately left in the obvious 150 so you know instantly which dimension was calculated “c_…”.

Hope this saves people the trouble to figure it out by them selves.

GrtzG

You can of course create distributable modules or packages but with simple local workstation like maintenance this seems overkill … yep, you are allowed to disagree

So, we need a place to put code that is easy to import in our used scripts and it should be easy to maintain. Dropping it in my homedir in a directory called “.python” seems well suited for this.

The Setup

Create the directory “.python” in your $HOMEDIR. Then add a line to your “.bashrc” to export $PYTHONPATH so when you do an import in python it is actually found.

PYTHONPATH=~/.python
export PYTHONPATH

Python picks up the paths from this variable and adds them to “sys.path” so there’s no need to add the path in every script you make. In individual cases you can of course do it like it is explained here.

Then create a file in “~/.python/” for instance “userconfig.py”.

To make it available in your script simply import it and execute one of your functions.

import userconfig as mystuff
mystuff.function(with, parms)

I’ll give an example of a userconfig.py function to easily send out emails.

import os
import sys
import pynotify
import smtplib
from email.mime.text import MIMEText

# Settings << These are the "Sensible defaults" 
MAILSERVER = 'localhost'
MAILFROM = 'somebody'
MAILTO = 'you@yourdomain.com'

def send_mail(subject, body, fro=MAILFROM, to=MAILTO):
    """
    Stripped function to send mail from local code
    """
    msg = MIMEText(body)
    msg['Subject'] = subject
    msg['From'] = fro
    msg['To'] = to

    s = smtplib.SMTP(MAILSERVER)
    s.sendmail(msg['From'], msg['To'], msg.as_string())
    s.close()

The code above composes and sends an email. Doing all this in the script you are writing results in quite a bunch of these lines ending up in every one of your scripts.

Sensible defaults

How about not having to enter those ‘always the same defaults’? Well … When using the setup described in this article most can be omitted and parameters only need to be added when you deviate from your sensible defaults.

For argument sake I’ll give an example script that just mails something and calls the “send_mail()” function.

import userconfig as user

body = """Some multiline triple quoted body mass\n\nwith lot's of

funky stuff in it."""

fish = 'whale'
subject = 'something fishy: %s' % fish

user.send_mail(subject, body)

So that’s only 1 line for the actual ‘send my mail’ command. Should you want a different FROM address then you just change the function call to this.

user.send_mail(subject, body, 'notme')

Thus, add parms when you need them or rely on your “Sensible Defaults” from your userconfig.py.

You can build a world of functionality in your “~/.python”. Import and use system wide installed packages in there, test if they are present on your system, etc.

Gotcha’s

When using scripts under CRON you need to add the PYTHONPATH to the definition like below because CRON does not read your “.bashrc”.

*/1 * * * *  (PYTHONPATH=~/.python; /path/to/your/script.py)

NB: Mind the parenthesis and semicolon on the line above.

Besides the fact that you should watch for name clashes, I can’t think of any other gotcha’s. If you do, then please teach me something and drop me a line

GrtzG

There definitely are some articles (and forum threads) out there that come close, but this is how it’s done

Some predefs

The goal is to be able to connect to multiple VirtualHost’s on an Apache webserver.

We have a localpc behind a NAT-ed internet connection (yourpc.locality.lan) and the aforementioned publicly accessible webserver on the net somewhere (yourserver.example.com).

I’m assuming you can already connect to your server via SSH, based on a pub/priv keypair.

Local to remote

There are some things that need to be set local AND remote to make sure that Apache knows to which (not publicly accessible) VirtualHost it must redirect your HTTP request. That is, make up a name and put it in your /etc/hosts file and have it resolve to 127.0.0.1. E.g:

$ cat /etc/hosts
127.0.0.1 localhost

# For ssh tunneling
127.0.0.1 mysuperadminsite.locality.lan

Important! You need to put the ‘mysuperadminsite’  entry in your /etc/hosts file on your server as well. Otherwise it won’t work because Apache can’t figure out where this needs to go (more on apache config in a sec).

Then, the actual SSH tunnel command is this:

ssh  -L 9002:mysuperadminsite.locality.lan:80 yourname@yourserver.example.com

There are ofcourse nicer ways to fully hide/automate the SSH tunnel, but by doing it manually like this you are explicitly remembered that you’re in ‘admin-mode’

Apache trickery

Ok, so how does Apache know where to go when your HTTP request hits the server side? As your mysuperadminsite request is resolved to 127.0.0.1 (on the server), apache needs this as a NameVirtualHost. So put this in your global Apache config somewhere.

# For admin work over SSH
NameVirtualHost 127.0.0.1:80

Then you create an apache VirtualHost config with a setup like this.

<VirtualHost 127.0.0.1:80>
	ServerName mysuperadminsite.locality.lan

	# Here you put your docroot, includes, logfile entries and whatever else you want.

</VirtualHost>

And so, apache resolves the request to 127.0.0.1 where, based on the X-Header (containing the mysuperadminsite name) sent by your browser, it actually finds a vhost to handle your request.

This is a very safe way to handle your secure access because the VirtualHost is only handled by apache when it comes in on your loopback interface. Moreover FQDN’s based on “locality.lan” are not resolvable in the outside world.

It does however require a second website instance. You could combine an externally accesible VirtualHost by starting your config with this.

<VirtualHost [external_ip]:80, 127.0.0.1:80>

This way you don’t have to have a second VirtualHost config (and thus website instance) for management. But it’s easier to overlook going secure and thus have your passwords or whatever sniffed.

Gotcha’s

None that I know of, but feel free to point them out

Safe computing!

After researching and setting up two FormWizards in Django I concluded some things that might be useful to others. Hence this post.

Having userdata available throughout the wizard

I’ve seen some solutions on the net for this but when you handle data from several models over different steps the best way to handle this is using Django’s session framework. In parse_params() in the beginning and end we repectively get/set data and store our data.

def parse_params(self, request, *args, **kwargs):
    current_step = self.determine_step(request, *args, **kwargs)
    form = self.get_form(current_step, request.POST)

    # Pickup the dict from the users session or create a new one
    wizdata = request.session.get('wizdata') or {}

    # Your code goes here. E.g. set a value in the dict
    wizdata['some_key'] = 'Some value'

    # Store the possibly changed dict back in the users session.
    request.session['wizdata'] = wizdata

So whatever you do with the user data, it’s safe, and we can access it in any step throughout the wizardry.

def render_template(self, request, form, previous_fields, step, context=None):
    wizdata = request.session.get('wizdata')

    # Your other code goes here. E.g. a conditional on previously set data.
    if wizdata.get('some_key'):
        # Do something with your data
        wizdata['some_key'] = 'Some other value'

    # And again, simply store the dict in the users session.
    request.session['wizdata'] = wizdata

You can imagine that in the parse_params() and the render_template() method you respectively have the ‘if current_step == ‘ or ‘if step == ‘ statements along the way. All having the wizdata dict available.

This also works in the done() method. Simply get the dict one last time from the user session.

def done(self, request, form_list):
    wizdata = request.session.get('wizdata')

    # Other code here

    # Cleanup
    del request.session['wizdata']

Then, for tidyness, at the end of done() we remove the dict from the user session.

Gotchas

There can be stale data, in the form of our stored dicts, left behind when wizard sessions are not finished by the user. This also is true for the sessions itself. As stated in the The Django docs about sessions you should clean up the sessions from time to time.

Anybody that has improvements, questions or compliments please drop me a line

GrtzG

SELECT id, name FROM myapp_model WHERE owner_id='1' GROUP BY name;

This would have been (easily) possible except for the WHERE clause on ownership that screwed me. Since the SQL statement was that simple I decided to write a bypass function that get’s the data straight from the database. It’s readonly access and I dont do anything more with it then create a list of links. Even more so, from a KISS point of view this code is easier to read back after several months.

And for reusability I turned it in to a function. It takes the model and the distinct field, and for my purpose the needed ownership as parameter:

from django.db import connection

def get_latest_objects(model_name=None, distinct_field=None, user_id=None):
    """ Get lastest distinct selection (as tuples) of a given model
    """
    model_name = model_name.lower()
    query = ("select id,%(distinct_field)s from myapp_%(model_name)s "
                "where owner_id='%(user_id)s' "
                "group by %(distinct_field)s;") % {
                    'model_name': model_name,
                    'distinct_field': distinct_field,
                    'user_id': user_id,
                    }
    cursor = connection.cursor()
    cursor.execute(query)

There’s not much to it, I just hope it helps you to avoid ‘the hard way’. And it helps to keeps your view methods more readable because you dont need anything more then this:

latest_objects = get_latest_objects(model_name='MyModel',
                        distinct_field='name',
                        user_id=request.user.id)

What is returned (latest_objects) is a list of tuples that you can unpack in your templates straight away. Note that there’s no error checking in there, because I know what I’m doing Besides, worst case you get back an empty list and possible errors are caught when you write your tests. You do write those don’t you?

Grtz Gerard.

But since wrongfull data disclosure is absolutely unacceptable I was still afraid that I would miss something somewhere. A nice example I ran into was populating a dropdown list in a form, where all records were visible instead of only those owned by the logged in user.

That got me thinking and eventually I wrote this small but sweet piece of middleware. Further elaboration below the code.

from django.db import connection
import re

"""
QueryScreener is a middleware development tool. This tool helps to avoid
unwanted data disclosure once you go into production.

It monitors queries to the models in your model_list and warns you when queries
are executed that do not contain a ownership where clause. And thus can be a
potential data disclosure hazard.

It requires a owner attribute in your model definition, e.g:

    owner = models.ForeignKey(User, editable=False)

Edit the 'model_list' below for what models should be monitored. And add
QueryScreener to MIDDLEWARE_CLASSES in you settings.py

Note: This can/should only be used while running Django's testserver command
with e.g: ./manage.py runserver 192.168.1.81:8000
"""

class QueryScreener(object):

    model_list = ['myapp_customer', 'myapp_order', 'myapp_product']

    def process_view(self, request, view_func, view_args, view_kwargs):
        if len(connection.queries) > 0:
            query_parse(connection.queries, self.model_list, 'process_view')

    def process_response(self, request, response):
        if len(connection.queries) > 0:
            query_parse(connection.queries, self.model_list, 'process_response')
        return response

def query_parse(self, model_list, caller_process):

    for query in connection.queries:
        for modelname in model_list:
            modelstring = 'FROM `'+modelname

            if re.search(modelstring, query['sql']) and not \
                re.search(r'^SELECT.\(1\).AS', query['sql']):

                reg = re.compile(r'^SELECT.*WHERE.*owner.*(ORDER BY.*)?$',
                                    re.DOTALL)

                if not reg.search(query['sql']):
                    print ('<<< WARNING >>> Query execution without ownership '
                            'clause, called from "' + caller_process + '"')
                    print query['sql']

            if re.search(r'^SELECT.\(1\).AS.`a`.FROM.*WHERE.*$', query['sql']):
                print ('<<< Django Farted >>>')
#                print query['sql']

Update1: The ‘ORDER BY’ in the regex needs to be optional.
Update2: Django does a ‘try update’ in save_base() without owner (seperated the select statement)

The comment in the code above sums up how to get it working. What it does is print a warning and the query in question that does not respect ownership. If enabled while developing just keep track of your console output for:

<<< WARNING >>> Query execution without ownership clause, called from "process_response"

Should you  have suggestion, criticism, or words of admiration then please, do tell me

GrtzG