BALL

This page has three main sections. (Note that the listings could be empty.) more… Tip: Remember the back-button! And don't click the number on the left.

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.
documentation
3767 comment >

System Monitor

Location

The system monitor and control panel is a simple browser based interface for common administrative operations on the local peer. The monitor is by default either as user named "system" or within the "system" user under the name of "system".

System Monitor & Control: Tabs

Threads

A simple, native thread listing of the implementation.

Depending on the underlying language and implementation this listing looks very different.

Network

connect

This allows to supply a URL for the initial connect to a network. (Normally a one-time operation.)

host map

The current map from known host identifiers to network addresses.

connections

A listing of network addresses.

The connections listing is concerned exclusively with values gathered from the currently running peer (process).

Columns:

  • host: the other peer
  • left:difference of used vs. allowed number of connections active number of active (reusable) connections
  • speed: two sub-columns: total avg and recent avg of the time difference between echo messages sent to host and ready messages received. min, max upper and lower limits of speed.
  • s: connection state

    char description
    - unreachable
    # trying to connect
    > fully reachable (can connect at any time; aka. not firewalled)
    < one-way connected; persistent incoming connection exists, outgoing connections will fail (aka. firewalled)
  • age: seconds since last refresh of this entry

DNS

An example how the local map of connected hosts would look as a DNS zome file.

That's so far not actually used.

Entries

Management interface for local users.

Certs

Displays of the local X509 certificate and the certification authority in use.

For authorized users: includes forms to manage these certificates.

cm

Certificate Management: forms to aid the handling of certificate requests.

user debug

A protocol of the last debug messages generated from the user debug facility.

profiling

Very system dependent means to view some currently collected profile information of the peer.

3769 comment >

Network Setup Procedure Using A Central authority

A step-by-step procedure to set up a BALL network of three peers relying on a single X509 authority certificate.

TBD: Strip the down. There is no need to repeat ad nausea as done here.

Optional before you start: create three host name aliases for "localhost" in your DNS setup. We will use "a1", "a2" and "a3" here. If you don't do so, you will have to accept some SSL warnings and occasionally substitute "localhost" in command lines as given below.

  1. make (as described in detail above)
  2. make repository HOSTNAME=a1 PORTBASE=9000
  3. make start HOSTNAME=a1
  4. wwwbrowser http://localhost:9081
  5. log in using "gonzo" password "oznog"
  6. Follow Link "System" and "certs"
  7. Find the password field left of the "Create New Key" button, enter the hostmaster password ("exit" by default) and push the button to create a new certificate request for this representative.
  8. Find the password field left of the "Create New CA" button, enter the hostmaster password ("exit" by default) and push the button to create a new certificate authority for your whole network.
  9. Find the password field at the bottom of the "X509 Certificate Management" section, enter the hostmaster password ("exit" by default) and push the button labled "sign" to sign the certificate request for this representative.
  10. Find the password field left of the button labled "set host cert", enter the hostmaster password ("exit" by default) and push the button to store the newly signed certificate as this representatives SSL certificate.
  11. Copy the text block of the "Certificate Authority Certificate" (right column besides the clear text of the cert; from

    ---BEGIN CERTIFICATE to END CERTIFICATE-----) to the Clipboard.

  12. Stop the representative, e.g., press ^C in the terminal, where the "make start..." command runs.
  13. make repository HOSTNAME=a2 PORTBASE=10000
  14. make start HOSTNAME=a2
  15. wwwbrowser http://localhost:10081 log in as user "gonzo" with password "oznog". Note that this user "gonzo" is different from "gonzo@a1": they have different OID's. You may want to modify one or both of your gonzo's to make the difference apparent. Each of them runs on either a1 or a2.
  16. Follow Link "System" and "certs"
  17. Paste the certificate authority from the clipboard into the text area of the "manage" form (right under the file upload box labeled "CA Cert File", enter the hostmaster password ("exit" by default) and push the button to accept the certificate authority created at host "a1"
  18. Find the password field left of the "Create New Key" button, enter the hostmaster password ("exit" by default) and push the button to create a new certificate request for this representative (a2).
  19. Copy the text block (right column) of certificate request from the "X509 Certificate Management" section to the clipboard.
  20. open a new terminal and do make start HOSTNAME=a1
  21. If you have aliase names for your host point your wwwbrowser to https://a1:9443 wwwbrowser otherwise use https://localhost:9443
  22. The browser will complain, that it doesn't know the Certificate Authority. No surprise: you just created it yourself. Accept your Certificate (forever).
  23. If you don't have alias names, accept you browser complaining once more that "a1" is not the same als "localhost" but the certificate is for "a1", which is actually correct.
  24. Follow Link "System" and "certs"
  25. Paste the certificate request from the clipboard to the X509 certificate management area and push the "store" button.
  26. Enter the hostmaster password ("exit" by default) and push the button labled "sign" to sign the certificate request for host "a2".
  27. Copy the text block (right column) of certificate request from the "X509 Certificate Management" section to the clipboard.
  28. wwwbrowser http://localhost:10081, follow Link "System" and "certs"
  29. Paste the host certificate from the clipboard in the text area in the "Local X509 Certificate" section (right under the file upload box labled "Certificate File" and the "Submit Host Cert" button, enter the hostmaster password ("exit" by default) and push the button to store the certificate as this (a2) representatives SSL certificate.
  30. If you have aliase names for your host point your wwwbrowser to https://a2:10443 wwwbrowser otherwise use https://localhost:10443
  31. Accept the browsers complaints about your cerfificates.
  32. Follow the Link "System" and "network".
  33. Enter https://a1:9443 (or https://localhost:9443) in the "connect" field and press enter. Now Both your systems should know about each other. Especially the host with local id "a2" should have "a1" as "certified location" in the host map, while "a1" has seen the certification for "a2.

  34. At "a1" follow the link "Einstellungen" and "support" and enter "a2" in the "Toggle support" field.
  35. At "a2" follow "System" and "entries".
  36. Fill in the "create channel" form. Enter a new user id of you choice (we'll use "Fred") in the filed labled "here", "a1" in the field labled "from host" and "gonzo" in the field labled "user". Enter the administrative password ("sesam" by default) and push the "create" button.
  37. You should now be able to log into "a2" using user id "Fred" and password "oznog" and control the same user (according to the OID), which now runs on the majority of {a1, a2} - that is only on both representatives at the same time.
  38. Repeat the process from "make repository HOSTNAME=a2" for a3.
1339 is a > wiki page
1341 description >

Concepts And Internals

Alternatives

3763 description >

Usage

  • TBD Howto and first steps.

    1. Semantics rest on unreliable, unidirectional message passing with share nothing semantics. This choice was inspired by and follows the motivation of the Erlang language. (However that's where the similarity to Erlang ends.)
    2. Separation of duties among the expression language BAIL and the CoreAPI is similliar to the relationship of Haskell and its IO monad.
  • Command line syntax.

  • Some agents (like this one) allow low level access to their internal state. Also known debug interface, see: Exploring The System.

  • Core API to control effects

  • Capability based access control & incorruptibility

  • Applications may be written in any language. The core system supports:

  • TBD: Using WebDAV and mount directories via fuse

  • Monitoring

  • Bootstrap

    The bootstrap process installs an initial contract (typically a charter, statute, a license of some sort or a constitution) applicable to the accounts to be created at the representative. Under this initial contract it published some code defining the rules of the game and eventually creates user accounts bound to these rules.

  • Old manuals

Introductory Examples