--- /dev/null
+title: APT Repository
+linktitle: aptrepo
+parent: TOP
+ctime: 2009-12-10
+
+Repositories: [[aptrepo]].
+
+# Introduction
+
+TMI maintains an APT repository containing some of the code available from this
+website. We use this repository in-house, and it is fairly well tested on 32
+and 64 bit Intel and AMD based workstations running Ubuntu Hardy and Ubuntu
+Karmic.
+
+# How to use
+
+## Step 1 - Add the backports repository
+
+Ubuntu Hardy users need to activate the hardy-backports repository to use our
+`cp210x-module-dkms` package. Ubuntu Karmic users can skip this step. Note,
+you can also activate hardy-backports from the GUI.
+
+ sudo cp /etc/apt/sources.list /etc/apt/sources.list.bak
+ cat <<+EOF+ | sudo tee -a /etc/apt/sources.list
+ deb http://us.archive.ubuntu.com/ubuntu hardy-backports main restricted universe multiverse
+ +EOF+
+
+## Step 2 - Adding the TMI repository to sources.list.d
+
+ cat <<+EOF+ | sudo tee /etc/apt/sources.list.d/tmi.list
+ # TMI repository
+ deb http://repo.titaniummirror.com/ubuntu hardy main
+ deb-src http://repo.titaniummirror.com/ubuntu hardy main
+ +EOF+
+ sudo apt-get update
+
+## Step 2 - Adding the TMI package key
+
+When you issued `apt-get update` above, you saw a key warning. We solve this
+by installing a package from the TMI repository that contains our packaging
+key.
+
+ sudo apt-get install --yes --allow-unauthenticated tmi-keyring
+
+You should now verify the installed key. Run the `sudo apt-key list | less`
+and look for the following two lines, ensuring your output matches that below:
+
+ pub 1024D/E9BE0373 2009-12-08
+ uid TMI Packages <pkgs@titaniummirror.com>
+
+## Step 3 - Install packages
+
+You can now install packages from the TMI repository. For example:
+
+* Install our [[cp210x]] driver: `sudo apt-get install cp210x-module-dkms`
+
+* Install our [[tinyos]] development suite: `sudo apt-get install tinyos`
--- /dev/null
+title: CP210X
+linktitle: cp210x
+parent: TOP
+ctime: 2009-12-10
+
+Repositories: [cp210x](http://repo/gitweb/?p=cp210x.git;a=summary), [[aptrepo]].
+
+# A USB to UART chip
+
+[Silicon Labs](http://www.silabs.com) sells a single-chip USB to UART bridge,
+the [cp210x](http://www.silabs.com/products/interface/usbtouart/Pages/default.aspx).
+For windows platforms, Silicon Labs offers manufacturing support, in the form
+of a DLL and a small utility, to set the various USB descriptor fields, port
+configurations, etc. They also offer a DLL and example programs showing how
+to manipulate the GPIO pins available on the cp2103 part.
+
+With approval from Silicon Labs, TMI has modified their reference Linux driver
+to support all of the features their Windows DLLs and utilities provide. This
+is accomplished via extended ioctl() calls from the kernel cp210x driver, and
+various utilities and sample code. This code is really invaluable for those
+working on hardware device designs using the cp2103. The code is released
+under the GPLv2.
+
+TMI sent the modified code back to Silicon Labs, who supposedly had someone
+in-house (or contracted) who regularly works with the maintainer of the cp210x
+(formerly cp2101) driver in the mainline Linux kernel. That was over a year
+ago, and the code hasn't shown up. We will be working with the maintainer
+directly to get this code available. In the mean time, it is available
+[as source](http://repo/gitweb/?p=cp210x.git;a=summary) and from our
+[[aptrepo]]. The `cp210x-module-dkms` package in the APT repository has been
+tested on Ubuntu Hardy and Karmic systems with both 32 and 64 bit x86
+(Intel/AMD) processors.
--- /dev/null
+title: Router Firmware
+linktitle: firmware
+parent: TOP
+ctime: 2006-02-13
+
+Tarball: [gpl](http://www.titaniummirror.com/gpl).
+
+TMI has developed a fault tolerant internetworking platform composed of a set
+of proprietary cluster, event and web management applications running atop a
+GNU/Linux open source platform core. Essentially, the core represents a
+customized Linux distribution geared specifically for network appliances. TMI's
+proprietary code does not link with any GPL components of the core. Some
+minor changes have been made to the core components. Those changes are
+available [here](http://www.titaniummirror.com/gpl).
--- /dev/null
+title: GIT Utilities
+linktitle: git-utils
+parent: TOP
+ctime: 2009-12-10
+
+Repositories: [git-utils](TBD).
+
+# GIT
+
+Read about [GIT](http://git-scm.com) here.
+
+# Utilities
+
+Over time, TMI is starting to collect a number of small utilities for git.
+These are available from our [git-utils](TBD) repository. Each utility has
+a man page describing its operation, so we'll only highlight the basics here.
+
+* git-empty-branch. Create an empty branch in a local git repository.
+
+* git-local. Store local branches temporarily in a shared git repository,
+ probably hosted on a server used by the local development team. git-local
+ offers upload, download, remove and list operations.
+
+* git-publish-branch. A shell version of a ruby script created by William
+ Morgan. See his [git utilities page](http://git-wt-commit.rubyforge.org).
+ This has been a locally popular utility, and we did not want to see ruby
+ effectively become yet another pre-requisite for git.
-title: Webber
-ctime: 2009-06-24
+title: Our OSS Projects
+linktitle: TOP
+ctime: 2009-12-15
-* [[overview]]
-* [[pageformat]]
-* [[configuration]]
- * [[commandline]]
- * [[inheritance]]
-* [[plugins]]
- * [[read_rst]]
- * [[read_markdown]]
- * [[read_html]]
- * [[read_copyonly]] (e.g. images)
- * [[link]]
- * [[hierarchy]]
- * [[template_mako]]
- * [[skeleton]]
-* [[hooks]]
-* [[functions]]
-* [[macros]]
-* [[templates]]
+# Introduction
+
+[Titanium Mirror, Inc.](http://www.titaniummirror.com) (TMI) is a successful
+small business in part because we have can leverage the development work of
+other talented professionals who have opted to release the product of their
+labors as Open Source Software (OSS). Over time, we have made our own changes
+to support our business and customers. We publish our work to this website in
+case others find our contributions useful.
+
+Of course, we make an effort to contribute patches to the relevant upstream
+maintainers. But it takes time for patches to migrate upstream, and there is
+no guarantee that something we find useful is general enough to be incorporated
+into an upstream project. For these reasons, we publish this website.
+
+# The Projects
+
+Select a project to browse from the Navigation panel on the left.
--- /dev/null
+title: MSP430
+linktitle: msp430
+parent: TOP
+ctime: 2008-01-03
+
+Repositories:
+[msp430-binutils](http://repo/gitweb/?p=msp430-binutils.git;a=summary),
+[msp430-gcc](http://repo/gitweb/?p=msp430-gcc.git;a=summary),
+[msp430-libc](http://repo/gitweb/?p=msp430-libc.git;a=summary),
+[[aptrepo]].
+
+TMI maintains an msp430 toolchain, including [[Ubuntu packages|aptrepo]], which
+work with newer members of the msp430 family, such as the popular
+MSP430F2618 part and is properly patched for use in
+[[TinyOS]] development. The official TinyOS distribution
+provides an older msp430 toolchain that does not support some of the newer
+msp430 parts. The msp430 toolchain is composed of: binutils, gnu compiler,
+and libc.
--- /dev/null
+title: OSS Website Code
+linktitle: oss-web
+parent: TOP
+ctime: 2009-12-15
+
+Repositories: [oss-web](http://repo/gitweb/?p=oss-web.git;a=summary).
+
+This website is statically generated using [[Webber]] from the source code
+link above.
--- /dev/null
+title: OpenVZ + BackupPC
+linktitle: ovzbpc
+parent: TOP
+ctime: 2008-06-09
+
+Repositories: [backuppc](http://repo/gitweb/?p=backuppc.git;a=tree),
+[ovz](http://repo/gitweb/?p=ovz.git;a=tree),
+[esata](http://repo/gitweb/?p=esata.git;a=tree).
+
+# OpenVZ
+
+TMI hosts its compute resources on DELL PE1800 servers configured as a cluster
+of [OpenVZ](http://www.openvz.org) Hardware Nodes (HN's), which host multiple
+OpenVZ Virtual Environments (VE's). Open VZ VE's are virtual machines
+virtualized at the operating system. The downside is that all VE's must be
+Linux instances capable of running on the OpenVZ kernel. The upside is that
+far more OS virtualized instances can reside on a given set of hardware
+compared to virtualizers like VMWare and Xen, which (para-)virtualize hardware.
+
+# BackupPC
+
+TMI uses [BackupPC](http://backuppc.sourceforge.net) for backup services across
+our company, including notebooks, workstations and servers (OpenVZ VE's). We
+are especially happy with BackupPC and how it is integrated into our server
+environment. Each HN is backed up as a separate host, but none of the data
+for any VE's it may be hosting. Each VE is also backed up, each as a separate
+host. Our HN's use LVM, and our add-on scripts allow for backup of any VE with
+minimal downtime. The scripts actually shut down the VE, create a snapshot of
+the HN volume on which the VE's filesystem is stored, restarts the VE,
+completes the over-the-net BackupPC backup operation, then removes the snapshot.
+By shutting down the VE, we ensure the integrity of the backup without
+requiring application specific tools like database hotcopy scripts. By using
+LVM, the VE downtime is typically less than 90 seconds. We backup every system
+every evening.
+
+# Off-site backups
+
+BackupPC maintains an on-disk archive of de-duplicated backups for all hosts.
+We maintain off-site backups by cloning the BackupPC archive to removable
+eSATA disks. For fastest recovery, we run BackupPC in a VE within our
+server infrastructure, so what we clone to an external disk is the entire
+BackupPC VE filesystem. We also keep a second partition on each removable
+disk, which contains, essentially, our HN operating system. eSATA connections
+make this backup operation very fast. And because a human must connect an
+external drive prior to the backup, that person can also provide the necessary
+key that allows the external drive filesystems to be cryptographically secure.
+We clone the BackupPC archive once per week, and rotate several external
+drives through the off-site location.
+
+# Recovery
+
+A word about recovery: great. This combination of technologies allows the
+recovery of any system, directory, or file stored within the BackupPC archive
+over the network. The data need not be recovered to the same machine from
+which it was backed up, nor does it need to be placed in the same directory.
+Restore operations are done via a web interface, and the interface does not
+have to be accessed from the machine to which the data are to be restored.
+
+Disaster recovery is also a big plus. The entire TMI infrastructure can be
+reconstructed onto new hardware from just one off-site archive drive.
+
+# TMI code
+
+TMI maintains a number of code repositories containing scripts, etc. for
+integrating OpenVZ and BackupPC. Please be aware that these are formulated
+somewhat specifically for our environment. But if you have a similar setup,
+they should be usable with minimal massaging. Someday, someone here will take
+the time to merge this stuff into a single repo and document it better.
+
+# BackupPC scripts
+
+The [BackupPC scripts repository](http://repo/gitweb/?p=backuppc.git;a=tree)
+includes:
+
+* BackupPC_ovz. Installed on an HN, it allows BackupPC to backup from and
+ restore to any VE hosted on any HN in the cluster. When VE's are migrated
+ between HN's, the backup configuration does not need to change.
+
+* Holger Parplies' BackupPC_verifyPool.
+
+* See the [README](http://repo/gitweb/?p=backuppc.git;a=blob;f=README;hb=HEAD)
+ in the repository for more information.
+
+# OpenVZ scripts
+
+The [OpenVZ scripts repository](http://repo/gitweb/?p=ovz.git;a=tree)
+includes:
+
+* bpcdump. Similar in concept to vzdump. Although fairly general in nature,
+ we use it only for backing up the BackupPC VE, whose filesystem is on a
+ private LVM LV (logical volume), to an eSATA drive.
+
+* bpcbackup. A script that runs from crontab on one or more HN's to launch
+ the bpcdump program. Since all our HN's are configured the same, each has
+ an eSATA port and can be used to perform a backup of the BackupPC VE.
+
+* See the [README.recover](http://repo/gitweb/?p=ovz.git;a=blob;f=README.recover;hb=HEAD)
+ file for mroe information.
+
+# eSATA scripts
+
+The [eSATA scripts repository](http://repo/gitweb/?p=esata.git;a=tree)
+contains the esata script, which wraps the `scsiadd` utility for properly
+handling esternal drives on the Dell PE1800 and PE1900 platforms. Newer
+hardware and better Linux kernel support should someday make scripts like this
+unnecessary. See the included
+[README](http://repo/gitweb/?p=esata.git;a=blob;f=README;hb=HEAD) file for
+more information.
<div class="articleListing">
<h2>Navigation</h2>
<ul class="directory">
-% for level, part_of_path, current, page, link in get_sidemenu('Webber'):
+% for level, part_of_path, current, page, link in get_sidemenu('TOP'):
% if current:
<li class="active sidebar${level}">
% else:
<%def name="contents()">\
${body}
<%
- site = get_sitemap("Webber", True)
+ site = get_sitemap("TOP", True)
%>
<ul>
% for level, page, link in site:
--- /dev/null
+title: TinyOS
+linktitle: tinyos
+parent: TOP
+ctime: 2009-12-07
+
+Repositories: [tinyos](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary),
+[[aptrepo]].
+
+TMI uses [TinyOS](http://www.tinyos.net) for various data acquisition
+applications, and we maintain a modified tree that supports certain features
+not available in the official tree. We maintain a
+[repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary) containing
+our TinyOS tree, in which we also maintain a cogent patchset against the
+official tree.
+
+* Current patchset tag: patchset/2.1.0-3
+* Build from official release tag: tinyos/2.1.0
+* View the patchset [here](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=shortlog;h=refs/tags/patchset/2.1.0-3).
+
+Our TinyOS requires a newer [[msp430]] toolchain. A complete TinyOS
+development environment including a newer toolchain is available for
+installation from our [[APT repository|aptrepo]].
--- /dev/null
+title: TinyOS Packages
+linktitle: tinyospkgs
+parent: aptrepo
+ctime: 2009-12-10
+
+Repositories: [tinyos](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary),
+[[aptrepo]].
+
+## Package versioning
+
+The TinyOS packages are built from the TMI
+[TinyOS repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary). The
+package version number is of the form `tosver-tmiver`, where `tosver` is the
+official TinyOS release version on which the code is based, and `tmiver` is the
+version of the modifications applied by TMI.
+
+These version numbers are present in the
+[repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary) in the form
+of release and patchset tags. For example, the code from which package version
+`2.1.0-3` is built is tagged `release/2.1.0-3`. This code is based on the
+upstream version `2.1.0`, which is tagged in the repository as `tinyos/2.1.0`.
+A clean patchset is tagged `patchset/2.1.0-3`, where the commits between these
+two tags represent a clean set of patches that apply the TMI modifications to
+the upstream version.
+
+## Git/CVS issues
+
+Because CVS and git tags are fundamentally incompatible, we cannot guarantee
+that a git repo using `git-cvs` and tracking the upstream CVS repository will
+result in the exact same checkout tree state at each tag. We resolve this
+issue as follows:
+
+* TMI tracks the upstream CVS in a git mirror repository updated periodically
+ via a script using `git-cvsimport`.
+
+* When TMI wants to rebase its local modifications on a newer version of
+ upstream TinyOS, it pulls changes in from this mirror git repo into the
+ [TMI TinyOS repository](http://repo/gitweb/?p=tmi/tinyos-2.x.git;a=summary)
+ onto the `upstream` branch. Release tags, such as `release_tinyos_2_1_0_0`
+ from CVS are also pulled.
+
+* In git, a new release branch is created at the release tag. In this example,
+ release tag `release_tinyos_2_1_0_0` is the branch point for the new branch
+ `release/2.1.0`.
+
+* The tag `tinyos/2.1.0` is the tag of git tree along the `release/2.1.0`
+ branch where the checkout of git at `tinyos/2.1.0` exactly matches the
+ checkout of upstream CVS at `release_tinyos_2_1_0_0`.
+
+** If the git and CVS tags checkout trees that match at tag
+ `release_tinyos_2_1_0_0`, then `tinyos/2.1.0` tags that same commit.
+
+** If the git and CVS checkouts diverge, then the first commit along the new
+ `release/2.1.0` branch contains the changes necessary to sync git with CVS
+ at the release tag. This is accomplished by using `git_load_dirs`. This
+ new commit to the release branch is tagged `tinyos/2.1.0`.
+
+## Multiple source trees
+
+TMI TinyOS packages allow for the installation of multiple TinyOS source trees.
+This allows us to maintain older programs built against older versions of
+TinyOS while simultaneously working on new applications. It also allows us to
+compile code against the official TinyOS releases in addition to the TMI
+enhanced releases.
+
+This is accomplished by altering how TinyOS source is installed. The standard
+convention is for the TinyOS source tree to be installed on a development
+workstation at `/opt/tinyos-2.x`. The TMI packages install the source trees
+at `/opt/tinyos/VER`. For example, the official TinyOS 2.0.2.2 source tree
+would install at `/opt/tinyos/2.0.2.2`, and the TMI enhanced TinyOS 2.1.0-3
+tree installs at `/opt/tinyos/2.1.0-3`. A sourceable script,
+`/opt/tinyos/tinyos.sh`, is used to set which source tree is used by the
+TinyOS development tools and build system. The script is also sourced in
+the user's profile to provide persistence of settings across logins and reboots.
+
+Each TinyOS source tree has its own package. Here are the currently available
+trees as of this writing:
+
+ $ sudo apt-cache search tinyos-source
+ tinyos-source - TinyOS source meta package
+ tinyos-source-2.0.1 - TinyOS source code tree
+ tinyos-source-2.0.2.2 - TinyOS source code tree
+ tinyos-source-2.1.0 - TinyOS source code tree
+ tinyos-source-2.1.0-3 - TinyOS source code tree
+
+At least one tree must be installed, and the latest tree is installed each time
+the tinyos packages are installed or upgraded. However, the developer may
+keep multiple trees installed if necessary. The APT package upgrade
+mechanisms work properly.
+
+## Installing TinyOS
+
+To install TinyOS, perform the steps above to configure the TMI repository on
+the workstation, then type:
+
+ sudo apt-get install tinyos
+
+By default, the latest TinyOS source tree, with TMI enhancements, and the TMI
+[[msp430]] toolchain are installed. At this point, additional tinyos source
+trees may be installed as required. For example:
+
+ sudo apt-get install tinyos-source-2.1.0
--- /dev/null
+title: TMIcore
+linktitle: tmicore
+parent: TOP
+ctime: 2009-12-02
+
+Repositories: [tmicore](TBD).
+
+TMI has developed an [[msp430]] target board for low power data acquisition.
+Its design is not complete yet, but it is (SOON) available under an open
+source license. The design was created using [Eagle](http://www.cadsoft.de).
+
+We call our target board TMIcore. In actuality, the board shown in the design
+is the TMIrws board, which contains at its core the TMIcore design. The PCB
+design shows where it can be 'cut' to build a stand-alone TMIcore board.
+The full TMIrws board is the heart of a solar powered remote weather station
+that reports its observations to an internet server via the cellular network.
template: default
-subtitle: "Webber"
+subtitle: "OSS"
main_url: "www.holgerschurig.de/projects/webber"
date_format: "%Y-%m-%d %H:%M:%S"
input_encoding: "iso-8859-1"
--- /dev/null
+title: Webber
+linktitle: webber
+parent: TOP
+ctime: 2009-12-15
+
+Repositories: [webber](http://repo/gitweb/?p=webber.git;a=summary).
+
+[Webber](http://gitorious.org/webber) is a great static website generator
+written in Python by
+[Holger Schurig](http://www.holgerschurig.de/projects/webber/). We maintain
+a [local copy](http://repo/gitweb/?p=webber.git;a=summary) of his repository
+with a few changes. This website is built using webber; see [[oss-web]].
projects / oss-web.git / commitdiff