One Unified Global Perspective
Communications with a Global Perspective
Home
Intro
Contact Us
Voice over IP
PBX Solutions
Services
Support
Glossary
Open Source
Blog
Forum

WebMail





2013 Aug 23 - Fri

Blog Migration

Text file blogging, such as what blogs based upon Blosxom are, can become resource hogs after a number of blog entries of accumulted. Over 500 entries in the case of this blog. So it is time to migrate to a database based blog.

I first had my eye on Movable Type, it is Perl based, and used to support both MySQL and PostgreSQL. But the company is deprecating POstgreSQL, which is my preferred database solution of the two.

A bit more searching resulted in coming across serendipity, a PHP based blogging tool which stores its data in PostgreSQL.

With that up and running now, I've ported my entriese over to the my new blog at: Raymond Burkholder - Things I Do. There is still some house keeping to do regarding categories and linked files, but from now on, it is there where the new content will be created.

Thank you for coming by and I hope to hear from you at the new location, which is now possible, as the new blogging software has commenting capability!


2013 Aug 17 - Sat

Migrating From Google Reader to Tiny Tiny RSS

RSS feeds have been and still are my primary ways of reviewing current events. I made significant use of Google's RSS Reader, that is, I was subscribed to quite a few feeds through their service. Then Google decided to tear down the service. At least they gave warning and provided a means of getting at the raw data. I was able download my configuration files, which included feed names, categories, as well as starred items.

I read quite a few blog entries relating to replacement services. Most of the suggestions didn't provide the warm and fuzzies relating to functionality, availability, and interface. A few did refer to Tiny Tiny RSS as having the ability for me to self-serve my own feed. And it stores its information in PostgreSQL. Cool.

Installing was straight-forward on a Debian platform:

  • apt-get install php5-pgsql
  • apt-get install php5-cur
  • su - postgres
    • create user tt login password 'some password';
    • create database tt with owner = tt;
  • add to /etc/postgresql/9.1/main/pg_hba.conf: local tt tt md5
  • /etc/init.d/postgresql reload
  • cd /var/www
  • wget https://github.com/gothfox/Tiny-Tiny-RSS/archive/1.9.tar.gz
  • tar -zxvf Tiny-Tiny-RSS/archive/1.9.tar.gz
  • rm 1.9.tar.gz
  • mv Tiny-Tiny-RSS ttrss
  • start the browser and finish the configuration.

The OPML file can be imported via a preferences menu.

For starred items, there is a Google Reader Import plugin which can be enabled. One enabled, a plugins menu is enabled, and starred items are easily imported.


2013 Aug 15 - Thu

Bermuda Based Band - Sonique Sanctuary - Releases New Song: Anomaly

Last month, Bermuda rock band Sonique Sanctuary played at Chewstick. As part of their set, they played an original song called Anomaly. Here is a video of them playing.


2013 Aug 12 - Mon

Linux Containers (LXC) on Debian Wheezy 7.1 With OpenVSwitch

Now that the networking side of things are complete with Quagga and OpenVSwitch, I can start working further up the technology layers. The next step is to work on virtualization technologies and their management. The focus of this article is to get Linux Containers (LXC) working within a Debian Wheezy 7.1 environment.

Before getting into the installation steps of lxc, some background first. LXC is not a full virtualization solution with an independent kernal and bios, such as provided by Qemu/Kvm. Instead, it runs in a namespace of the host's kernel. As such, it has very fast startup characteristics. The draw backs are several: a) it doesn't offer the tighter security that something like OpenVZ offers (another container flavour), b) it is a more recent container solution and has much catching up to do, and c) and one of things it needs to catch up with is live migration of sessions from one host to another.

János Pásztor goes into some of the differences between LXC and OpenVZ. The disadvantage of OpenVZ is that it has not been welecomed in to recent versions of the Linux Kernel. It appears as though the game plan is the passing of the baton from OpenVZ to LXC.

From an LXC perspective, its usefulness is good when using it in environments where the administrator has control over its integration. It is not a viable candidate when trying to set hosting solutions for third parties. Tighter security for those scenarios can be supplied with a Qemu/Kvm style solution. Some additional reservations regarding OpenVZ and LXC.

The basics of installation for LXC are straight-forward:

aptitude install lxc libvirt-bin

The first package deals with lxc directly. If I wasn't using OpenVSWitch, lxc would be all that I require. But in order to use OpenVSwitch for the networking side of things, I need assistance from the libvirt system. As a side effect of the libvirt install, the Qemu/Kvm compontents get installed at the same time. However, since I'm focussing on lxc at the moment, Qemu/Kvm will be discussed in a different entry.

A manual entry into /etc/fstab is required followed by a reboot to resolve a "resource busy problem" as well as taking care of the mount:

cgroup  /sys/fs/cgroup  cgroup  defaults  0   0

There is some explanation for control groups (cgroup) at Control Groups Resource Management.

Before performing the reboot, one other adjustment is required. The following needs to replace the 'GRUB_CMDLINE_LINUX=""' in /etc/default/grub:

GRUB_CMDLINE_LINUX="cgroup_enable=memory"

Then run the command 'update-grub'. Then perform the reboot. This is from the Debian Wiki on LXC.

After which, running 'lxc-checkconfig' should result in 'yes' for all items.

We can now move on to creating an lxc container. But even this isn't completely straightforward. Wheezy was released unstable in this regard, no functioning lxc template. Instead, based upon Horrors using Debian Wheezy, we need to obtain the template from elsewhere. LXC template lxc-debian-wheezy-template talks about the template.

The template uses debootstrap as part of the build process. The supplied script can be easily modified to install additional packages, or to choose different install configurations.

wget http://freedomboxblog.nl/wp-content/uploads/lxc-debian-wheezy.gz
gzip -d lxc-debian-wheezy.gz
mv lxc-debian-wheezy /usr/share/lxc/templates
chmod +x /usr/share/lxc/templates/lxc-debian-wheezy

Because I am doing this on an amd64 flavour, some lines in /usr/share/lxc/templates/lxc-debian-wheezy needs to be modified:

rootfs=$1/rootfs-amd64
# the following are commented out, not proper
#1:2345:respawn:/sbin/getty 38400 console
#c1:12345:respawn:/sbin/getty 38400 tty1 linux
#c2:12345:respawn:/sbin/getty 38400 tty2 linux
#c3:12345:respawn:/sbin/getty 38400 tty3 linux
#c4:12345:respawn:/sbin/getty 38400 tty4 linux
# instead use these:
1:2345:respawn:/sbin/getty 38400 tty1
2:23:respawn:/sbin/getty 38400 tty2
3:23:respawn:/sbin/getty 38400 tty3
4:23:respawn:/sbin/getty 38400 tty4
5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

The lxc container can now be created:

lxc-create -n debianbase -t debian-wheezy

I am using btrfs as my file system for holding these containers. One interesting feature of the integration between btrfs and lxc is that the lxc-create command will automatically create a btrfs sub-volume for the new container. These allows the use of snapshots for each container. Therefore, the one caveat of which to be aware is that when removing a container, the btrfs subvolume delete command is required. For example, 'rmdir -rf /var/lib/lxc/debianbase' will complain that rootfs is on another device. The command 'btrfs subvolume delete /var/lib/lxc/debianbase/rootfs' will need to be run to remove the subvolme before the remaining elements can be removed with the rm command.

In any case, the creation process will take a few moments to transfer, extract, and configure.

Now that the container has been created, there will be a config file located in /var/lib/lxc/debianbase. This file is used by the lxc-start commands. But since we are using OpenVSwitch, errors will occur when trying to start with the lxc-start commands. Instead, we will ignore this file and use libvirt/virtsh to start the container. However, some additional configuration is first required. An .xml configuration file is required to define the lxc container to be run.

There are a couple of examples located within the libvirt LXC container driver documentation. There is another sample described as libvirt LXC container w/ bridged networking (and 2GB RAM).

The key point is that libvirt will only work with OpenVSwitch in bridged mode. How to Use Open vSwitch with Libvir discusses this a bit. Be sure to have the bridge device configured in OpenVSWitch with:

ovs-vsctl add-br br0

The key line in the libvirt file is to have '<virtualport type='openvswitch'/>' in place. I placed my debianbase.xml file in the /var/lib/lxc directory, to keep everything together. LibVirt Network XML format goes into the fine points of the configuration.

One other consideration is that I am running the amd64 64 bit version. The lxc-create command changed the root partition to be /var/lib/lxc/debianbase/rootfs/rootfs-amd64 instead of /var/lib/lxc/debianbase/rootfs.

libvirt will take care of the interface creation and integration between OpenVSwitch and the lxc container. But a configuration change will be required in the container to obtain an appropriate ip address. To use dhcp for addressing, a default dhcp stanza has been added for eth0. If a static ip address is to be assigned instead, use the normal addressing stanzas associated with that file.

Also, so you don't confuse yourself, set a different hostname in the file at: /var/lib/lxc/debianbase/rootfs/rootfs-amd64/etc/hostname.

LibVirt, the server, also needs to be told about OpenVSwitch. I copied a template from elsewhere in libvirt to use:

cp -p /etc/libvirt/qemu/networks/default.xml /etc/libvirt/lxc/network.xml

Here is an example network.xml file.

The network has to be started in libvirt:

virsh
  connect lxc:///
  net-define /etc/libvirt/lxc/network.xml
  net-start host-bridge
  net-autostart host-bridge

The container can now be started with libvirt:

virsh
  connect lxc:///
  define /var/lib/lxc/debianbase/debianbase.xml
  start debianbase
  console debianbase

For some reason, which has been noted by a number of authors, is that ssh is not configured properly, probably becuase the keys need to be regenerated, which the default debootstrap doesn't deal with. So, the ssh server has to be re-installed. From the console, a few house-keeping adjustments. The locale and ssh reinstall could be performed from a chroot environment:

cd /var/lib/lxc
chroot debianbase/rootfs/rootfs-amd64/
pwd
....
exit
export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
# fix some perl locale issues:
echo "en_US.UTF-8 UTF-8" > /etc/locale.gen
apt-get -y --force-yes install locales
dpkg-reconfigure locales
apt-get install --reinstall openssh-server
# add some additional tools
apt-get --no-install-recommends install -y adduser apt-utils iputils-ping rsyslog logrotate
apt-get install --no-install-recommends openssh-blacklist openssh-blacklist-extra
apt-get install wget less lsof screen nano inetutils-ping psmisc sockstat
#apt-get install man
apt-get clean
apt-get autoremove

The perl locale issues are identified and remedied with Creating a LXC virtual machine template (from scratch).

LXC HOWTO has some interesting ideas regarding LXC containter initialization.

The ssh reinstall was mentioned at Setting up LXC containers in 30 minutes (Debian Wheezy).

Coruscating Lucubrations talks about Incremental backups with btrfs

Margaret Bierman talks about How I Use the Advanced Capabilities of Btrfs.

Dobrica Pavlinusic's Weblog / Blog has an entry discussing the use of private mac addresses:

You will notice that I'm using prefix AC:DE:48 prefix for my mac addresses, which, to best of my knowledge range for private use and used all over IEEE docs (something like private IP range, but for mac addresses). I also have habit of naming interfaces with last octet of IP adress for internal ones, and last two for external one and same notation for mac addresses. Our brain is good at spotting patterns, and if you can read hex this seems just natural...

A ctrl-d or the command exit will exit and close the container. To disconnect from the container, instead use 'ctrl-a q', or if using screen, use 'ctrl-a a q'. 'ctrl-a ctrl-a' can be used to perform a regular 'ctrl-a' in the session (ie, move to beginning of a line). These commands apparently won't work in foreground mode, only in background mode.

Once in the container, and an ip address has been obtained, apt-get install iputils-ping can be used to get the ping utility installed.

On a moderately related note, I was wondering how to get by without doing the virsh .xml file first. The last part of Libvirt 1.0.5 with Openvswitch 1.11.90 provides the clue. Use the command virt-install like:

 # virt-install --connect qemu:///system --name DSL2 --ram 1024 --vcpus 1 \
      --disk path=/tmp/dsl2,size=1,bus=virtio,cache=none \
      --network=ovs-br0 \    <======= THIS LINE IS CHANGED.
      --vnc --os-type=linux --cdrom /dev/sr0

In a follow on article, I have to deal with one level of added complexity, working with vlans with libvirt. The question was brought up with [ovs-discuss] tag vlan communication inter LXC. The solution supposedly exists at Open vSwitch Frequently Asked Questions.

However, according to LibVirt Network XML format, libvirt handles VLAN oriented configurations starting with libvirt version 0.10.0. Debian Wheezy uses version 0.9.12. The solution to this is supplied via remarks at using VLANs with Open vSwitch Fake Bridges. This is actually quite useful as I think that there can be multiple networkxxx.xml files, each supporting a vlan, and as the guest file references a particular network name, the appropriate vlan can be selected. I haven't tested it yet, but this should also allow multiple interfaces, each connected to a particular vlan.

Some older info on LXC on Debian Squeeze.

docker: an open source project to pack, ship and run any application as a lightweight container making use of LXC.


2013 Aug 11 - Sun

Understanding OpenVSWitch Configuration

My previous openvswitch article dealt with building a recent release on one system, migrating the .deb files to another system, installing them, and getting the daemon to run upon reboot. Last year I also wrote about some useful configuration commands, which dealt with simple access port style interfaces.

This article rehashes some of those commands, adds a few more refinements regarding vlan capabilities, and offers some additional background.

For working with vlan style interfaces, the documentation at ovs-vsctlman page is missing a few key information elements, elements I found at other sites. For example, to add an interface for handling a particular layer2/layer3 network end, something like the following is required:

ovs-vsctl add-br br0
ovs-vsctl add-port br0 vlan201 tag=201 -- set interface vlan201 type=internal

The first command is the well known method for adding a new bridge. As an aside, a bridge in this context would represent a switch, something which can deal with muliple vlans in the various access port and trunk port roles. The second command is the way to add an 'internal' interface into Linux. Ip addressing can be assigned interactively via something like:

ip addr add 10.11.1.20/24 dev vlan210

For persistance through boot cycles, the addresss should maintained in the /etc/network/interfaces file through the standard iface stanzas.

An article at blog.scottlowe.org covers some trunking commands. The gist is that by using something like the following to set specifically which vlans are available over a particular physical or tap port. I believe something like the following will work:

ovs-vsctl add-port br0 eth1 trunks=101,102

The trunks aspect can be added as a two step process:

ovs-vsctl add-port br0 eth1 
ovs-vsctl set port eth1 trunks=101,102

The author of that same article goes on to explain the philosophy of the ovs-vsctl command structure: it is a structure closely resembling the commands for updating the database. And when you do a list command, such as 'ovs-vsctl list port vlan201', you obtain a list of keys which can be updated with specific values. And in actual fact, I just learned by reading a comment at the end of the article, it is the ovs-vswitchd.conf.db manual which describes all the possible parameters and their values. The articles also has some interesting links for sFlow integration and even sFlow auto-configuration.

Some references regarding openvswitch:


Building openvswitch on Debian 7.1 (Wheezy)

openvswitch is a powerful Linux based utility for working with vlans, traffic filtering, monitoring, and QoS management within a hosted virtualization environment.

The current stable version of Debian, which as of this writing is version 7.1, has an older version of openvswitch. The version is many versions ago.

To use the most recent version of openvswitch will require manually building. These are the steps I performed to get the basic system in place.

wget http://openvswitch.org/releases/openvswitch-1.10.0.tar.gz
tar -zxvf openvswitch-1.10.0.tar.gz
cd openvswitch-1.10.0
apt-get install linux-headers-`uname -r`
apt-get install build-essential
apt-get install libssl-dev openssl pkg-config
apt-get remove bridge-utils
tc
./configure  \
  --prefix=/usr   \
  --bindir=/usr/bin   \
  --sbindir=/usr/sbin   \
  --sysconfdir=/etc   \
  --localstatedir=/var   \
  --libdir=/usr/lib   \
  --includedir=/usr/include   \
  --datarootdir=/usr/share    \
  --with-linux=/lib/modules/`uname -r`/build
make
make install
insmod datapath/linux/openvswitch.ko
lsmod | grep switch
/sbin/modinfo ./datapath/linux/openvswitch.ko
make modules_install
ovsdb-tool create /etc/openvswitch/conf.db vswitchd/vswitch.ovsschema
ovsdb-server \
  --remote=punix:/var/run/openvswitch/db.sock \
  --remote=db:Open_vSwitch,manager_options \
  --private-key=db:SSL,private_key \
  --certificate=db:SSL,certificate \
  --bootstrap-ca-cert=db:SSL,ca_cert \
  --pidfile --detach
ovs-vsctl --no-wait init
ovs-vswitchd --pidfile --detach

I put the following lines in /etc/rc.local to get things started after a reboot:

ovsdb-server \
  --remote=punix:/var/run/openvswitch/db.sock \
  --remote=db:Open_vSwitch,manager_options \
  --private-key=db:SSL,private_key \
  --certificate=db:SSL,certificate \
  --bootstrap-ca-cert=db:SSL,ca_cert \
  --pidfile --detach
ovs-vswitchd --pidfile --detach

Since I have a number of other servers requiring the same treatement, the openvswitch distribution comes with the meta files necessary for creating suitable Debian packages. The packages can be copied to the other servers and installed. The packages end up in the parent directory of the source distribution. Part of the packaging process involves running a series of unit tests, which appear to take more time than the build itself. The readme files explain options to turn those tests off.

cd /usr/src/openvswitch-1.10.0
apt-get install fakeroot debhelper
apt-get install autoconf automake python-all python-qt4 python-zopeinterface python-twisted-conch
dpkg-checkbuilddeps
make distclean
fakeroot debian/rules binary
apt-get install module-assistant
module-assistant auto-install openvswitch-datapath

When installing the .deb packages, auto-start stuff should automatically be dealt with, unlike the manual start stuff I performed at the beginning of this document.

There are a number of .deb packages, but only the following are really needed:

  • openvswitch-common_1.10.0-1_amd64.deb
  • openvswitch-switch_1.10.0-1_amd64.deb
  • openvswitch-datapath-module-3.2.0-4-amd64_1.4.2+git20120612-9_amd64.deb

These are secondary files. The controller is a simple OpenFlow controller. ovsdbmonitor is a GUI tool for remotely viewing OVS databases and OpenFlow flow tables.

  • openvswitch-controller_1.10.0-1_amd64.deb
  • ovsdbmonitor_1.10.0-1_all.deb
  • python-openvswitch_1.10.0-1_all.deb

To install on another server, copy the .deb files over and then:

  • apt-get install uuid-runtime
  • dpkg -i openvswitch-common_1.10.0-1_amd64.deb
  • dpkg -i openvswitch-switch_1.10.0-1_amd64.deb
  • dpkg -i openvswitch-datapath-module-3.2.0-4-amd64_1.4.2+git20120612-9_amd64.deb

I recieved errors like:

FATAL: Module openvswitch not found.
Inserting openvswitch module ... failed!
Starting ovsdb-server.
Configuring Open vSwitch system IDs.
FATAL: Module openvswitch not found.
Inserting openvswitch module ... failed!

I ran the following commands to get things operational:

  • depmod
  • modprobe openvswitch_mod
  • dpkg -i openvswitch-switch_1.10.0-1_amd64.deb
  • echo openvswitch_mod >> /etc/modules


2013 Aug 08 - Thu

HP Utilities on Debian MultArch amd64 x86_64

HP has utilities for managing hardware on HP Servers running Debian at SDR Repository Listing. Even though the files have suffix with amd64.deb, they are still 32 bit files. They have not been built natively for the x64 architecture.

In previous versions of Debian, the solution was to

  • apt-get install ia32-libs

This is now deprecated in Debian 7.0, 7.1, Wheezy. The solution is instead to turn on multi-architecture mode:

  • dpkg --add-architecture i386
  • apt-get update

Now, for example, the HP file hpacucli_8.70-8.0.2-2_amd64.deb can be installed with the following commands. The first line shows the 32 bit dependencies, the second installs the dependencies, and the third installs the package.

  • dpkg --info hpacucli_8.70-8.0.2-2_amd64.deb
  • apt-get install lib32gcc1 lib32stdc++6 libc6-i386
  • dpkg -i hpacucli_8.70-8.0.2-2_amd64.deb


2013 Mar 30 - Sat

GNS3 206-unable to create UDP NIO

GNS3 has it's benefits in terms of being able to test out reasonably complicated scenarios in terms of routing. But it does have it's quirks and issues.

One issue with the GNS3 0.8.4-RC2 release is in how it deals with its topology file. Well, now that I think of it, there are two issues I recently encountered with this build. If others encounter the same thing, I've included some work arounds.

The first issue I encountered is that when I built a topology, there were a few routers for which I did not create links. When I saved and then reloaded the topology file, the unlinked routers did not show up on the diagram. So.... whenever adding routers, ensure there is at least one link provided. This ensures that router shows up next time in the drawing.

The second issue is somewhat more insidious. A reasonably complicated set of routers and links can be created. The topology can then be saved. When restarting it a subsequent time, the following error occurs:

*** Warning: Connecting to resulted in: 206-unable to create UDP NIO *** Error: errors during loading of the topology file, please correct them

The solution to this is to manually edit the topology file and reorder the sections in ascending order, something like:

127.0.0.1:7200] ... section content [127.0.0.1:7201] ... section content ... simlar sections


2013 Mar 21 - Thu

GNS3 And OSPF-4-ERRRCV: Received invalid packet: Bad LLS Checksum

GNS3 works quite well for simulating and testing Cisco routed networks. However, when creating links between routers, there are times when the following message appears on the console of some interconnected routers:

OSPF-4-ERRRCV: Received invalid packet: Bad LLS Checksum

I am uncertain as to the source of this issue. Some forums recommend applying the command to each interface:

  • ip ospf network point-to-point

This did not work for me. Instead I tried the following at the interface level:

  • ip ospf authentication message-digest
  • ip ospf message-digest-key 1 md5 7

The above md5 digest key settings have stopped the errors from occuring.


2013 Mar 03 - Sun

FOFOA - (Gold) Friend of Friend of Another

FOFOA represents the continuation of an ongoing interpretation of a very long running commentary on the shadowy world of gold, oil, and international currencies.

The linked commentaries go back for more than ten years, and provide a whole new perspective on gold price 'discovery' mechanisms.

One fascinating aspect of reading through some of the 'Thoughts', was that the current depressed prices of gold producers could be attributed to the fact that world wide aggregate gold production is declining on a year to year basis. If there are not more inventories, nothing to sell, and therefore no value for the company. The issues are much more complex than that.

As well, the gold producers a bit more diversified than the statement suggests.


2012 Dec 07 - Fri

BGP Default-Information Originate

A brief note on the rules for originating a default route into BGP (copied from a posting made by Mohammed Mahmoud):

  • default-information originate + redistribute static (or any dynamic routing protocol having the default route - you may filter only the default route)
  • network command but must make sure the default route is present in the routing table
  • issuing the neighbor default-originate command. This method does not require the presence of the 0.0.0.0/0 network in the routing table of the advertising router

Additional notes: The configuration of the default-information originate command in BGP is similar to the configuration of the network (BGP) command. The default-information originate command, however, requires explicit redistribution of the route 0.0.0.0. The network command requires only that the route 0.0.0.0 is present in the Interior Gateway Protocol (IGP) routing table. For this reason, the network command is preferred.


2012 Oct 23 - Tue

HostDatastoreSystem.QueryVmfsDatastoreCreateOptions

I was having problems with getting a VMWare ESXi 5.1 Host to register properly with vSphere 5.0 (probably something seriously wrong with that whole concept all by itself). During the install of ESXi 5.1, the local drives were attached and formatted for vmfs capability.

Since I couldn't fix the registration problem, I rolled the host back to ESXi 4.1. When it came time to reformat and make the drives useful for vmfs, I encountered an error along the lines of:

VMware: Call "HostDatastoreSystem.QueryVmfsDatastoreCreateOptions" for object "ha-datastoresystem" on ESXi "SERVERNAME" failed

The comments of VMPros Virtualization provided the solution (with an enhancement included by someone in the comments):

  • I just did a .ls /vmfs/devices/disks/. from the shell to identify what was the vml I had to use.
  • To find the vml I just ran the following command .partedUtil get /vmfs/devices/disks/VMLID. and I got an error with the VMLID corresponding to the new drive.
  • After that, I just ran your .dd if=/dev/zero of=./vmfs/devices/disks/VMLID. bs=512 count=34 conv=notrunc. and I was able to add the hard drive.



New blog site at: Raymond Burkholder - What I Do

Blog Content ©2013
Ray Burkholder
All Rights Reserved
ray@oneunified.net
(441) 705-7292
(519) 838-6013
Available for Contract Work
Resume

RSS: Click to see the XML version of this web page.

twitter
View Ray 
Burkholder's profile on LinkedIn
technorati
Add to Technorati Favorites



September
Su Mo Tu We Th Fr Sa
 
16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        


Main Links:
Monitoring Server
SSH Tools
QuantDeveloper Code

Special Links:
Frink

Blog Links:
Sergey Solyanik
Marc Andreessen
Micro Persuasion
... Reasonable ...
Chris Donnan
BeyondVC
lifehacker
Trader Mike
Ticker Sense
HeadRush
TraderFeed
Stock Bandit
The Daily WTF
Guy Kawaski
J. Brant Arseneau
Steve Pavlina
Matt Cutts
Kevin Scaldeferri
Joel On Software
Quant Recruiter
Blosxom User Group
Wesner Moise
Julian Dunn
Steve Yegge
Max Dama

2014
Months
Sep
Oct Nov Dec




Mason HQ

Disclaimer: This site may include market analysis. All ideas, opinions, and/or forecasts, expressed or implied herein, are for informational purposes only and should not be construed as a recommendation to invest, trade, and/or speculate in the markets. Any investments, trades, and/or speculations made in light of the ideas, opinions, and/or forecasts, expressed or implied herein, are committed at your own risk, financial or otherwise.