When the php-....tgz file is created, it should include the Byzantium/porteus/php/etc/httpd/php.ini configuration file rather than the basic php.ini file from the PHP tarball.

Device a way in which encryption (WEP/WPA) can be configured on wireless network interfaces that will be used as mesh gateways.

As things stand now, wicd (already enabled in Porteus Linux) is content to set up a network interface and then get out of our way, so I think this will be easy. It might make more sense to assume that the user has already configured the gateway interface somehow (Ethernet is configured automatically via DHCP using ifplugd, why not make the same assumption for wireless?) and we're just turning gateway mode on by re-running babeld with an extra interface and a -C option to propagate the route. Once that's done the NAT rules can be applied.

NameError: global name 'error' is not defined

/home/guest/Byzantium/control_panel/services.py, line 227

I've been told that making the system stats page (object Status()) the default page for the control panel rather than something a bit more helpful to the user (like setting the language for the 'panel) isn't a good UI design. Rework control_panel.py so that something other than Status() is used as the root object.

The source code of the control panel (written in Python and using CherryPy) needs to be audited for security vulnerabilities (including HTML vulnerabilities!). I'm not a webapp.sec guru and I would really like people who are more knowledgable of such things to go through the control panel and double-check my work. I've tried to trust as little input as I could (preferring input from the OS over user input) but that's nothing compared to somebody who knows this stuff better than I putting it under the microscope.

The customized dnsmasq.conf file in Byzantium/porteus/dnsmasq needs to be put in the final .tgz package.

Not-amateur HTML for the control panel is in the works but hasn't been comitted yet. After it's committed, the HTML for the gateway configuration sub-app needs to be fixed up so it looks the same.

In meshconfiguration.py, modify the code that enumerates meshed network interfaces and instead of omitting them from the list passed to the HTML template, make it so that those interfaces can be removed from the mesh (by re-running babeld without the interface in question and them marking the interface as 'unconfigured' in the network.sqlite database). The place to start is in the MeshConfiguration.index() method, and then another method and HTML template will have to be added.

cmake is not installed by default. Details to follow.

In use cases like the Egypt Problem, it is likely that a Byzantium node, if seized, could be analyzed to gather information about currently associated users. Thus, it would be prudent (after the alpha release) to configure the system and as many apps as feasible to either log nothing (best case) or log directly to /dev/null (worst case).

It would also help prevent nodes from running out of disk space (and RAM, in the case of liveboot-only nodes).

syslogd should be disabled. Apache should be configured to log nothing. MySQL error logging should be turned off. Etherpad-Lite should log nothing. The IRC server should be confirmed to log nothing; logging of qwebirc should be disabled as well).

The openjpeg part of the Porteus meta-package mupdf won't compile unless cmake is installed. Error message:

[successful compilation of libjbig omitted...]
[decompression of openjpeg tarball omitted...]
patching file jp3d/libjp3dvm/CMakeLists.txt
patching file libopenjpeg/CMakeLists.txt
openjpeg.SlackBuild: line 76: cmake: command not found
make[1]: *** [../pkgs/openjpeg-1.4-i486-2_SBo.tgz] Error 127
make[1]: Leaving directory `/home/guest/Byzantium/porteus/mupdf/src'
make: *** [pkgs/openjpeg-1.4-i486-2_SBo.tgz] Error 2

We need a Porteus package for cmake. At least we won't have to include it in the final distribution, we just need it as a compilation tool.

In MeshConfiguration.enable() split the code that grabs the PID of babeld into a separate method. In the long run it'll make the code easier to maintain, as well as making it easier for us to switch to a different mesh routing protocol if we decide to do so in the future.

Could somebody pick up development of the gateway configuration sub-app (gateways.py)? I just realized that I might know more about the manual installation process at this point, and should spend time documenting that so that the .iso build process can be finished. I've based the code off of networkconfiguration.py and I'm re-using some of the HTML templates as the user interface.

I have design notes that I can add to this ticket for whomever wants to pick it up.

Please? Anybody?

Trying to build the Erlang Porteus module fails with the following error:

• export 'http://www.erlang.org/download/otp_doc_man_R14B02.tar.gz"'
  ../../build.sh: line 8: export: `http://www.erlang.org/download/otp_doc_man_R14B02.tar.gz"': not a valid identifier
  make: *** [../pkgs/erlang-otp-14B02-i486-1_SBo.tgz] Error 1

When toggling a web application, the text on the /services/webapp.html template needs to be made consistent with the action selected by the user. For example:

"You have chosen to deactivate the microblog web application.
This will deactivate the application! Are you sure you want to do this?
Click the "deactivate" button to turn it on or the "Cancel" button to abort!"

The highlighted bit should be supplied by the Services.toggle_webapp() method and not be hardcoded to 'on'.

please ignore this as well

Compilation of the Tor Porteus package fails like the others have due to the for.. loop in build.sh. Here's the error message:

...
../../build.sh: line 8: export: #': not a valid identifier make[1]: *** [../pkgs/tor-0.2.2.32-i486-1_SBo.tgz] Error 1 make[1]: Leaving directory/home/guest/Byzantium/porteus/tor/src'
make: *** [pkgs/tor-0.2.2.32-i486-1_SBo.tgz] Error 2

I had to tweak the build files a little bit to pull v0.2.2.33 rather than .32 because the latter isn't available at distfiles.gentoo.org anymore. The script dies in a different way:

./tor.SlackBuild: line 99: LD_LIBRARY_PATH: unbound variable

Compilation of libevent succeeds, though.

dnsmasq is capable of performing a DNS hijack on certain IP addresses to redirect traffic elsewhere. In this case, traffic destined for certain popular websites (such as Google, Facebook, and Twitter) should be redirected to the node's frontpage (https://nodename.byzantium.mesh/) to inform the user that a) they are on a mesh, b) proper operational security measures should be taken, and c) they have to click through to acknowledge this fact. This is done with the address= directive in dnsmasq.conf, and looks like this:

 address=/www.google.com/10.x.y.1

Due to the fact that the IP address to redirect to has to be specified, we can't set this up ahead of time. It'll have to be configured at the same time that the dnsmasq.conf.include file is created by the control panel. This will be pretty easy to do as it will only involve the addition of a couple of writes to the .include file.

So far, www.google.com, encrypted.google.com, twitter.com, and facebook.com are on the list. Any others we should hijack?

Add functionality to the Gateways() object to configure a gateway node to redirect all of the traffic destined for the uplink through a running Tor (https://torproject.org/) daemon in client mode. This can be done with IPtables (and is by at least one live distro - TAILS).

Tor could be configured out of the box as a client and could be manipulated by the user with TORK or Vidalia. When Tor is running successfully the option will be made available to the user to run all gatewayed traffic over Tor.

The Tor Project has instructions for doing this here (https://trac.torproject.org/projects/tor/wiki/doc/TransparentProxy) that we could turn into an init-style script.

In the HTML generated by the Services.index() method, each service has two buttons associated with it - a non-clickable button that shows the name of the service and its status (green for running, red for not-running), and a clickable button that toggles the state of the service (running or not). The services' toggles are colored appropriately (green for 'start', red for 'stop') but the label on the button is the same as the name of the service (due to how forms pass information to the next HTML page). Those labels need to be changed to 'start' or 'stop' as appropriate rather than the name of the service.

sorry just a test ignore this

Make the default homepage for Firefox http://localhost:8080/ (the control panel's HTTP port).

Put a link to the control panel in /home/guest/Desktop that
a) opens in Firefox.
b) opens the control panel.

Firefox Preferences -> Privacy
Firefox will never remember history

The APR package will not compile properly unless doxygen is installed beforehand. I went through the online help in the configure script and there doesn't seem to be a --switch to disable doxygen checks. We need a doxygen Porteus package as a dependency.

In Gateways.activate() add a routine that parses the currently installed iptables ruleset to ensure that NAT rules don't exist already. There is no sense in adding and re-adding rules if one set will do. This will also help avoid functional conflicts.

Parse output of iptables -t nat -n -L | grep MASQUERADE

The problem with some of the services we package is that their initscripts aren't consistent in some ways (if they have initscripts in the first place). The first problem is that they don't always support the 'status' argument to determine if a service is running. If a service is running, it should print 'running' or 'deactivated' to STDOUT where it can be captured by the control panel and parsed.

Additionally, not all services write PID files to /var/run, which causes problems when it comes to testing to make sure that services actually did come up when started from the control panel.

To verify that a service is running, the control panel takes the contents of /var/run/[servicename].pid and checks in /proc to see if a matching directory exists. If there isn't a match then it's assumed that the service didn't start up and so displays an error message to the user. if there is a match then it's assumed that the service is running, and it's flagged in the services.sqlite database as such so that it will be displayed on the node's frontpage (the "Things I support" page).

If you're writing an initscript, please ensure that you add a 'status' function to it, and also make sure that you capture the PID of the running process to /var/run/[servicename].pid, either in the initscript itself or in the configuration of the service.

Take the filenames of initscripts (rc.foo) out of the services.sqlite database and put them into a configuration file to make them easier to manage?

Pros? Cons? Non-issues?

In NetworkConfiguration.make_hosts() add code to detect error conditions in which /etc/hosts.mesh could not be created and display an error to the user. The event in which the file could not be created is already handled by moving the old /etc/hosts.mesh file back into position but the user should be made aware of the problem.

The exact error message is "configure: error: Can't enable gnutls". When I built the existing package by hand I had to pass the switch --disable-gnutls to ./configure for the build to go through.

The babeld package needs to include the etc/babeld.conf file checked into git.

Also, why does it compile ahcpd at the same time? We're not using it.

Before Byzantium Linux goes beta, we need at least one person to stomp through the file system and do due dilligence insofar as the security posture of the default install is concerned. Where possible, things need to run with the least privilege they can get away with. The contents of /sbin and /usr/sbin should probably be set o-rwx. Everything with a set[gu]id bit that the unprivileged user doesn't normally run should be set mode 0750. In short, somebody has to go through the usual list of best practices lists and apply them to a running instance.

It would probably be a good idea to write a shell or Perl script to do the hardening for us, if only to speed up the process and make it less likely that something will be forgotten. We'll have to integrate this into the package build process as well because it's more than just the base OS that should be audited.

In meshconfiguration.py, modify the code that enumerates network interfaces and adds them to the network.sqlite database to detect when network interfaces have gone away (been unplugged or came loose from the system) and removes them from the database. This will help keep the configuration databases clean and free of potentially conflicting entries.

The network configuration application of the control panel never actually puts any wireless interfaces into ad-hoc mode. If you run iwconfig on a wireless NIC, it shows that it's stil in managed mode. This breaks mesh networking completely. Oops.

It failed in the same way that the Erlang package did. The for.. loop in build.sh blows up the build, but if I go through the steps in that script one by one and just source the apr.info file, the compile proceeds normally. The compile also dies because doxygen isn't installed, but that's a separate issue.

A Slackbuild script exists for building a node.js .tgz file. It is then trivial to convert that .tgz file into an .xzm file for use with Porteus. This has already been done.

Unfortunately, NPM (node.js package manager) is not so easy to package. Rather than using a more pedestrian packaging technique, installation of NPM involves downloading and running an install.sh script which then downloads the NPM source code tarball, does a bunch of stuff to it, and then installs it in as opaque a manner as possible which makes the creation of a .SlackBuild script difficult to say the least. We need to figure out how to write a .SlackBuild script that will generate a .tgz Slackware package, and then turn that into a Porteus .xzm file.

I think a good place to start would be reading through the Arch Linux PKGBUILD script for NPM (https://aur.archlinux.org/packages/no/nodejs-npm/PKGBUILD) because it documents how the AUR goes about building a package canonical to Arch, and then use their procedure to create a .SlackBuild. Someone's already done the heavy lifting for us.

Because Byzantium is designed with more than just English speakers in mind, we need to start figuring out how to internationalize the control panel.

Ideally, when the user opens the control panel in a web browser, they are presented with a set of flags that correspond to language packs for the text of the control panel's pages. The user clicks on one of the flags and that sets the set of text strings that are used for the output to the user.

There is a tool called babel (http://babel.edgewall.org/) - unrelated to the mesh routing daemon - which can be used to internationalize Python applications. We may wish to investigate this tool. We will also need to co-ordinate with Laurelindel, who is working on the HTML for the control panel.

Assuming a node that uses persistent storage, modify control_panel.py to detect whether or not the system has been configured in the past, and if so walk through the configuration process to restore it to its previous condition (i.e., running services, network interfaces, and gateway status).

Issue notes to come that discuss discrete engineering issues involved in this.

Permission denied, because /etc/rc.d/rc.sshd is not +x.

add dnssec capabilities for internet connected nodes. this should wait until 2.0 unless we have an opportunity to get it going before then.

Some wireless devices do not error out if they do not recieve configuration information from a DHCP server and instead configure themselves using APIPA (http://compnetworking.about.com/cs/protocolsdhcp/g/bldef_apipa.htm). Add a virtual interface :2 to all mesh interfaces automatically that is configured with an IP address and route within the APIPA netblock (169.254/16) for these devices.

I've been told that making the system stats page (object Status()) the default page for the control panel rather than something a bit more helpful to the user (like setting the language for the 'panel) isn't a good UI design. Rework control_panel.py so that something other than Status() is used as the root object.

Git won't finish compiling without the presence of asciidoc (http://www.methods.co.nz/asciidoc/), which is used to format its documentation files. Sauce:

/bin/sh: line 1: asciidoc: command not found
make[3]: *** [git-tar-tree.html] Error 127
make[3]: Leaving directory /tmp/git-1.7.4.4/Documentation' make[2]: *** [doc] Error 2 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory/tmp/git-1.7.4.4'
make[1]: *** [../pkgs/git-1.7.4.4-i486-1.tgz] Error 1
make[1]: Leaving directory `/home/guest/Byzantium/porteus/git/src'
make: *** [pkgs/git-1.7.4.4-i486-1.tgz] Error 2

The compilation of APR fails because the doxygen utility isn't installed to format the docs. Either we need a doxygen Porteus module, or the build script for APR needs to be modified to call ./configure in such a way that doxygen isn't needed.

When using the "Configure Network Interfaces" function of the web control panel (http://localhost:8080/network/), the user can go through the process of either picking or pseudorandomly assigning an IP address to a wireless network interface. However, at the end of the process the following error message will appear in the control panel's debugging output:

"Error for wireless request ''Set Frequency'' (8B04) : too few arguments"

iwconfig is called from control_panel/networkconfiguration.py, NetworkConfiguration.set_ip()

Hardware: Asus EeePC 900, 1GB RAM, 4GB USB key.
Wireless NIC: Atheros AR5001 (rev 01)

dnsmasq is capable of performing a DNS hijack on certain IP addresses to redirect traffic elsewhere. In this case, traffic destined for certain popular websites (such as Google, Facebook, and Twitter) should be redirected to the node's frontpage (https://nodename.byzantium.mesh/) to inform the user that a) they are on a mesh, b) proper operational security measures should be taken, and c) they have to click through to acknowledge this fact. This is done with the address= directive in dnsmasq.conf, and looks like this:

 address=/www.google.com/10.x.y.1

Due to the fact that the IP address to redirect to has to be specified, we can't set this up ahead of time. It'll have to be configured at the same time that the dnsmasq.conf.include file is created by the control panel. This will be pretty easy to do as it will only involve the addition of a couple of writes to the .include file.

So far, www.google.com, encrypted.google.com, twitter.com, and facebook.com are on the list. Any others we should hijack?

Using the build-o-matic to compile a Porteus module of Git doesn't work. It fails due to the for... loop in build.sh. Executing the package construction process by hand omitting the for.. loop almost works. It dies at the end of the ./configure process with the following error:

...
checking for library containing mkstemps... none required
checking for initgroups... yes
checking for library containing initgroups... none required
checking Checking for POSIX Threads with '-mt'... no
checking Checking for POSIX Threads with '-pthread'... yes
configure: creating ./config.status
config.status: creating config.mak.autogen
./git.SlackBuild: line 96: /etc/profile.d/32dev.sh: No such file or directory

32dev.sh doesn't seem to exist in the test VM. Running a find(1) as root on / doesn't return anything.

ignore this

Right now Byzantium can only be manually installed in a running instance of Porteus Linux. The documentation of the process is partial at best (http://wiki.hacdc.org/index.php/Process_for_manually_installing_Byzantium. (NOTE: There needs to be a period at the end of that URL!) and prone to problems involving forgetting to copy customized and version controlled config files into place. The manual installation process is what we'll be basing the distro build process on, so we need to finish fleshing out that wiki page. I think this needs to be a group effort to get as much coverage of the installation process as we can.

Start with a basic install of Porteus Linux (on a USB key is fine, a virtual machine is better) and check out the repository. Then start following the instructions on the wiki page to install packages and copy configuration files and scripts into place. In many of the sub-directories pertaining to Porteus packages, config files can be found in subdirectories (Byzantium/porteus/) that match where they should go in the live system (so, files in Byzantium/porteus/apache/etc/httpd should be copied into /etc/httpd).

There's going to be a significant amount of pain here, so the faster we get it over and done with the faster we can automate the process with Ben and Chris' build-o-matic.

Murmur (http://slackbuilds.org/repository/13.37/network/murmur/) is the server-side component of Mumble (http://slackbuilds.org/repository/13.37/network/mumble/), a voice chat application that is efficient, lightweight, and encrypted (http://mumble.sourceforge.net/FAQ#Is_Mumble_encrypted.3F) end-to-end with the potential of self-signed certificate-based authentication. It's pretty stable and is being used pretty heavily by some activists when cellular or hardwired telephony is unvailable or can't be trusted. Perhaps we should consider packaging the Murmur server and including it with Byzantium Linux.

Needs a compiled and installed libgdbm package to work.

testing please ignore this