MongoDB vs. Postgres; A specific use case
I’ve recently taken a job at Ansible working on the enterprise offering Tower. In case you don’t know, Tower is a front-end for your Ansible playbooks w/ enterprise permission management. I was tasked with evaluating our database needs for a new System Tracking feature that we released. Working remotely at the time forced me to create detailed presentations on my progress and evaluation. I ended up taking the internal presentations and created a blog post about the evaluation process.
http://www.ansible.com/blog/how-we-chose-mongodb-for-ansible-tower-system-tracking-feature
Devstack on EC2 via Ansible
So you want to get an instance of OpenStack running to poke around and see what all the fuss is about without going insane. Welcome to Devstack. Once Devstack is setup you will have access to a web-based control panel with prepopulated data and instances. You will also be able to explore the OpenStack API with v2.0 and v3 authentication (keystone).
devstack webpanel
Setup
git clone https://github.com/chrismeyersfsu/playbook-devstack
cd playbook-devstack/
sudo ansible-galaxy install -r requirements.yml
- Create an ec2 elastic ip address and override the playbook variable
ec2_elastic_ip. - Map a domain/subdomain in route53 (or other dns service) to your elasic ip address. (i.e. devstack.example.com)
- Set your webportal login password by overriding the playbook variable
nova_password
Execution
Be aware that the playbook may take > 20 minutes on an ec2 instance to complete.
ansible-playbook site.yml -i ‘devstack.example.com,’
When finished you should be able to visit http://devstack.example.com and login using demo / nova_password. You should then see the webpanel similar to the image above. The v2.0 and v3 APIs are accessabile via http://devstack.example.com:5000/v2.0/ and http://devstack.example.com:5000/v3/.
Debugging
So things maybe didn’t go according to plan. Here are some playbook invocation variations that you can be used to execute a subset of the tasks.
- Do not provision a new ec2 instance. Only run the devstack install task.
ansible-playbook site.yml -i ‘devstack.testing.ansible.com,` -vvvv –tags “devstack_setup”
- Do not provision a new ec2 instance nor run the devstack install task. Only run the vm instance creation tasks.
ansible-playbook site.yml -i ‘devstack.testing.ansible.com,` -vvvv –tags “devstack_nova”
Beaglebone + Ubuntu
We can install Ubuntu 2-ways.
- To the external SDCARD
- To the internal MMC
Installing to the internal MMC requires an SDCARD to install, but the sdcard is not required after that. The process is mostly the same. The MMC setup vs. the SDCARD setup depends on which image you download.
Installing Ubuntu
MMC: Download the latest file of the form BBB-eMMC-flasher-ubuntu-xx.xx-xxxx-xx-xx.img.xz
SDCARD: Download the latest file of the form ubuntu-12.10-console-armhf-xxxx-xx-xx.tar.xz
Extract the image
sudo apt-get install xz
xz -d *.img.xz
Insert the sdcard into your desktop and note the device path. In my case the device is at /dev/sdc.
[email protected]:~/beaglebone$ dmesg
[ 1659.900631] usb 3-1: USB disconnect, device number 3
[ 2664.433700] usb 3-1: new high-speed USB device number 4 using xhci_hcd
[ 2664.709199] scsi7 : usb-storage 3-1:1.0
[ 2665.706903] scsi 7:0:0:0: Direct-Access Generic- SD/MMC 1.00 PQ: 0 ANSI: 0 CCS
[ 2665.707747] sd 7:0:0:0: Attached scsi generic sg3 type 0
[ 2666.334388] sd 7:0:0:0: [sdc] 15519744 512-byte logical blocks: (7.94 GB/7.40 GiB)
[ 2666.334770] sd 7:0:0:0: [sdc] Write Protect is off
[ 2666.334775] sd 7:0:0:0: [sdc] Mode Sense: 03 00 00 00
[ 2666.335066] sd 7:0:0:0: [sdc] No Caching mode page present
[ 2666.335071] sd 7:0:0:0: [sdc] Assuming drive cache: write through
[ 2666.336660] sd 7:0:0:0: [sdc] No Caching mode page present
[ 2666.336667] sd 7:0:0:0: [sdc] Assuming drive cache: write through
[ 2666.337339] sdc: sdc1 sdc2
[ 2666.338721] sd 7:0:0:0: [sdc] No Caching mode page present
[ 2666.338726] sd 7:0:0:0: [sdc] Assuming drive cache: write through
[ 2666.338730] sd 7:0:0:0: [sdc] Attached SCSI removable disk
[ 2666.821868] EXT4-fs (sdc2): mounted filesystem with ordered data mode. Opts: (null)
Flash the image to the sdcard. Substitute <mmc_or_sdcard>.img and /dev/sdX accordingly.
sudo dd if=<mmc_or_sdcard>.img of=/dev/sdX bs=1M
Upon completion remove the sdcard and perform the following:
- Ensure the beaglebone is off
- If you plan on powering the beaglebone with usb, ensure the ethernet is unplugged.
- Insert the sdcard into the beaglebone
- Hold down the button that is by itself near the SDCARD
- Insert the USB power or barrel jack power
- Once the lights begin blinking blue you may release the button
- Wait =~ 45 minutes until all the lights are blue
Once all the lights turn solid blue the MMC is successfully flashed and you may power down your beaglebone (unplug the power), remove the sdcard. Wait a couple seconds, then plug the power back in and the system will boot Ubuntu.
Verifying Ubuntu Install
Find the ip of your beaglebone on your network.
[email protected]:~$ sudo nmap -sP 192.168.1.*
Starting Nmap 5.21 ( http://nmap.org ) at 2013-06-30 14:13 EDT
Nmap scan report for 192.168.1.1
Host is up (0.00086s latency).
MAC Address: 00:23:69:0E:20:D7 (Cisco-Linksys)
Nmap scan report for 192.168.1.2
Host is up (0.076s latency).
MAC Address: BC:AE:C5:C4:F6:AB (Unknown)
Nmap scan report for 192.168.1.103
Host is up (0.065s latency).
MAC Address: BC:AE:C5:C4:F6:AB (Unknown)
Nmap scan report for 192.168.1.106
Host is up (0.00023s latency).
MAC Address: 3C:07:71:24:21:4B (Unknown)
Nmap scan report for 192.168.1.107
Host is up.
Nmap scan report for 192.168.1.112
Host is up (0.075s latency).
MAC Address: BC:AE:C5:C4:F6:AB (Unknown)
Nmap scan report for 192.168.1.114
Host is up (0.062s latency).
MAC Address: BC:AE:C5:C4:F6:AB (Unknown)
Nmap scan report for 192.168.1.116
Host is up (0.00072s latency).
MAC Address: C8:A0:30:B2:8E:5D (Unknown)
Nmap scan report for 192.168.1.118
Host is up (0.017s latency).
MAC Address: BC:AE:C5:C4:F6:AB (Unknown)
Nmap done: 256 IP addresses (9 hosts up) scanned in 6.18 seconds
ssh to your beaglebone.
ssh [email protected]
[email protected]’s password: temppwd
Raspberry Pi OpenCV Pan & Tilt Face Tracker
Create your own face tracking, pan and tilt camera on the Raspberry Pi!
This tutorial will demonstrate use of the OpenCV (computer vision) library to identify and track faces on the raspberry pi using two servos and a USB webcam. For the interested, I previously covered a more thorough overview of the installation of OpenCV from source here, however, I have found that the apt package is sufficient for all but the most bleeding edge of projects.
This project is based on the OpenCV face tracking example that comes along with the source-based distribution. In short, it performs face detection using haar-like features to analyze the video frame, and locates any faces present within it. In the live video window, identified faces are surrounded with a red rectangle. For additional information about how face detection works as well as the specifics of face detection with OpenCV, I recommend this article by Robin Hewitt.
Using the coordinates of the rectangle vertices, my script calculates the (X,Y) position of the center of the face. If the face is sufficiently on the left side of the screen, the pan servo will progressively rotate leftward, on the right side, rightward. This is likewise performed for the tilt servo as well, if the face is in the upper portion of the screen, it will pan upward, in the lower portion, pan downward. If the face is detected reasonably within the center of the image, no action is performed by the servos. This prevents unnecessary jitter once the camera has locked itself on the face.
Hardware
Parts needed:
- 512 MB raspberry pi
- 2x Hobby servos (Turnigy 9g fom Hobby King)
- Pan & tilt bracket (from Foxtech FPV)
- USB webcam (Microsoft LifeCam Show from Amazon)
- Power supply
- Hook-up wire
- Raspberry Pi enclosure (from Built to Spec)
Assembly
Connect the red, power lines of the servos to +5v, the black ground lines to GND, and the yellow signal lines to the desired output pins, GPIO pins 22 and 23 in the example. Here is a diagram of the completed circuit (created with Fritzing):
And here is how it looks all put together:
Software
Get the source.
The first step of this procedure is to install the required libraries and packages using the Raspberry Pi package manager. Open up terminal shell and run:
sudo apt-get update && sudo apt-get install git python-opencv python-all-dev libopencv-dev
This command will pull down all of the required packages (about 215 MB worth) including the git version control system, as well as the OpenCV development headers and Python bindings. The next step is to configure the Raspberry Pi for use with multiple pulse width modulation (PWM) outputs. Normally, the Raspberry Pi has only one channel of PWM output. However, thanks to the efforts of Richard Hirst, eight channels of PWM can be used through the use of this servoblaster kernel driver.The driver creates a device file, /dev/servoblaster to which commands can be sent to control the servos. The commands take the form “=” with servo number representing the desired servo (0-7 in this case) and servo position representing the pulse width in units of 10 µs. For example, to send servo 3 a pulse width of 120 µs: echo 3=120 > /dev/servoblaster To configure the servoblaster on the Raspberry Pi, first pull down the sources from Richard’s Github repo:
git clone https://github.com/richardghirst/PiBits.git
Then change into the servo blaster directory, and install the module:
cd PiBits/ServoBlaster
make install_autostart
This command also sets up the necessary udev rules for accessing the /dev/servoblaster device. Note: using the ’install_autostart ’ command will set up a Raspberry Pi to load the servoblaster kernel module on every boot. If you don’t want this behavior, execute ‘make install’ instead. In either case, the module will not yet be loaded so go ahead and load it into the kernel using modprobe:
sudo modprobe servoblaster
Now that all the prerequisites have been installed and the servo blaster device configured, it’s time to get the actual face tracking and servo moving code. Clone my repo from Github here:
git clone https://github.com/mitchtech/py_servo_facetracker
Now change directory into the created folder, and run the script like this:
cd py_servo_facetracker
python ./facetracker_servo_gpio.py 0
If you have a different servo bracket configuration, the pan and tilt axis may need to be inverted. To do so, invert the sign on the values of panStepSize and tiltStepSize. Similarly, increasing or decreasing these values will change the sensitivity of the movement, larger numbers corresponding to more degrees moved per face detection frame.
Raspberry Pi Google Talk Robot
Google Talk/Chat/Messenger is normally used by humans to interact with other humans. However, its underlying technology can also be used as a mechanism to implement software robots. Internet bots, also known as web robots, WWW robots or simply ‘bots’ can also utilize the technology to perform automated functions over the web. There are many such bots in existence, offering a diverse spectrum of services from jokes ([email protected]) to URL Shortening using bit.ly ([email protected]), even mathematical calculation ([email protected]). Using such bots is quick and easy to configure, all that must be done is to add the bot as a contact to your messaging account. Then, whenever you desire data from the service, simply text the command to the bot and it will respond with the respective message.
The Raspi Bot is essentially the same as any other automated Internet robot. To configure it, it must first have its own e-mail address associated with a Google talk account. This e-mail address must also be added as a contact with the account that wishes to communicate to the bot. Then, whenever the script is running on the remote machine, it will log into Google chat and appear as a friend in your contact list.
The software itself is essentially just a Python daemon script that is a wrapper around the XMPP protocol. When executed, the script will sign in to Google talk using its own username and password. The Python script is derived from the open source project pygtalkrobot: An open source python gtalk(google talk) bot framework using XMPPPY and PyDNS libraries, that also references the source code of python-jabberbot.
Software
The Raspi Bot requires several additional Python modules for use. The easiest way to install these is with the python pip package manager. If you don’t have it installed, you can install them using apt-get:
sudo apt-get install python-pip git-core python2.7-dev
Then update the easy_install index:
sudo easy_install -U distribute
And install the GPIO, xmpppy, and pydns modules:
sudo pip install RPi.GPIO xmpppy pydns
Then clone my repo for the Raspi Gtalk robot:
git clone https://github.com/mitchtech/raspi_gtalk_robot.git
Now change into the newly created directory:
cd raspi_gtalk_robot
Finally, you will need to configure the Raspi Bot’s Gtalk username and password. This is done by editing the fields BOT_GTALK_USER, BOT_GTALK_PASS, and BOT_ADMIN, on lines 31-33 in the raspiBot.py file. It is recommended, though not required, to give the Raspi Bot its own Gmail account. Since access to the Raspberry Pi GPIO pins is restricted, the script needs to be run with sudo:
sudo python ./raspiBot.py
This basic sample script supports the following commands:
- [pinon|pon|on|high] [pin] : turns on the specified GPIO pin
- [pinoff|poff|off|low] [pin] : turns off the specified GPIO pin
- [write|w] [pin] [state] : writes specified state to the specified GPIO pin
- [read|r] [pin]: reads the value of the specified GPIO pin
- [available|online|busy|dnd|away|idle|out|xa] [arg1] : set gtalk state and status message to specified argument
- [shell|bash] [arg1] : executes the specified shell command argument after ‘shell’ or ‘bash’
For example, sending the message “pinon 10” will turn on GPIO pin #10, “read 8” will read the current state of GPIO pin 8, or “bash ps” to execute the shell command ‘ps’.
Hardware
The video demonstration uses a slide switch connected to GPIO pin 8 and an LED connected to GPIO pin 10. Here is a diagram of how this is wired (created with Fritzing):
Use case #1: Home automation
One of the most obvious usages of this technology is for home automation purposes. The Raspi Bot can be accessed anywhere with Google talk, which to my understanding, is nearly every system in existence. Send the Raspi Bot messages to turn on and off lights and other electrical appliances.
This is also useful to provide immediate notification in the event of intrusion detection. The Raspi Bot can be supplemented with additional security sensors, including infrared motion, and ultrasonic distance sensors. If any pre-programmed sensor violates any predefined condition, you can be immediately notified via message from the Raspi Bot.
Use case #2: Remote shell
The Raspi Bot can be used essentially as a remote shell. In this configuration, every message sent to the Raspi Bot will be interpreted as a shell command with the output piped back to the user in the form of a response message. Obviously, this could raise some security concerns. To protect against misuse, the Raspi Bot will only respond to Google chat messages from the Google user designated as the administrator of the bot. By default, messages from any other user will simply be ignored.
The following is a small subset of the relatively benign commands possible to be run remotely via the Raspi Bot:
- vmstat – system activity, hardware and information
- uptime – how long the system has been running
- w – logged in users and their process activity
- ps – reports a snapshot of the current processes
- free – physical and swap memory usage
- iostat – average CPU load, disk activity
Arguably, disclosure of any amount of information about system can be considered a security issue such as that reported by some of the above tools. For users more concerned about convenience over security exposure, much more elaborate commands can be run, such as executing additional scripts or accessing private data.
Use case #3: Remote Reboot
Another problem that can be solved by the Raspi Bot is frozen remote machines. We’ve all been there before, attempting to access a remote machine only to find it to be completely non-responsive to any form of remote login. These cases, we (or maybe a system administrator somewhere) would usually have to make a trip to the physical location of the server and push ‘the big red button’ to reboot the affected machine. The situation can be eliminated completely by deputizing a Raspi Bot as a remote reboot agent. This can be done by adding bot controlled relay(s) to the power supplies of the machines. In the event any of the machines controlled by the Raspi Bot becomes non-responsive, simply send the appropriate Google talk message to flip the respective relay, and reboot the affected machine. Here’s a diagram of how this would look:
Raspberry Pi + PWM RGB LED Strip
This tutorial demonstrates how to easily use a Raspberry Pi to drive 12V RGB LED strips using Pulse Width Modulation (PWM). Out of the box, the Raspberry Pi has only one GPIO pin that is capable of pulse width modulation (PWM). However, thanks to the efforts of Richard Hirst and his servoblaster kernel module, standard GPIO pins can be used to perform PWM.
Note: The flashing of the LED strip due to PWM is only noticeable in the uploaded video; in reality, the colors progress smoothly without any visible flashing.
Hardware
Parts needed:
- Raspberry Pi
- 3 x TIP120 power transistors
- RGB LED strip
- Perfboard/Breadboard
- Hook-up wire
Assembly
Connect a 12V power supply to the 12V pad on the RGB LED strip, connect the base of each TIP120 power transistor to its respective GPIO pin (pins 18, 23, and 24 in this example), connect the collector of each to its matching pad on the LED strip, and finally, connect the emitters to common ground for both the Raspberry Pi and the 12V power supply. Here is a diagram of the circuit (created with Fritzing):
Software
Configure servoblaster.
The next step is to configure the servoblaster kernel driver. The driver creates a device file, /dev/servoblaster to which commands can be sent to control the servos. The commands take the form “=” with servo number representing the desired servo (0-7 in this case) and servo position representing the pulse width in units of 10 µs. For example, to send servo 3 a pulse width of 120 µs:
echo 3=120 > /dev/servoblaster
To setup the servo blaster on the Raspberry Pi, we will need to have git installed to pull down the sources. If you don’t have it installed already, open a terminal and run:
sudo apt-get install git-core
Then pull down the sources from Richard’s Github repo:
git clone https://github.com/richardghirst/PiBits.git
Now change into the servo blaster directory:
cd PiBits/ServoBlaster
And compile and install the module:
make install_autostart
This command also sets up the necessary udev rules for accessing the /dev/servoblaster device. Note: using the ’install_autostart ’ command will set up a raspberry pi to load the servo blaster kernel module on every boot. If you don’t want this behavior, execute ‘make install’ instead. In either case, the module will not yet be loaded so go ahead and install it using modprobe:
sudo modprobe servoblaster
Sample code usage.
Now that all the prerequisites have been installed and the servo blaster device configured, on to the actual sample code. The python sample script uses PWM to fade from blue to violet, to red, to yellow, to green, to teal, back to blue.
NEW