Droid/Tux/Web

A close friend of mine bought an android phone.However much of her excitement went down the drain when she was unable to connect to the internet using her ad hoc sharing of Ethernet.

if you are in a similar situation and use linux/fedora and wanted to connect to the internet, here is a small way of doing so. If you use windows 7+ however, you can use an application called connectify. :

Step 1.

$sudo yum install hostapd

Step 2.
Configure hostapd with few lines, there are many options feel free to explore

interface=wlan0
hw_mode=g
channel=6
ssid=Yourssidhere

macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
wpa=3
wpa_passphrase=yourssidpasshere
wpa_key_mgmt=WPA-PSK
wpa_pairwise=TKIP
rsn_pairwise=CCMP

Step 3.
Stop the hostapd service if it is running:

$sudo service hostapd stop

or

$sudo systemctl stop hostapd.service

Step 4.
Go to your network manager, wireless and turn on the hotspot.
Step 5.
Restart the hosapd service

$sudo service hostapd start

or

$sudo systemctl start hostapd.service

Done

There is a better way of doing this with bridge-utils, dnsmasq, and hostapd, I will blog about that later.

To the south, sir!

It has been sometime while playing with Django. One problem that I face mostly is making changes in the model and expect the change to reflect itself on the fly. Django, however does not like this idea and does not let you do so. In most case if you are making a model and want to create the DB schema you will do something like this:

python manage.py syncdb

This will create your model, however once created and then if you want to make changes in the schema, you are not going anywhere. So this is where we need to go south.
Django south generally works in this way:

python manage.py schemamigration <appname> --initial

Then you do a

python manage.py migrate <appname>

This is enough to create a migration directory and track changes to your model based in the appname you are using.
So now if you are making changes to the column, you will be using south. The next few lines will deal with screwing thing inside south as well as making you model change successful. One piece of caution though, this will/may delete your existing data, so be careful.
Let say, you end up with an error like this while migrating using south.

! These migrations are in the database but not on disk:
some migrations here
! I’m not trusting myself; either fix this yourself by fiddling
! with the south_migrationhistory table, or pass –delete-ghost-migrations
! to South to have it delete ALL of these records (this may not be good).

This happens because there is conflict in the original model and the model you are trying to implement.

The following steps will help:

Undo changes in the model.py intended to have the change and delete the migration folder in the folder, then run

python manage.py migrate <appname> --delete-ghost-migration

This step will delete all the migrations that has not trickled down properly.
If your app is already managed by south then run the next step, else if your app was previously managed by syncdb only, use this command first:

python manage.py convert_to_south <appname>

Coming back to our steps:


python manage.py schemamigration <appname> --init


python manage.py migrate <appname> --fake

The argument –fake will record the changes but will not write it to the DB.
Now redo the changes in the model.py

python manage.py schemamigration <appname> --auto

The argument –auto will keep track of the changes happening over the initial change/previous changes.

python manage.py migrate <appname>

And that’s it, you are done and your changes has flown to the DB.
Please read south documentation for more details, it can be found here.