« Posts by admin

Gravity drip irrigation

I’ve been setting up a system of cheap drip irrigation for a remote location. Here are the facts and criteria

  1. Remote, no electricity, off-grid
  2. Water from well, well pump run only by generator
  3. Multiple trees
  4. Drip time before refilling (about one per week)
  5. Hot summer (80-100F), wet mild winter
  6. Windy site, full sun, no shade

Here is the setup so far:

  1. 1/4 tubing
  2. 1/4 tubing w/ 1/2GPH emitters at 6″/12″ spacing
  3. 1/4 fittings (tee, connector)
  4. 1/2 tubing
  5. 1/2 fittings (tee, connector, cap)
  6. mini sprinklers
  7. 1/2 GPH PC/non-PC emitters
  8. Trash cans (32G), many, cheap at OSH $10/each, this acts as the rain barrel, container
  9. 8x8x16 Concrete blocks ($1.48=>$1.54 at HomeDepot)

Basic steps for a single emitter

  1. Drill trash can to connect out to 1/4 pipe with valve
  2. Connect 1/4 tubing with 1/2GPH emitter at the end
  3. Place water container on top of concrete blocks to create pressure
  4. Place emitter at base of tree

Other setups:

  1. Single tree, single barrel
  2. Single barrel, several emitters

Problems encounters:

  1. Run out of water from a single trash can too quickly
  2. Time to manually water and refill containers

Google Drive, XAMPP, MacBook

  1. Rename “Google Drive” to one without space. Example: GoogleDrive to avoid issues
  2. Move app to that folder: /Users/xxx/GoogleDrive/htdocs/MyApp
  3. Edit XAMPP etc/httpd/extra/httpd-vhost.conf:
    <VirtualHost *:80>
    DocumentRoot “/Applications/XAMPP/xamppfiles/htdocs”
    ServerName localhost
    </VirtualHost>

    <VirtualHost *:80>
    DocumentRoot “/Users/xxx/GoogleDrive/htdocs/MyApp1/webroot”
    ServerName dev.app1
    </VirtualHost>

    <VirtualHost *:80>
    DocumentRoot “/Users/xxx/GoogleDrive/htdocs/MyApp2/webroot”
    ServerName dev.app2
    </VirtualHost>

  4.  Map custom domain to localhost in /etc/hosts:
    127.0.0.1 dev.app1
    127.0.0.1 dev.app2

TL-WR1043ND, DD-WRT and NetGear WNDR3700

Setup 1043ND (DD-WRT flashed) as wireless repeater for WNDR3700 (stock firmware). First set it up as Client Bridge, make sure it works. One major gotcha is DHCP, did not flow through initially so I thought it wasn’t working when a static assignment showed it was bridged properly. Then add the virtual interface as AP to access it wirelessly. Still testing, some links:

http://www.dd-wrt.com/wiki/index.php/Client_Bridged
http://www.dd-wrt.com/phpBB2/viewtopic.php?p=630485
http://blog.jeffcosta.com/2011/09/29/create-a-wireless-n-bridge-with-2-inexpensive-tp-link-routers/
http://www.dd-wrt.com/site/support/router-database

Retina Macbook Pro – First impressions

Got mine 2 days ago. Here is what I like:

  • Fast! Open apps almost instantly thanks to SSDs
  • Retina is very sharp, almost too sharp and many apps or logos turn blurry because of the high resolution. Viewing photos from D800 is fantastic, very sharp and the colors are extremely vivid. Love it!
  • Illuminated keyboard, very nice when the environment is a little bit dark or you don’t have enough ambient light
  • Lighter than my old unibody MacBook 13″ (no optical)
  • Mail 6 is definitely better than older Mail on my old MB, very easy to setup and threaded like Gmail.

Cons:

  • Upgradability is low. I knew this so started with a better CPU and more RAM (16G). Hopefully it lasts me a bit longer. I think Apple understands this so upgrade pricing is decent and not too expensive.
  • No optical drive, I do need files from DVD from time to time. I guess I cannot have everything. It’s an okay removal and I still have other options for this.
  • Firefox is still blurry. This is a problem with Firefox, not Apple, so I’m switching to Chrome. Other older apps have blurry text (eg: KeepassX)

Overall, it’s a great machine and I think Apple is doing a great job going for the ridiculous Retina resolution. Other vendors will have to get there, just a matter of time. They’re in a great position: they control the price and they control the market share. What else do you ask for. And they keep going for the edge. Too bad I don’t have any AAPL ūüôā

Nice replication setup

If you have a chain replication: A=>B=>C. If B is out of sync for some reason, C will be out of sync and you need to rebuild. The nice thing is that when B is rebuilt, it automatically rebuilds all its slaves (C1, C2, C3, etc.) because B&C are still in replication, the DROP IF EXISTS and those INSERTs will run as normal, which is very nice because you can have a few secondary head slaves (B1, B2, B3) and then hundreds/thousands of real slave (C1,C2,C3,C4,C5). They will cascade data down the chain when you only have to rebuild the secondary masters.

Ideas

Vision: an app that can identify what’s in a photo. Examples: use your mobile phone to capture an unknown flower and it tells you what kind of flower. Applications: plant, insect, bird, fish identification. If it does not know, it uses crowd-sourcing for identification (forums/community input). Anyone knows of such an app?

Vision: virtual organizer of real things. You put your physical items into virtual bins and the software will automatically identify, categorize. You can search, find the items. Think “computer file folders” but with real items (golf clubs, Christmas ornaments, garden seeds, paperworks, etc.) Anyone knows if anything like this exists?

Vision: plug a USB into your head to read a book. Lose the fun of reading, gain the speed of obtaining information

Autossh init.d script

In this init.d script for autossh in CentOS, I use puppet to replace the param “pAutoSSHParams”, which could be something like this:

“-M 0 -f -N -L 3307:127.0.0.1:3306 -p 22 user@host”

File: /etc/init.d/autossh

Run: service autossh start/stop

#!/bin/sh
#
# autossh – Startup script for autossh

# chkconfig: 2345 20 80
# description: Maintain a persistent SSH tunneling
# processname: autossh
# pidfile: /var/run/autossh.pid

# @since 2011-12-11 08:18:47
# @author Son Nguyen
# Managed by Puppet so do not modify manually

# Source function library
. /etc/rc.d/init.d/functions

prog=”autossh”
autossh=”/usr/bin/autossh”
RETVAL=0

start() {
echo -n $”Starting $prog: ”
# http://www.jbmurphy.com/2011/04/29/autossh-on-centos/
AUTOSSH_PIDFILE=/var/run/autossh.pid
if [ ! -e $AUTOSSH_PIDFILE ]; then
AUTOSSH_PIDFILE=$AUTOSSH_PIDFILE;export AUTOSSH_PIDFILE
daemon $autossh <%= pAutoSSHParams %>
RETVAL=$?
else
RETVAL=1
echo_failure
fi
echo
[ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog
return $RETVAL
}

stop() {
echo -n $”Stopping $prog: ”
killproc $autossh
RETVAL=$?
echo
[ $RETVAL -eq 0 ] && rm -f /var/lock/subsys/$prog
return $RETVAL
}

case “$1″ in
start)
start
;;
stop)
stop
;;
restart)
stop
start
;;
status)
status $autossh
RETVAL=$?
;;
*)
echo $”Usage: $0 {start|stop|restart|status}”
RETVAL=1
esac

exit $RETVAL

SSH Tunneling with restricted/limited shell

If you want to connect to rsync/mysql or other service via localhost through SSH tunneling, you need the tunnel to stay open. There are rssh and other limited shells. But you can write your own. In this case, it opens for 10 seconds then closes. It does not close if there are activities (rsync takes longer than 10s) from my experience. It does nothing so there is no security to worry about.

1) Create sleepshell.c

main() {sleep (10);}

2) gcc sleepshell.c -o /usr/local/bin/sleepshell

3) useradd -m -d /home/tunneluser -s /usr/local/bin/sleepshell tunneluser

or usermod -s /usr/local/bin/sleepshell tunneluser

And that is it.

ssh -f -L 873:localhost:873 tunneluser@server “ANYTHING”

rsync –delete –delete-excluded –progress -zrltvp module@localhost dest

Steadfast Cloud

These are some benchmarks run with UnixBench 5.1.3 on Steadfast Cloud powered by OnApp. The ability for scaling up/down RAM and CPU without reboot is neat and very useful. Disk resizing need reboot but this can be avoided by the app. The OnApp API is very simple and easy to use as well. I tried RackSpace and it needs reboot. EC2 is similar to RackSpace cloud too. Basically, migration to a new instance (bigger/smaller) and point to the same mount/virtual disk. OnApp added memory and CPU in real-time and I can see it reflect via “top”. Very cool indeed. I see this as the future (auto-scaling up/down, in/out, vertical/horizontal seamlessly) and truely present the power of cloud computing

Physical: 2x4xHT (16 cores) Xeon E5620 2.4Ghz

Config – 512MB RAM, 10% of 1 core and also 1% of 1 core (look like it’s burst-able)

Benchmark Run: Wed Dec 07 2011 20:46:04 – 21:14:18
1 CPU in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       14152617.2 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2851.9 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1588.2 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        215988.3 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           56996.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        651739.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                              290994.0 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  83294.7 lps   (10.0 s, 7 samples)
Process Creation                               3397.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   2741.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    381.3 lpm   (60.0 s, 2 samples)
System Call Overhead                         251441.4 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   14152617.2   1212.7
Double-Precision Whetstone                       55.0       2851.9    518.5
Execl Throughput                                 43.0       1588.2    369.4
File Copy 1024 bufsize 2000 maxblocks          3960.0     215988.3    545.4
File Copy 256 bufsize 500 maxblocks            1655.0      56996.5    344.4
File Copy 4096 bufsize 8000 maxblocks          5800.0     651739.5   1123.7
Pipe Throughput                               12440.0     290994.0    233.9
Pipe-based Context Switching                   4000.0      83294.7    208.2
Process Creation                                126.0       3397.9    269.7
Shell Scripts (1 concurrent)                     42.4       2741.2    646.5
Shell Scripts (8 concurrent)                      6.0        381.3    635.5
System Call Overhead                          15000.0     251441.4    167.6
========
System Benchmarks Index Score                                         433.8

Config – 512M RAM, 1% of 10 core

Benchmark Run: Wed Dec 07 2011 22:05:17 – 22:33:32
10 CPUs in system; running 1 parallel copy of tests

Dhrystone 2 using register variables       13349714.7 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     2824.6 MWIPS (9.9 s, 7 samples)
Execl Throughput                               1241.2 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        213946.6 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           56376.5 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        660924.3 KBps  (30.0 s, 2 samples)
Pipe Throughput                              301494.5 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                  80504.0 lps   (10.0 s, 7 samples)
Process Creation                               3496.9 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3429.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   1309.2 lpm   (60.0 s, 2 samples)
System Call Overhead                         261392.6 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   13349714.7   1143.9
Double-Precision Whetstone                       55.0       2824.6    513.6
Execl Throughput                                 43.0       1241.2    288.7
File Copy 1024 bufsize 2000 maxblocks          3960.0     213946.6    540.3
File Copy 256 bufsize 500 maxblocks            1655.0      56376.5    340.6
File Copy 4096 bufsize 8000 maxblocks          5800.0     660924.3   1139.5
Pipe Throughput                               12440.0     301494.5    242.4
Pipe-based Context Switching                   4000.0      80504.0    201.3
Process Creation                                126.0       3496.9    277.5
Shell Scripts (1 concurrent)                     42.4       3429.2    808.8
Shell Scripts (8 concurrent)                      6.0       1309.2   2182.0
System Call Overhead                          15000.0     261392.6    174.3
========
System Benchmarks Index Score                                         479.6

————————————————————————
Benchmark Run: Wed Dec 07 2011 22:33:32 – 23:02:22
10 CPUs in system; running 10 parallel copies of tests

Dhrystone 2 using register variables       88693187.8 lps   (10.1 s, 7 samples)
Double-Precision Whetstone                    24944.7 MWIPS (9.8 s, 7 samples)
Execl Throughput                               8738.4 lps   (29.8 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        138675.4 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           36445.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        485151.9 KBps  (30.0 s, 2 samples)
Pipe Throughput                             2266234.2 lps   (10.1 s, 7 samples)
Pipe-based Context Switching                 618203.4 lps   (10.1 s, 7 samples)
Process Creation                              20493.0 lps   (30.1 s, 2 samples)
Shell Scripts (1 concurrent)                  15570.8 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   2282.2 lpm   (60.2 s, 2 samples)
System Call Overhead                        1834019.4 lps   (10.1 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   88693187.8   7600.1
Double-Precision Whetstone                       55.0      24944.7   4535.4
Execl Throughput                                 43.0       8738.4   2032.2
File Copy 1024 bufsize 2000 maxblocks          3960.0     138675.4    350.2
File Copy 256 bufsize 500 maxblocks            1655.0      36445.3    220.2
File Copy 4096 bufsize 8000 maxblocks          5800.0     485151.9    836.5
Pipe Throughput                               12440.0    2266234.2   1821.7
Pipe-based Context Switching                   4000.0     618203.4   1545.5
Process Creation                                126.0      20493.0   1626.4
Shell Scripts (1 concurrent)                     42.4      15570.8   3672.3
Shell Scripts (8 concurrent)                      6.0       2282.2   3803.6
System Call Overhead                          15000.0    1834019.4   1222.7
========
System Benchmarks Index Score                                        1630.6

 

Some autobench results:

1% of 1 cores => ab @ 450 reqs/sec
1% of 2 cores => ab @ 940 reqs/sec
1% of 10 cores => ab @ 1060 reqs/sec
2% of 5 cores => ab @ 1005 reqs/sec
5% of 2 cores => ab @ 990 reqs/sec

RackSpace cloud resizing (Scaling) steps

Step 1: Resize request is queued
The resize request will be processed as resources permit. The queued period is usually quick, but can vary depending on other host machine activities.
Step 2: Initial preparation of new server
This is the longest part of the upgrade, during this step the original server remains up and running.
Step 3: Current server is shut down and migrated
You will experience a downtime varying in proportion to fullness of the filesystem.
Step 4: Verification of new server
Your newly resized server should now be available. Login to verify that the server is intact and functioning as expected. After verification, the old server will be purged from the system and your account will be billed a prorated amount. If no verification is made, the resize will be automatically verified after a period of 12 hours.