liz/hacdc-wiki
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Restructered pre-import

Browse Source
This commit is contained in:
Liz Cray
2024-07-07 13:53:31 -04:00
parent 47996087db
commit cc9e65b5c6
302 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

10
Old Pages/Byzantium/ByzantiumContact.md Executable file
View File

@@ -0,0 +1,10 @@
## HacDC Byzantium Team Contact Info
- IRC
- [IRC on freenode](irc://irc.freenode.net/#byzantium)
- [IRC Web
Chat](http://webchat.freenode.net/?channels=byzantium&uio=d4)
- [Bug Reports](https://github.com/byzantium/byzantium/issues)
- [Email the mailing list](mailto:byzantium@hacdc.org)
- [Subscribe to the Byzantium mailing
list](https://groups.google.com/a/hacdc.org/group/Byzantium/topics)

37
Old Pages/Byzantium/Byzantium_101.md Executable file
View File

@@ -0,0 +1,37 @@
- Download a copy of [Porteus Linux](http://porteus.org).
- Install it to a USB key or virtual machine, depending on your
preference. Use the official Porteus instructions to do so.
- Set up an account at [Github](https://github.com) and start watching
[Project Byzantium](https://github.com/Byzantium/Byzantium).
- This will let you not only watch the project's activity from your
Github dashboard, but if you join the project you'll be able to
check code in.
- You'll also be able to open new tickets in the bug tracker, and
comment on existing ones.
- Check out a copy of the source code: **git clone
<git://github.com/Byzantium/Byzantium.git>**
- Now you'll have all of the code we've written.
- To update your local checkout, change to the Byzantium directory and
run the command **git pull**.
- If you just want to try the latest build of Byzantium, download [the
Byzantium
module](http://svn.virtadpt.net/byzantium/000-byzantium.xzm) and
copy it into the directory */porteus/modules/* on your USB key or in
your virtual machine after you've booted it. The module will be
automatically activated the next time it's booted.
- Note that 000-byzantium.xzm isn't updated as often as the source
code repository is, so it may not be up to date.
- Join the [mailing
list](http://groups.google.com/a/hacdc.org/group/Byzantium/?hl=en).
Note that you'll need a Gmail account of some kind.
- Once you're on the list, post an introduction! Tell us how you found
out about Byzantium and a little about what you would like to work
on.
- Pick something to work on!
- Pick a ticket in the [bug
tracker](http://svn.virtadpt.net/byzantium/000-byzantium.xzm) and
fix it. Tell us about it on the mailing list if you don't already
have commit access and post a patch (**git diff**) if not.
- Experiment with Byzantium. If you manage to break it somehow, open a
ticket in the bug tracker and tell us about it. Even better, post a
fix for it.

46
Old Pages/Byzantium/Byzantium_Action_Log.md Executable file
View File

@@ -0,0 +1,46 @@
If you contribute to the Byzantium project in anyway (including
intellectually) please add a brief (if it's more than 280 characters
consider linking to a separate page) entry to this page or have someone
with edit access to this page in the following format. If there is an
objection to an entry it can always be removed so don't be afraid to
write something. If you don't want to be identified you can use the name
"Anonamoose" or anything else you want (but Anonymoose is the best
choice :P). Try to keep it in roughly chronological order if you can but
close is good enough ([haxwithaxe](User:haxwithaxe "wikilink") will
probably rewrite the page after running it through sort occasionally).
- YYYY/mm/dd - Name - description and links etc
## Log
### 2011
- 2011/09/30 - group - byzantium planning meeting: discussed use cases,
routing between meshes with nonmesh clients, prepared to finalize the
development (pre-pre-alpha) build of the live distro
- 2011/10/01 - haxwithaxe - made this page for people to record their
contributions
- 2011/10/01 - group - byzantium sprint day: TBD
- 2011/7/9 - drwho - Set up <http://svn.virtadpt.net/byzantium> for
Porteus modules
- Started coding web control panel for Byzantium
- Converted Slackware v13.37 packages into Porteus modules
- Converted Slackware packages from slackbuilds.org into Porteus
modules.
- Packaged web apps into Porteus modules.
- Tested package compilation using the scripts Ben and Chris wrote.
Noted the ones that worked, opened tickets in the [bug
tracker](https://github.com/Byzantium/Byzantium/issues) for the ones
that didn't, tried to include enough information to help figure out
what's going wrong in the package builder.
- 2022/11/13 - drwho - Figured out how to put together a fakeroot
directory structure that could then be used to build
000-byzantium.xzm. This is the core module of Byzantium Linux.
- Put together the 000-byzantium.xzm module for demonstration as an
alpha release.
- Debugged rc.setup_mysql initscript so that it sets up the necessary
application MySQL databases on an instance of Byzantium and locks it
down. It's also extensible enough to build new functionality on
later.
### 2012

50
Old Pages/Byzantium/Byzantium_Distributed_DNS.md Executable file
View File

@@ -0,0 +1,50 @@
## Summary
The problem: <http://en.wikipedia.org/wiki/Zooko's_triangle>
## Suggested Reading
[CJDNS](https://github.com/cjdelisle/cjdns) - CJDNS == CJD's Network
Suite. it does not contain a ddns system yet. it currently uses plain
old DNS within the darknet. <s>True DNS (i.e., port 53/UDP) with a DHT.
I've played around with it a little and it seems to do what it says on
the tin.</s>
[Distributed Hash Table
(DHT)](http://en.wikipedia.org/wiki/Distributed_hash_table) - Wikipeda
page on DHTs. Has a decent overview of how they work.
[Bamboo DHT](http://www.bamboo-dht.org/) - A DHT implementation in Java.
[UpRight](http://code.google.com/p/upright/) - A library for building
fault-tolerant distributed systems. Incorporates innovations from modern
solutions to Byzantine fault tolerance.
[Gossip
Protocols](https://secure.wikimedia.org/wikipedia/en/wiki/Gossip_protocol):
Nodes in a network pseudorandomly select peers to exchange information
with. Could be useful for distributing the contents of a DHT-based DNS
implementation within a mesh network.
[Kademlia](https://secure.wikimedia.org/wikipedia/en/wiki/Kademlia) has
an interesting way of handling the entry distribution problem. When
inserting an entry, it iterates through the table to find suitable nodes
in the network to hold that entry and propagates it to them as well as
saving a copy locally.
[CoDoNS
paper](http://conferences.sigcomm.org/sigcomm/2004/papers/p292-ramasubramanian1111.pdf) -
A very good paper from 2004 on a distributed DNS alternative. It still
relies on centralized domain name registration. [CoDoNS main
page](http://www.cs.cornell.edu/people/egs/beehive/codons.php) - It
appears that CoDoNS is operational and running on PlanetLab.
Unfortunately, I don't see any code. I see no reason why we can't simply
hijack their design.
[Tutorial on DNS and
DNSSEC](http://www.surfnet.nl/Documents/DNSSSEC-web.pdf)
[Intentional Naming System](http://nms.lcs.mit.edu/projects/ins/) - "INS
is a new naming system intended for naming and discovering a variety of
resources in future networks of devices and services. It has the
following interesting characteristics about the way it names resources
and the way names are resolved."

49
Old Pages/Byzantium/Byzantium_InterMesh.md Executable file
View File

@@ -0,0 +1,49 @@
The InterMesh is the network of meshes that is separate from the
internet either functionally (bandwidth/latency limitations) or fully
(completely disconnected).
## Services Needed
All these services need to be distributed throughout the InterMesh.
I think we should err on the side of "Secure by default". To make it
easy to grow the mesh we can't really set up encryption at OSI layers 1
and 2 (getting people to configure that in a hurry isn't going to work,
though we might have some luck if we did with [QR
codes](http://skattertech.com/2011/01/quick-tip-use-a-qr-code-to-share-wifi-passwords-with-android/)).
I think any services offered on the mesh should offer SSL/TLS by default
(we'll have to go with self-signed certs).
- captive portal
- to let people know about the services we are providing
- Webmail
- Something that works like
[privacybox.de](https://privacybox.de/index.en.html) would be ideal
in that it's got a short learning curve and a UI that's easy to use
from a smartphone or PDA.
- Twitter equivalent
- [status.net](http://status.net/)
- Common chat networks
- AIM compatible eqiv.
- Gtalk compatible equiv.
- Facebook chat compatible equiv.
- In short, IM-over-HTTPS.
- IRC
- [Mibbit](http://www.mibbit.com/) or something that works like it.
- [CryptoCat](https://crypto.cat/) I think we should get in touch
with the person running this project.
- Collaborative notes
- Mediawiki
- Etherpad
- File uploads
- Image dump ala [Plixi](http://plixi.com/).
- Streaming audio (low priority)
- Yes, I'd plug my police scanner into my computer and stream what I
pick up.
- Voice over IP
- Asterisk
- Configure a conference bridge that people with softphones can talk
on.
- We'll have to test what kind of latency we get with such a setup.
- Voicemail
- Microblog-to-speech using Festival?

304
Old Pages/Byzantium/Byzantium_Live_Distro.md Executable file
View File

@@ -0,0 +1,304 @@
## Description
We are building a portable live Linux distribution based on [Porteus
Linux](http://porteus.org/). Porteus itself is a fork of Slax that has
been brought up to date with Slackware 13.37 and uses a 2.6.38.8 kernel.
Porteus can use binary packages from Slackware 13.37 after conversion to
Porteus' native format.
## Code Repositories
[Github page](https://github.com/Byzantium/Byzantium)
[Subversion repo for Porteus
packages](http://svn.virtadpt.net/byzantium/)
## Goals
- Make it possible for people in emergency situations to communicate and
collaborate.
- Make it possible for people in areas where the communications
infrastructure is compromised to communicate and collaborate.
- Provide services to support communication and collaboration.
- Will be secure out of the box.
- Best practices for isolating running services will be followed.
- Best practices for configuration web applications will be followed.
- Least privilege will be followed wherever possible.
- Will be extensively documented.
- A Creative Commons-licensed book will be made available with the
Byzantium distribution as well as separately
- Will explain the finer points of setting up a mesh, as well as
accompanying projects (such as dialup gateways and long-haul
transports).
- Will be translated into as many languages as possible.
- Widely compatible.
- Users need to be able to boot their desktop/laptop/netbook from
Byzantium media and set up a node.
- As little fiddling with network drivers as possible.
- Rapidly deployable.
- Users need to be able to configure their Byzantium node rapidly and
with little assistance.
- Emergency situations.
- Control panel aims to be as self-documenting as possible.
- Aims to protect confidentiality of traffic.
- Opportunistic IPsec?
- All services default to SSLv3/TLSv1.
- Aims to protect integrity of traffic.
- SSLv3/TLSv1.
- Meshes should grow without the direction of a central authority.
- Anyone can set up a mesh node.
- Anyone can set up services on the mesh.
- Services packaged by default can be managed (activated and
deactivated) from the control panel
- Services packaged by default will come preconfigured with secure
defaults and a mobile-friendly theme where appropriate.
- This is a calculated risk. The threat models of Tor and I2P take
this into account as well.
- Byzantium nodes need to be rapidly clonable.
- One copy of the live distribution needs to become many on demand.
- Nodes need to be clonable without taking the node down.
- Persistent storage has to be an option.
- Built into [Porteus](http://porteus.org).
- save.dat file
- removable media
- media Porteus is installed to
- Dependencies will be automatically managed by the control panel.
## Features
- Can support multiple mesh routing protocols.
- Modular configuration back end.
- Multiple pre-packaged, pre-configured web applications for
communication and collaboration.
- All services can be independently activated and deactivated.
- Aims for security by default.
- Services are not active unless explicitly triggered.
- Services are configured using best practices for security.
- Services support strong cryptography by default.
- Supports gatewaying from the mesh to the Net over a live connection.
- Supports persistent (encrypted) storage on demand (not default).
- Note: When creating a save.dat file under Porteus, if the drive it's
on is formatted FAT-32 or less, the file MUST be \<1024MB, else, the
/linuxrc script that forms the core of the distro will pretend that
it can't locate the file, regardless of where you put it. This drove
me bonkers for two months!
- If possible we should try to make save.dat a second partition on
the thumbdrive (ala casper-rw for ubuntu liveUSBs) there are some
big benefits to this:
- it makes it harder for windows users to see that there is a
second partition in case big brother decides to inspect the
contents of all thumbdrives.
- it means we won't have to worry about file size limits.
### ToDo
- ~~[Node Control Panel](Byzantium_Live_Distro_CP "wikilink")~~ - DONE!
- ~~[Captive Portal](Byzantium_Live_Distro_Captive_Portal "wikilink")~~
-DONE!
- [Provided Services
Announcement](Byzantium_Live_Distro_Service_Announce "wikilink")
- [Wiki](Byzantium_Live_Distro_Wiki "wikilink") - suspended notion
- ~~[Microblog](Byzantium_Live_Distro_Microblog "wikilink")~~ - DONE!
- [File dump/Twitpic
work-alike](Byzantium_Live_Distro_FileDump "wikilink")
- [Voice chat/telephony server](Byzantium_Live_Distro_Tel "wikilink")
- ~~[Clientless web chat](Byzantium_Live_Distro_Chat "wikilink")~~ -
DONE!
- ~~[Blog](Byzantium_Live_Distro_Microblog "wikilink")~~ - see Microblog
- ~~[EtherPad-like thing](Byzantium_Live_Distro_EPad "wikilink")~~ -
DONE!
- [Streaming media
server](Byzantium_Live_Distro_StreamingMediaSrv "wikilink")
- [HTTP caching proxy](Byzantium_Live_Distro_WebProxy "wikilink")
- [Tor](https://www.torproject.org/)
- [IPset](IPset "wikilink")
Pick a web server to host applications:
- Converted the Apache, apr\*, and PHP packages of Slackware v13.37 into
Porteus modules. They Just Worked(tm).
~~We need to figure out how to properly install the control panel app on
a new system. The process should be as pythonic as possible.~~
We need to figure out how to bundle the already configured and populated
MySQL databases for the web apps!
- Packaging them into a module and activating it didn't work.
- ~~Write a script that detects the presence or absence of
/var/lib/db/\*/ and restores them from .sql dumps at boot-time.~~
[The Doctor's to-do list](The_Doctor's_to-do_list "wikilink")
## Packages built for Byzantium
- babeld - For great mesh routing.
- batman-adv - Kernel module which implements mesh routing at OSI
layer 2. We may not use it but it's there if we need it.
- batctl - Utility for configurating and manipulating batman-adv.
- Dependency of batman-adv.
- olsrd - from olsr.org
- ahcpd - For configuring mesh nodes that don't want to use the random
RFC-1918 IP address generator.
- CherryPy - Python module that implements a fast multi-threaded HTTP
(web application) server.
- Without this, there is no control panel.
- pySetupTools - Required for installing some Python modules.
- Mako - Python HTML templating system.
- Dependency of the control panel.
- MarkupSafe - Python library that implements a Unicode string that is
aware of HTML escaping rules and does automatic string escaping.
- Dependency of Mako.
- Git - Converted Slackware v13.37 package.
- Necessary for checking code out and into Github.
- Curl - Converted Slackware v13.37 package.
- Dependency of git.
- Note: To make git work without "error setting certificate verify
locations" errors, you need to run the following command as the root
user: git config --system http.sslcainfo
/usr/share/curl/ca-bundle.crt
- rrdtool - Used by traffic_stats.sh to monitor network traffic and
build graphs.
- sqlitebrowser - Used to develop SQLite database schemas and debug
database access code. Will not be in OS release.
- ~~nginx - Lightweight, fast HTTP(S) server. Much more lightweight than
Apache, at any rate. Custom build for Byzantium.~~
- Enough!
- gd - Dependency of PHP.
- Used for server side image manipulation.
- libmcrypt - Dependency of PHP.
- icu4c - International Components for Unicode. i18n dependency of PHP.
- openldap-client - Dependency of PHP to make it compile. Not pleased by
having to package it, but it won't build without it.
- Can we get away with not having it because I didn't have to compile
it for Apache? Let's try it!
- php - Converted Slackware v13.37 package.
- httpd - Apache v2.2.17. Converted Slackware v13.37 package.
- ..and then stuff started working!
- apr-util - Converted Slackware v13.37 package.
- Utility used for compiling Apache modules.
- apr - Converted Slackware v13.37 package.
- Package used for compiling Apache modules.
- t1lib - Converted Slackware v13.37 package. Used for font
manipulation.
- pcre - Converted Slackware v13.37 package.
- Perl Compatible Regular Expression library.
- Unicode aware for i18n support. status.net requires this for basic
functionality, whcih means that we get i18n for free.
- ~~Firefox v6.0.2~~
- Do not use! i_can_haz_firefox.sh builds a package with bad symlinks.
Haven't bothered to fix it so far.
- node - An event-driven I/O server-side JavaScript environment based on
V8. (from website and wikipedia).
- Required by Etherpad-lite.
- dnsmasq - All-in-one DHCP and caching DNS server.
- Much easier to work with in circumstances like this than ISC BIND or
even djbdns.
- ipcalc - Command-line IP networking calculator. Will be needed by the
control panel shortly.
- Removed the CGI-BIN script from the package when it was built.
- ngircd - Lightweight IRC server.
- Back-end for web chat application.
- Somehow we need to figure out a way to make them automagically hook
together into an IRC network. But that can wait.
- zope.interface - Required by Twisted.
- Twisted - Required by qwebirc.
- Satisfies the clientless web chat requirement.
## Links
Place links relevant to any part of the process of making the live
distro here.
[Porteus Official Website](http://porteus.org/)
[Processes for building Porteus
packages.](Processes_for_building_Porteus_packages. "wikilink")
[Process for manually installing
Byzantium.](Process_for_manually_installing_Byzantium. "wikilink")
[Byzantium 101](Byzantium_101 "wikilink") - How to get yourself set up.
[Hardware compatibility list](Hardware_compatibility_list "wikilink")
[User Feedback on Byzantium
0.1a](User_Feedback_on_Byzantium_0.1a "wikilink")
[Handy generic git notes](Git_Notes "wikilink")
## Timeline
- .....uhh....
- 20 October 2011 - Live demo, presentation, and networking at
[ContactCon](http://contactcon.com/).
- 12 May 2012 @ 1400 EST5EDT: Project Byzantium presentation at
[CarolinaCon](http://carolinacon.org/).
- 13-15 July 2012 @ TBA: Project Byzantium presentation at [HOPE Number
Nine](http://www.hopenumbernine.net/).
## Stuff
~~Need to edit /etc/hosts, add 'byzantium' to 127.0.0.1 so that the web
server will start up.~~
[Mobile devices and IPv6.](Mobile_devices_and_IPv6. "wikilink")
~~[DNSmasq](http://thekelleys.org.uk/dnsmasq/doc.html)~~
- ~~One nice thing about DNSmasq is the -H option, for additional
/etc/hosts-like files. We could use those to cache the IP addresses of
other Byzantium nodes, and then query them for the services they
run.~~
- Hostnames are IPv6 addresses of nodes.
- ifconfig wlan0 \| grep inet6 \| awk '{print \$3}' \| sed 's/:/-/g'
\| sed 's/\\64\$//' \| sed 's/\$/.byzantium.mesh/' ==
fe80--21c-bfff-fe35-84c2.byzantium.mesh
- ~~Put IP addresses and hostnames in /etc/hosts.mesh.~~
- This could also be used for status.net federation and IRC network
construction.
- ~~Move the **server=/byzantium.mesh/...** line into the generated
DNSmasq include file?~~
- ~~Make the '...' the mesh interface's IP address?~~
<!-- -->
- ~~Consulted with an expert about IP addressing. At first scratch, it
might be a good idea to stick wtih pseudo-randomly chosen 10/8's.
Configure the mesh interface for the .1 and give the clients .2-.254.
I'll re-work the control panel to do that.~~
Need to account for [APIPA](http://www.webopedia.com/TERM/A/APIPA.html)
addressing in the initial set of routes.
- ~~Added for the purpose of making networkconfiguration.py [detect
whether or not the proposed IP address for the mesh interface is in
use](http://www.cyberciti.biz/faq/linux-duplicate-address-detection-with-arping/).~~
- Byzantium does this now. It works like a champ.
List of public DNSes that we may wish to fall back upon in the event a
node is made into a gateway:
- [Google Public DNS](https://code.google.com/speed/public-dns/)
- [Public DNS servers](http://www.tech-faq.com/public-dns-servers.html)
- [OpenDNS](https://www.opendns.com/)
[Packaging NPM.](Packaging_NPM. "wikilink")
[Finding neighboring mesh
nodes](Finding_neighboring_mesh_nodes "wikilink")
[Fully distributed services](Fully_distributed_services "wikilink")
## Stuff to consider for later
- Consider adding [Iodine](http://code.kryo.se/iodine/) to Byzantium to
help tunnel gatewayed traffic onto the Net.
- Gateway nodes in hostile areas could use Iodine to tunnel traffic
out.
- Gateway nodes in non-hostile areas could accept Iodine connections
to help less fortunate nodes evade censorship.
- Consider adding (http\|proxy)tunnel with simplified usage of some kind
to allow encapsulating arbitrary data streams in http streams.
- Firewall evasion aids that will work well even in established internet
censorship systems?

17
Old Pages/Byzantium/Byzantium_Live_Distro_CP.md Executable file
View File

@@ -0,0 +1,17 @@
## Description
[Browse source
code](https://github.com/Sitwon/Byzantium/tree/master/control_panel).
## Features
## ToDo
- Modify startup code to:
- Read configuration databases
- Test each existing entry against the current hardware configuration
- If they match, start it up using the stored settings
- If they don't, delete that stored setting
- Start up system services that are configured and active.
- Modify the /index.html template to not show a sitrep but the current
configuration from the databases

17
Old Pages/Byzantium/Byzantium_Live_Distro_Captive_Portal.md Executable file
View File

@@ -0,0 +1,17 @@
## Description
Catch the first DNS request from a node or client and redirect them to a
page which will inform them of Byzantium's capabilities or lack thereof.
## Suggestions
- dnsmasq+custom scripts
- Have DNSmasq running, config file generated by control panel.
- Basic DNS hijacking possible (right now, intercepts www.google.com
and encrypted.google.com)
- When the captive portal is working we won't need to do this.
- [WiFiDoc](http://dev.wifidog.org/)
- [NoCatSplash](http://nocat.net/)
- [Captive::Portal](http://search.cpan.org/~gaissmai/Captive-Portal/)
- [Captive::Portal notes](Captive::Portal_notes "wikilink")
- [Dependencies](Dependencies "wikilink")

14
Old Pages/Byzantium/Byzantium_Live_Distro_Chat.md Executable file
View File

@@ -0,0 +1,14 @@
## Options
[crypto.cat](https://crypto.cat) - requires a preshared key for
encrypted sessions but is otherwise robust out of the box [akiscode
p2pchat](http://akiscode.com/projects/p2pchat/) - needs work but could
be made into a webchat and is written in python.
## Ideal Chat Client
- has the ability to do asymetric encryption
- has the ability to work without a server (maybe unrealistic but it
would be nice)
- if servers are required they can federate with other servers
- is easy to for end users to use

3
Old Pages/Byzantium/Byzantium_Live_Distro_EPad.md Executable file
View File

@@ -0,0 +1,3 @@
## Suggestions
- etherpad-lite

42
Old Pages/Byzantium/Byzantium_Live_Distro_FileDump.md Executable file
View File

@@ -0,0 +1,42 @@
Photoblog/Image Dump Essentially, a [Twitpic](http://twitpic.com)
work-alike for the Byzantium mesh.
- [Pixelpost](http://www.pixelpost.org/)
- Blog optimized for photoblogging.
- Requires MySQL.
- Requires PHP.
- Needs to be configured so that anyone can log in and post images
(guest/guest?)
- EXIF information needs to stay turned off.
- Look into writing a utility which strips EXIF information fromm all
images uploaded.
- Make the "Remove EXIF" function permanant?
<!-- -->
- [Plogger](http://www.plogger.org/)
- Dedicated online photo gallery.
- Requires MySQL.
- Requires PHP.
- Requires GD.
- Defaults to the first album, first collection if there is nothing
else.
- Need a mobile theme. Develop one?
- Has i18n support already.
- Can take descriptions.
- Needs to be configured so that anyone can log in and post images
(guest/guest?)
File dump
- [Simple File Exchange](https://github.com/TlhanGhun/SiFiEx)
- Requires PHP.
<!-- -->
- [Forban](http://www.foo.be/forban/)
- Python app.
- Simple peer-to-peer file sharing application.
- Implements HTTP.
- Opportunistic file sharing.
- Written in Python.

16
Old Pages/Byzantium/Byzantium_Live_Distro_Microblog.md Executable file
View File

@@ -0,0 +1,16 @@
Working on status.net for now. [status.net](http://status.net) isn't
quite what we need and it is much to complex (says haxwithaxe)
recommend we write our own dead simple one with the following features:
- completely anonymous posting (security via the lack thereof :P)
- distributed couchdb-like database backend
- the future ability to sign messages with pgp keys
For the time being, let's set it up. We can code something else later,
but I need *something* to demo (and turn testers loose on). I'll see if
status.net can use SQLite as its back end. Supposedly [the Google Summer
of
Code](http://status.net/wiki/Google_Summer_of_Code_2011#RDBMS_backend)
was supposed to do this in 2011, but I don't know if it actually
happened.

84
Old Pages/Byzantium/Byzantium_Live_Distro_Prerelease.md Executable file
View File

@@ -0,0 +1,84 @@
## Prerelease Process
**DRAFT** On this page we have a list of things that need to happen
between the **final** build and the publishing of software or
repackaging thereof by the Byzantium Project. Unless otherwise stated
all items are required to be satisfied for an individual build before
being placed in another part of the project or before publishing the
project.
### Build Environment
- manifest check - make sure what you think is there is actually there.
manifest files (with name <scope>.manifest) are recommended, and will
be checked by the build environment once that is automated.
- Add a stanza to the Makefile (if we go that way, that is) - **make
manifest** or **make test** or something like that.
- ?other sanity checks?
### Runtime Environment
- for each package/major feature set a checklist must be made that will
reasonably ensure the software is behaving as expected.
- A list of packages that comprise 000-byzantium.xzm should be
maintained someplace. Right now we're just eyeballing it.
- A list of files associated with each package should be maintained
someplace.
- This is why I build Slackware packages (where feasible) or do a
**DEST=/tmp/SBo make install** where there aren't any followed by a
**dir2xzm /tmp/package.xzm /tmp/SBo** - to keep all of the files for
a particular package grouped together.
- A bunch of .xzm packages are easier to keep track of than compiling
stuff in sequence. Then, when it comes time to build everything the
build system can check them out of SVN and use **xzm2dir** to unpack
all of them in sequence into a fakeroot. So, I propose a two step QA
sequence:
- Make sure that some_package-rev.isi.on.xzm was compiled and
checked into SVN.
- Make sure that some_package-rev.isi.on.xzm was checked out of SVN
on the build machine and **xzm2dir**ed into /tmp/fakeroot.
- the checklist can (and is recommended to) just say to run a script
that will do the required tests and return a pass/fail status.
- if a script is used for runtime QA it should be named "runtimeQA.sh"
and have 777 (a+rwx) permissions in the root directory of it's scope
(eg for a package
"byzantium-repo/packages/thispackagedir/runtimeQA.sh"). Also it
should use paths with the expectation that the script will be run
from an arbitrary directory.
### Human Environment
- 2 day cool down period between building and publishing
- No .iso image goes out without being PGP signed against key
0xD6975C17.
- While we're at it, can we get some more signatures on that key?
- Fingerprint 93F3 8B13 B52C D8F0 FA8D 03B3 37AA 847C D697 5C17
- I've uploaded it to a bunch of keyservers around the Net.
- The person who builds the .iso image is not the one who checks the
contents of the .iso image. After you've been staring at the same
thing for long enough, it all starts looking alike.
- Does the bootloader have the right porteus.cfg?
- Does the bootloader have byzantium.jpg handy?
- Does porteus/modules/000-byzantium.xzm exist?
- Do these files exist in the root directory of the .iso image?
- README.txt
- README.NOW
- FAQ.txt
- packages.txt
- CHANGELOG
- Do all of the Porteus modules exist in porteus/base?
- 000-kernel.xzm
- 001-core.xzm
- 002-xorg.xzm
- 003-lxde.xzm
- 004-kde.xzm
- 005-kdeapps.xzm
- 006-koffice.xzm
- Do we really need to include this?
- 007-devel.xzm
- 008-firefox.xzm
- No .iso goes out without being tested, i.e., at least booted in a VM
and put through its paces.
- We need a process for loading the mirrors from a single distribution
point.
- Torrents are seeded prior to announcement.

29
Old Pages/Byzantium/Byzantium_Live_Distro_Service_Announce.md Executable file
View File

@@ -0,0 +1,29 @@
## Description
Share services running on a network with clients and other supernodes.
Each mesh node maintains a list of all of the services and web apps it's
running. That list is used to populate the service directory page of
each node. The trick lies in telling the other mesh nodes what you
happen to be running and what IP address it is. This is where being able
to announce what services you run to other mesh nodes will come into
play. We are using dns-sd via mdns/avahi/bonjour to announce services.
The "__byz__._tcp" service type is being used to distribute
services started by byzantium.
This is simplified somewhat by the fact that the mesh nodes' network IP
addresses are all 192.168/16.
## Suggestions
### Contents
- see dns-sd spec
### Method
- dns-sd via mdns/bonjour/avahi
### Format
- see dns-sd spec

3
Old Pages/Byzantium/Byzantium_Live_Distro_StreamingMediaSrv.md Executable file
View File

@@ -0,0 +1,3 @@
## Suggestions
- [icecast](http://icecast.org)

4
Old Pages/Byzantium/Byzantium_Live_Distro_Tel.md Executable file
View File

@@ -0,0 +1,4 @@
## Sugestions
- Mumble/Murmur
- Asterix

8
Old Pages/Byzantium/Byzantium_Live_Distro_WebProxy.md Executable file
View File

@@ -0,0 +1,8 @@
## Suggestions
- Squidproxy
- (i'm just pulling names out of my ass on this one - haxwithaxe)
- Squid's got potential. We might also want to consider something like
polipo because it'll do the same thing, plus filtering out junk to a
certain extent, plus it's a lot more lightweight than Squid is.
--The Doctor

6
Old Pages/Byzantium/Byzantium_Live_Distro_Wiki.md Executable file
View File

@@ -0,0 +1,6 @@
There was a discussion on the mailing list over whether or not it would
be worth putting a wiki on a Byzantium node. Seeing as how our use cases
involve mobile devices, it might not be worth including them because
they're not easy to edit from smartphones or MP3 players. It's easy to
browse a wiki with a good mobile skin, but not so easy to edit text.
Thus, I think we're tabling the notion until later.

43
Old Pages/Byzantium/Byzantium_Sprint_1.md Executable file
View File

@@ -0,0 +1,43 @@
Goal - Reliably bridge two different and separate wireless networks
without using existing internet infrastructure.
Design goals 1) There should be a webserver on each network providing a
service of some kind (microblogs, web chat, file dump). 2) Nodes in
either network should be able to reach both webservers. 3) Nodes on one
network should be able to talk to nodes on the other network and vice
versa. 4) Networks should have at least 3-5 nodes each.
Tentative schedule is as follows:
Friday - 8:00pm Pizza and planning (any particular request should email
me off list). (COMPLETE!) Saturday - 9:00am Start showing up (IN
PROGRESS!) Saturday - 10:00am Divide into groups and start the sprint.
Sunday - 10:00am Start showing up. Sunday - 11:00am Finish the sprint!
Sunday - Evening Debriefing (I'll be taking extensive notes to update
the wiki).
Notes:
- [BATMAN](BATMAN "wikilink")
- [BATMAN-Advanced Setup](BATMAN-Advanced_Setup "wikilink")
- [Babel](Babel "wikilink")
- [Babel Setup](Babel_Setup "wikilink")
Plans! We're gonna have two teams each will implement a mesh network
using some existing mesh protocol. One team will be working with
BATMAN-Advanced and the other with BABEL. Each network will use at least
one openwrt device the rest will be laptops and netbooks.
from Wikipedia:
[Byzantine](http://en.wikipedia.org/wiki/Byzantine_fault_tolerance#Origin)
[From p2pfoundation.net](http://p2pfoundation.net/Mesh_Networks)
Interesting threads: [A few comments on the BATMAN routing
protocol](http://lists.alioth.debian.org/pipermail/babel-users/2008-August/000151.html)
[A few more comments on the BATMAN routing
protocol](http://lists.alioth.debian.org/pipermail/babel-users/2008-August/000156.html)
[Tweaking BATMAN-adv](http://www.open-mesh.org/wiki/batman-adv/Tweaking)
### Distributed DNS
see [this](Byzantium_Distributed_DNS "wikilink")

158
Old Pages/Byzantium/Byzantium_Sprint_2.md Executable file
View File

@@ -0,0 +1,158 @@
Summary: Build at least one long-haul link to bridge two meshes.
Planning meeting: Thu Mar 3 2011 after the bike maintenance class (done)
Planning meeting \#2: Wed Mar 16 2011 after the elements of computing
class (doneish)
**Sprint Date: Fri-Sun March 25-27**
[Inventory](Byzantium_Sprint_2_Inventory "wikilink")
### Schedule
FRI: 8:00pm Pizza, sprint 1 recap, and prep (mostly ripping thing apart
and some assembly) SAT:
- Noon Brunch and final assembly followed by bench tests and midrange
tests depending on speed of success
- Dinner Time: Dinner outside the space. This must occur outside the
space.
- 9:00pmish? Discussion and general planning for Sunday optionally
followed by more testing/making
SUN:
- Noon Brunch prep for long distance tests followed by long distance
tests
- Dinner Time: Dinner outside the space. This must occur outside the
space.
- 9:00pmish? Discussion and planning for the next sprint
### Stuff to bring (proposed)
- FMRS/GMRS radios that you wouldn't mind hacking.
- Childrens' walkie-talkies. [User:Drwho](User:Drwho "wikilink") knows
where to buy cheap pairs of them locally.
- Webcams *that are known to work with Linux*. That's closer to black
magick than computer science, so do your homework first (or on your
smartphone while at the store). The feature to look for is called
[UVC](http://en.wikipedia.org/wiki/USB_video_device_class) though
webcam boxes still might not mention it.
- Laser pointers (the more exotic the colors the better). Buy them when
you find them. When you go looking for them you can never find them.
- Really bright LEDs
- Photocells, photoresistors, photodetectors.
- Microcontrollers. They may come in handy for modulating/demodulating
signals.
- Hackable wireless access points. Here are some
[examples](http://www.newegg.com/Product/ProductList.aspx?Submit=ENE&DEPA=0&Order=BESTMATCH&Description=dd+wrt)
that might work.
- old headphones/headsets/stereo audio cables and phone cords for
cutting up and making into modem to radio connectors
### Radio
- radio shack/hardware store high bandwidth unlicensed spectrum
- Hacked FRS/GMRS radios
- [Text messages over
walkie-talkies.](http://takethingsapart.blogspot.com/2010/07/note-before-constructing-device-such-as.html)
- [Forum post with some
ideas.](http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1270645507)
- Pros:
- cheap
- longish range (35mi allegedly)
- Cons:
- Need an automated PTT switch or two radios per node
- Develop improvised antennae to improve signal quality, distance
covered.
- anything + aluminium foil = bouncy bouncy for radio waves
The FCC has designated a number of channels in the 27 MHz band that can
be used for signaling and radio control. They are unnumbered and
in-between CB channels 1-13
([source](http://forum.servomagazine.com/viewtopic.php?f=1&t=2736))
### Optical
- Modified Ronja-like
- with lasers
- with balloon targets
- with lasers and balloon targets
- with lasers and self-adhesive mirrored decals.
- All Electronics Magazine had a couple of articles on building
lasercomm devices on the cheap. Somebody remind the Doctor to go
through his magazine collection.
- [How to make a simple laser
communicator.](http://www.make-digital.com/make/vol16/?pg=69#pg69) (I
do have this issue. Have bought parts to build a pair of transceivers.
--The Doctor)
- [Handbook of Optical Through-the-Air
Communications](http://www.imagineeringezine.com/files/air-bk2.html)
is a good read on the basics of an LED-based hardware setup, though
he's aiming at voice comms. (Elliot)
### Inspiration
- [Ronja](Ronja "wikilink")
### Homework
- read up on [Ronja](http://ronja.twibright.com/)
- read up on FMRS/GMRS
- read up on and talk to the HacDC Spaceblimp team about soundcard
modems: like [this](http://www.baycom.org/~tom/ham/soundmodem/) (also
available via apt [like so](Notes_on_Soundmodem "wikilink"))
- [Howto](http://www.linux-ax25.org/wiki/Soundmodem)(go here last it's
a bit short on soundmodem specific info)
- [Notes on Soundmodem](Notes_on_Soundmodem "wikilink")
- [Soundmodem in the
field.](http://www.qbjnet.com/packet.html#soundmodem)
- Read up on [AX.25](AX.25 "wikilink").
### Goals (proposed)
- Optimize for hackability. Could your average geek build a few of these
using junk around zir house and deploy them in an emergency situation?
- not a chance
- Determine the optimum speed in bits per second for a mesh-to-mesh
link.
- very crazy slow (we didn't bother measuring it was so slow)
- Measure the bandwidth of a point-to-point long haul connection at a
particular distance.
- again to slow to bother
- Determine the maximum practical distance for a long haul connection
between two meshes in an urban environment.
- didn't get that far
- Mathematically describe the way to maximize throughput with a minimum
number of nodes.
- didn't get that far
- Run an ssh session over whatever link is established.
- done
- Interact with a web page over whatever link is established.
- connection was too unstable to get this far
- Develop methods to minimize latency.
- tweak the source and transmitter volume A LOT until the it's perfect
- Determine the efficiency of the mesh routing protocol we settle on.
- didn't get this far
- How many active nodes per mesh can be reasonably supported before
connectivity breaks down?
- to be determined
### Apps running on Windbringer (laptop/node) to prove functionality
- [status.net v0.9.6](http://status.net/open-source)
- [Mediawiki](http://www.mediawiki.org/wiki/MediaWiki)
### Lessons Learned
- "how hard can it be" ... oops :(
- very. soundmodem is finicky and creates unstable connections 20%
packet loss at best 80-90% avg.
- Don't forget network latency of 35,500ms over a distance of eight
feet.
- "What could possibly go wrong?" ... oops :(
- everything
- [There are no experimental failures. There is only more
data.](http://drwho.virtadpt.net/archive/2011/04/14/project-byzantium-development-sprint-2)
Let's see how much of [Project FabFi](http://fabfi.fablab.af/) we can
make use of!

98
Old Pages/Byzantium/Byzantium_Sprint_2_Inventory.md Executable file
View File

@@ -0,0 +1,98 @@
Add the crap you have to this list even if someone else says they have
the same stuff.
Also, keep in mind that having spares around would be handy in case we
fry some stuff.
## haxwithaxe (chris)
- openwrt compatable routers....10
- FRS/GMRS handsets....2
- laser pointers....1
- webcams(in laptops)....2
- usb webcams....1(non hackable :( )
- microcontrollers....5
- teensy 2.0
- teensy++ 2.0
- mbed
- 2 jeenode v4
- photoresistor....(will buy \$20 worth before planing meeting \#2 ...
radioshack is cheaper than digikey ... who'da thunk)
- Things are weird like that these days.
- 7805....(will buy \$20 worth before planning meeting \#2 ... again ...
wtf radioshack is cheaper)
- Cheaper but more scarce. Buy them online, you'll have a better
chance of getting them, plus it saves on gas.
## The Doctor
- Wireless routers: 2
- FRS/GMRS handsets: three pairs
- Uniden GMR1235-2: one pair
- No headphone or mic jacks.
- Will have to drill into case and patch directly onto PCB.
- Will have to build a push-to-talk circuit, though we might be able
to get away with using two per node (one sending, one receiving,
on different channels).
- Audiovox GMRS602: three (one is still MIA, I think ITechGeek has it)
- [Manual](http://audiovox2.info/docs/common/GMRS602CH/GMRS602CH_OM.pdf)
- Has vox support.
- Has a combination headphone/mic jack.
- No hardware modifications will be required.
- Simplex operation.
- Supports CTCSS subcodes to multiplex channels.
- Plug pinout (held with the tip downward)
- Center: base of plug : common
- Left: middle of plug : phono
- Right: tip of plug : mic
- Walkie-talkies: 2, could get another pair, they're cheap
- Each uses a 9V battery
- Laser pointers: 4
- See Make Magazine \#16, Spy lasercomm device.
- Simple design.
- Exposed power leads by chopping up casings last night.
- Two work well, one is kind of dodgy, one appears to be DOA.
- Taped buttons down.
- Taped stacks of coin cells together.
- Spring is negative, inside of shell is positive.
- Assorted LEDs: 20
- Webcams (USB): 1
- Microcontrollers: 1 Arduino Diecimiela
- Photocells: need to order
- Photoresistors: Seven, need to order more
- Modems: 2
- TinyTrak 4 (used with Project Spaceblimp)
- Radio Shack HTX-200 HT
- Uniden BC92XLT scanner
- Encapsulated solar cells, 66mm x 95mm x 6mm
- Pre-wired, with exposed holes for probes as well.
- 0.5V @ 800mA: 1
- Didn't generate an appreciable amount of current last night.
- Physically larger than the other one.
- Might be unsuitable for use as a detector.
- 1.0V @ 200mA: 1
- Generates a decent amount of current.
- Reacted to room lighting and flashlight in the 'space last night.
- Might make a good optical sensor.
- High intensity white light LED flashlights (miniature): 2
- I've had this model open and played around with them a bit, they're
just high-intensity white light LEDs that run on 3VDC. We'll have
more trouble opening the casings than putting them to use.
- 1/8" monoaural phono plugs: 4
- Useful for plugging into laptops.
- 1/8" stereo phono plugs: 4
- Useful for plugging into radios.
- 14" jumper leads, with alligator clips on both ends: 10
- Audio output transformers, 1K ohms in, 8K ohms out (RS 273-1380): 4
- Assorted resistors, carbon film type, 1/4 watt, 5% tolerance: 500
- Note: this was the only way I could find the resistors needed to
build the lasercomm device. Fraggin' Radio Shack...
- Ultra-high brightness red LEDs, 10mm diameter: 4
- 7805 voltage regulator, 5 VDC, 1A: 3
- Assorted cadmium sulfide photocells (RS 276-1657): 5
- assorted rubber bands to hold transmit buttons down
- assorted six inch lengths of heatshrink tubing to protect wiring
splices, bundle coin cells into ad-hoc power packs
- batteries for hand-helds
- 741 op amp, mini DIP formfactor, 8 pins: 4
- could use these to build amplifiers

43
Old Pages/Byzantium/Byzantium_Sprint_3.md Executable file
View File

@@ -0,0 +1,43 @@
**Sprint Dates: Fri 29 April 2011 - Sun 1 May 2011**
## Goals
- Revisit sprint 1
- Gather metrics to determine efficiency of protocols.
- Sizes of routing protocols' packets.
- Number of packets per second/minute/hour transmitted by each
protocol.
- Average amount of traffic during normal operation.
- Determine how many nodes can participate in a mesh before
responsiveness or bandwidth begin to degrade.
## Stuff To Bring
- anything that can run babel
- laptops/netbooks
- desktops with wireless cards
- openwrt compatible routers (if you're feeling lucky/adventurous)
## Homework
- install babeld on every machine you plan to bring to the sprint
- \[optional\] install a kernel with support for batman-adv on the same
machines (it's built into the kernel after version 2.6.38+ ) or build
the modules separate from the kernel
- readup on route and ip/ifconfig commands in linux
- readup on ipv6
## Experiments
- network density
- hypothesis: if the nodes are positioned very densely, then the
network quality will degrade.
- test: position nodes at increasing densities starting with evenly
distributed nodes at their maximum effective range, and run tests to
measure network quality at each level of density.
## Suggestions
- Babeld install guide
- LiveCD guide
- Twitter hashtag \#hacbyz ??

33
Old Pages/Byzantium/Byzantium_Sprint_4.md Executable file
View File

@@ -0,0 +1,33 @@
possible projects:
- Revisit sprint 2 with different methods.
- Cantenna?
- Dialup?
- Pretty easy to test at HacDC by cross-connecting two modems and
dialing between them.
- CAT-5e or CAT-6 throws (thanks to John Gillmore)?
- Bluetooth?
- web replacement (for inside the mesh)
- Can already set up web servers on the mesh and deploy web apps.
- distributed status.net (is it already? - Yes through OStatus
<http://ostatus.org/> )
- Have a copy of status.net running on a mesh node right now.
- [Tahrir](https://github.com/sanity/tahrir/wiki)
- [rstat.us](http://rstat.us/)
- webmail
- May we should look into something that works like
[privacybox.de](https://privacybox.de/).
- chat proxies/interceptors?
- aim
- facebook
- gtalk (not really any work needed here)
- Could probably do it with an XMPP server and a web front-end.
- Asterisk server with web front and a couple of confs configured?
<!-- -->
- New project - something different.
- [OLSR](http://www.olsr.org/)?
E-mail your vote to byzantium \[at\] hacdc \[dot\] org with the subject
"Sprint 4 Topic".