midendian / timps Goto Github PK

See:
   http://www.zigamorph.net/timps/


=== REQUIREMENTS ===

For compiling, you'll need the following packages, including the related
developement files (the -dev package or whatever).
  - expat
  - autoconf/automake
  - libtool

For the nafconsole module, you'll need the following, but you can just ignore
the compilation errors if you don't want it.
  - ncurses
  - readline

For the off-the-record messaging module, you'll need libotr installed.


=== COMPILING ===

To compile:
  ./gen ; ./configure ; make


=== RUNNING ===

For development, I run it something like this:
   timps/timpsd -c ~/timps.conf -d -D -M modules/nafconsole/.libs/libnafconsole.so
All messages will go to the log file specified in the config (see below), and
you will be given a "timps>" prompt (thanks to nafconsole).  From this
prompt, you can make RPC calls.  Try "call rpc->help()", for example.  The
most helpful right now is probably "call gnr->listnodes()" which will show
you the users currently online.

To run it as a daemon, use the much simpler:
   timpsd -c /etc/timps.conf
And it will fork and detach from the terminal into the background.  Note that
the config file path must be absolute, since daemonizing loses the current
working directory.

To use with AIM, change your client's authorizer, which is normally set to
login.oscar.aol.com:5190, to point to the machine running timps, and the port
that timps-oscar is configured for (see [module=conn] section of the config
file).  If the machine that timps is running on has a different IP than it
knows about (because of NAT, etc), add an 'extipaddr' line to the [module=conn]
section, so that it can tell clients to connect back in the right place.


=== OFF-THE-RECORD MESSAGING ===

If you want to use the OTR module, you will need to install libotr and all of
its dependencies.  Get that from here:  http://www.cypherpunks.ca/otr/

The timps-otr module is not compiled by default.  Once you build the rest of
timps, go to modules/timpsotr and run make.

Add a [module=timps-otr] section to your timps.conf that contains at least the
keyfilepath parameter, as shown in the sample configuration.  (The directory
specified must be writable by timps.) Then, add: 
    -M modules/timpsotr/.libs/libtimpsotr.so
to your timpsd command line.  (You can have multiple -M options.)

If it doesn't seem to be working, make sure there are no errors near the
"loaded module timps-otr" line in the timps system log.  Depending on your
system, you may need to run something like /sbin/ldconfig, or add the location
of libotr.so to something like /etc/ld.so.conf.

WARNING: The OTR module is even more experimental/fragile than the rest of
timps!


=== SAMPLE CONFIGURATION ===

Configuration file suitable for development (all debugging on):

----- SNIP -----

[module=conn]
listenports=5190/timps-oscar
debug=10
; if the clients connect to the server on a different address than the server
; knows about, set this
;extipaddr=66.66.66.66

[module=timps]
debug=10

[module=timps-logging]
; prefixed to filenames below
logfilepath=/home/mid/tmp/timps
; admin log gets all messages and user (dis)connects
adminlogfile=timps-message.log
; this will create a log file for each local user in the path above, of the
; form 'logfilepath/timps-userlog.SERVICE.screenname'
enableperuserlogs=false

; for the OTR module
[module=timps-otr]
; where the private key and fingerprint store files will be created
keyfilepath=/home/mid/tmp/timps
debug=10

[module=timps-oscar]
debug=10
; if you're using aimdlite for testing
;authorizer=localhost:6190
; default is login.oscar.aol.com:5190
; prorogueall will cause server connections to stay open even if client dies
;enableprorogueall=yes

[module=logging]
; this is the low-level logging module (in NAF) -- it does not see IMs
logfilepath=/home/mid/tmp/timps
systemlogfile=timps-system.log

[module=gnr]
debug=10

[module=nafconsole]
; you can use these to make nafconsole a little more pleasant.
usemacros=help,memuse,users
macro[help][expansion]=call rpc->help()
macro[memuse][expansion]=call core->modmemoryuse()
macro[users][expansion]=call gnr->listnodes()

----- /SNIP -----


=== USING NAFNET AND IPv4 ===

Although not useful for timps (at present, at least, and I'm not sure what it
would use it for), naf includes a basic IPv4 implementation.  You can use this
to build extremely low-level applications, particularly prototyping new
protocols without the hassle of the kernel development cycle (ie, crashing your
machine).

There is currently only one driver: Linux tun/tap, and that really only
supports tun, not tap.  A pcap/libnet driver that can use a real ethernet
interface is on the way.

To use tun/tap:
  1. Compile the tun/tap driver into your kernel (or as a module)
  2. The tunN devices are created dynamically (by naf via the kernel).  Sadly,
     this creates a permissions nightmare.  If you don't want to run naf/timps
     as root (and I don't suggest it), set the permissions of /dev/net/tun to
     some normal user, and run naf/timps as that.  Unfortunately, in that
     configuration, naf cannot configure the Linux side of the tunnel for you,
     so every time you start naf, you'll need to run ifconfig as root after it
     starts every time (!!!).
  3. If you don't have /dev/net/tun, do 
        mkdir /dev/net && mknod /dev/net/tun c 10 200
     (and set permissions of that file as described above).
  4. Add stuff like this to your timps/naf config:

[module=net]
debug=10
interface[lnx0][ipv4][address]=10.0.4.2
interface[lnx0][ipv4][mask]=255.255.255.0
interface[lnx0][mtu]=1500
interface[lnx0][state]=up

[module=ipv4]
debug=10

[module=linuxtun]
debug=10

  5. Start up naf.  On another terminal, run ifconfig.  For the config above,
     it'd be:
       ifconfig tun0 10.0.4.1 pointopoint 10.0.4.2
     That makes the Linux side .1 and the naf side .2.
  6. Ping should work:
	# ping 10.0.4.2
	PING 10.0.4.2 (10.0.4.2): 56 data bytes
	64 bytes from 10.0.4.2: icmp_seq=0 ttl=255 time=0.7 ms
	64 bytes from 10.0.4.2: icmp_seq=1 ttl=255 time=0.3 ms
     Note that with all that debugging turned on (particularly if you have the
     conn module set to debug=10), the latency will be really high, due to the
     logging of every packet a gazillion times.