media/mtransport/third_party/nrappkit/README@97036ab72558 (annotated)
media/mtransport/third_party/nrappkit/README
Tue, 06 Jan 2015 21:39:09 +0100
- author
- Michael Schloh von Bennewitz <michael@schloh.com>
- date
- Tue, 06 Jan 2015 21:39:09 +0100
- branch
- TOR_BUG_9701
- changeset 8
- 97036ab72558
- permissions
- -rw-r--r--
Conditionally force memory storage according to privacy.thirdparty.isolate;
This solves Tor bug #9701, complying with disk avoidance documented in
https://www.torproject.org/projects/torbrowser/design/#disk-avoidance.
| michael@0 | 1 | $Id: README,v 1.3 2007/11/21 00:09:10 adamcain Exp $ |
| michael@0 | 2 | |
| michael@0 | 3 | nrappkit 1.0b2 |
| michael@0 | 4 | Copyright (C) 2006 Network Resonance, Inc. |
| michael@0 | 5 | |
| michael@0 | 6 | |
| michael@0 | 7 | nrappkit is a toolkit for building standalone applications and |
| michael@0 | 8 | appliances. It provides: |
| michael@0 | 9 | |
| michael@0 | 10 | - registry-based configuration (with change callbacks) |
| michael@0 | 11 | - extensible command and configuration shell |
| michael@0 | 12 | - extensible statistics system |
| michael@0 | 13 | - configurable logging system |
| michael@0 | 14 | - event and timer handling |
| michael@0 | 15 | - generic plugin system |
| michael@0 | 16 | - launcher daemon |
| michael@0 | 17 | |
| michael@0 | 18 | The contents of nrappkit were extracted from Network Resonance's |
| michael@0 | 19 | product on the theory that they were generally useful for |
| michael@0 | 20 | application developers. |
| michael@0 | 21 | |
| michael@0 | 22 | THIS PACKAGE DOES NOT GRANT A LICENSE OR RIGHT TO ANY OTHER NETWORK |
| michael@0 | 23 | RESONANCE TECHNOLOGY OR SOFTWARE. |
| michael@0 | 24 | |
| michael@0 | 25 | |
| michael@0 | 26 | |
| michael@0 | 27 | BUILDING |
| michael@0 | 28 | |
| michael@0 | 29 | Builds are done semi-manually with port directories for each |
| michael@0 | 30 | platform. There are pre-existing ports to FreeBSD, Linux (Ubuntu |
| michael@0 | 31 | and Fedora Core), and Darwin (MacOSX). To build the system: |
| michael@0 | 32 | |
| michael@0 | 33 | cd src/make/<platform> |
| michael@0 | 34 | gmake |
| michael@0 | 35 | |
| michael@0 | 36 | Some of the platforms come in several variants. Most notably, |
| michael@0 | 37 | if a platform exists in "regular" and "-appliance" variant, |
| michael@0 | 38 | this means that the regular variant just builds binaries intended |
| michael@0 | 39 | to be run out of the make directory (for development) and the |
| michael@0 | 40 | appliance variant is intended to be installed in a real system. |
| michael@0 | 41 | |
| michael@0 | 42 | By default we want to install things owned as user "pcecap". |
| michael@0 | 43 | Either make this user or edit the Makefile to be a user you |
| michael@0 | 44 | like (e.g., nobody). |
| michael@0 | 45 | |
| michael@0 | 46 | If you want to include the 'nrsh' command-line configuration |
| michael@0 | 47 | tool in your build, you will need to make sure the line |
| michael@0 | 48 | BUILD_NRSH=yes |
| michael@0 | 49 | appears (uncommented-out) in your platform Makefile. You will |
| michael@0 | 50 | also need to to build OpenSSL and libedit and point your nrappkit |
| michael@0 | 51 | Makefile to the correct paths. You can obtain these packages at: |
| michael@0 | 52 | openssl-0.9.7l |
| michael@0 | 53 | http://www.openssl.org/source/openssl-0.9.7l.tar.gz |
| michael@0 | 54 | |
| michael@0 | 55 | libedit-20060829-2.9 |
| michael@0 | 56 | http://freshmeat.net/redir/editline/53029/url_tgz/libedit-20060829-2.9.tar.gz |
| michael@0 | 57 | |
| michael@0 | 58 | |
| michael@0 | 59 | INSTALLING |
| michael@0 | 60 | If you're doing an appliance as opposed to a development build, |
| michael@0 | 61 | you'll want to install it. This is easy: |
| michael@0 | 62 | |
| michael@0 | 63 | su |
| michael@0 | 64 | gmake install |
| michael@0 | 65 | |
| michael@0 | 66 | Most binaries and libraries ends up in /usr/local/pcecap while |
| michael@0 | 67 | data files are in /var/pcecap. However, you can tweak |
| michael@0 | 68 | this in the Makefile. By default it's all owned by pcecap. |
| michael@0 | 69 | |
| michael@0 | 70 | To ensure that dynamic libraries are loaded correctly at runtime, |
| michael@0 | 71 | you'd want to make sure the right directory is included in your |
| michael@0 | 72 | LD_LIBRARY_PATH or via ldconfig. |
| michael@0 | 73 | |
| michael@0 | 74 | |
| michael@0 | 75 | QUICK TOUR |
| michael@0 | 76 | The build makes the following binaries that you may find useful: |
| michael@0 | 77 | |
| michael@0 | 78 | - captured -- the launcher (the name is historical) |
| michael@0 | 79 | - registryd -- the registry daemon |
| michael@0 | 80 | - nrregctl -- a registry control program |
| michael@0 | 81 | - nrsh -- the command shell (when included in build) |
| michael@0 | 82 | - nrstatsctl -- the stats control program |
| michael@0 | 83 | |
| michael@0 | 84 | Using the nrcapctl script is the easiest way to interact with |
| michael@0 | 85 | the applications. It is run as "nrcapctl <command>" with the |
| michael@0 | 86 | following commands recognized: |
| michael@0 | 87 | |
| michael@0 | 88 | startup -- fires up captured, which in turn runs and |
| michael@0 | 89 | initializes the registry |
| michael@0 | 90 | |
| michael@0 | 91 | shutdown -- kills captured and its child processes |
| michael@0 | 92 | |
| michael@0 | 93 | status -- prints the running status of captured in |
| michael@0 | 94 | human-readable form |
| michael@0 | 95 | |
| michael@0 | 96 | stat -- prints the running status of captured in |
| michael@0 | 97 | a form easily parsed by scripts |
| michael@0 | 98 | |
| michael@0 | 99 | enable -- alters the mode.txt file so that captured |
| michael@0 | 100 | starts |
| michael@0 | 101 | |
| michael@0 | 102 | disable -- alters the mode.txt file so that captured |
| michael@0 | 103 | does not start |
| michael@0 | 104 | |
| michael@0 | 105 | clear-statistics -- equivalent to "nrstatsctl -z" (requires |
| michael@0 | 106 | that captured be running) |
| michael@0 | 107 | |
| michael@0 | 108 | Note: the "start" and "stop" nrcapctl commands do nothing as they |
| michael@0 | 109 | use components not included in nrappkit. However the associated |
| michael@0 | 110 | script logic in nrcapctl demonstrates how additional applications |
| michael@0 | 111 | might be launched using nrcapctl and particular registry settings. |
| michael@0 | 112 | |
| michael@0 | 113 | |
| michael@0 | 114 | EXTENDING |
| michael@0 | 115 | When things come up, they're pretty dumb. You'll probably want to |
| michael@0 | 116 | write your own applications, otherwise it's not clear why you're doing |
| michael@0 | 117 | this. The general idea is that you write your application using the |
| michael@0 | 118 | facilities that nrappkit provides and then write plugins to the |
| michael@0 | 119 | nrappkit components as necessary. So, for example, say you want |
| michael@0 | 120 | to write a network daemon. You would: |
| michael@0 | 121 | |
| michael@0 | 122 | - configure the launcher to launch your daemon (using the registry, |
| michael@0 | 123 | naturally). |
| michael@0 | 124 | - make calls to the registry to get configuration data |
| michael@0 | 125 | - make calls to the logging system to log data |
| michael@0 | 126 | - implement a stats module to record statistics |
| michael@0 | 127 | - write a plugin to nrsh to let people configure your parameters |
| michael@0 | 128 | |
| michael@0 | 129 | Examples of some of this stuff can be found in examples/demo_plugin. |
| michael@0 | 130 | Otherwise, read the source. More documentation will be on the way, |
| michael@0 | 131 | hopefully. |
| michael@0 | 132 | |
| michael@0 | 133 |
