To be continued.... ~ ornia

This page documents the list of items which must be accomplished in order to further the security, ease of use, and accessibility of ornia. To examine what has been previously accomplished in ornia thus far, see the Accomplished thus far ~ ornia article.

While all of ornia 1.0 and even some of ornia 2.0 was accomplished by Niko Kern only in his spare time outside of his courses, he has since sought official academic credit for his work on the project through independent studies with Dan Parker, the Senior Systems Administrator at Hampshire College. Dan is a faculty/staff associate, meaning he can sign off on independent studies, which is beneficial for Niko seeing as Dan has a wealth of GNU+Linux server administration experience.

= To-Do =

The items on this list will be tackled during Niko's current independent study for the Fall 2008 semester.

Regenerate SSL certificates
ornia runs Debian (or perhaps it's: Debian runs ornia?), and as such ornia fell victim to the OpenSSL vulnerabilites which plagued Debian's (and most Debian-derived distributions') OpenSSL packages. This means that all SSL/TLS encrypted communications to and from ornia are likely easily breakable, seeing as all of ornia's certificates were generated and self-signed before the vulnerability was known about.

Every SSL certificate needs to be regenerated with the patched OpenSSL software without the broken random number generator. This will require a reexamination of the best way to manually generate the strongest, safest SSL keys possible, as well as a proper solution for keeping track of them all on the filesystem. The certificates needing regeneration are used for ornia's webmail over HTTPS, other websites with Apache, IMAP and SMTP SSL encryption for those with standalone e-mail clients using ornia's mail server, Mumble, psyced certificates for all PSYC/IRC/XMPP use, and finally even Hampedia itself needs new certificates.

Migrate websites to a CMS
During the Fall 2007 semester, Niko had an independent study whereupon he taught himself (X)HTML, CSS, and a bit of Javascript and PHP. This was extremely beneficial for his skillset, however the only method of website creation he uses to this day is handcoding XHTML and CSS in vi, which makes for horrible management for larger websites with many pages. The other major problem is that others cannot help improve the site without Niko's direct involvement: not only is the barrier to entry to adding content far too high, but the only one with direct permissions to alter the website's documentroots was Niko himself.

This is not sustainable for larger projects that aren't solely run by Niko. Student group websites should be under the control of all those in the group, and it should be extremely easy to edit the pages and update them. This is the need for Content Management Systems for powering ornia's websites. The two most promising solutions are Drupal and Joomla, so both packages will be installed and assessed.

Patch Verlihub source code for Mac OS X and firewalled users
Verlihub has paranoid behaviors when it sees connections reporting a different IP address than the direct source destination on the layer 3 level of the OSI model. This paranoia is a feature to prevent Verlihub operators from turning their hub into a Distributed Denial of Service weapon, and thus they will not remove it. There are two major issues with this with respect to the current situation at Hampshire College.

The first is the lack of college-run wireless LANs in student living areas. This causes students to set up their own wireless routers which segment off the Hampshire Local Area Network into tiny chunks. Any clients behind routers will report the IP address they received from the router instead of the IP address ornia actually sees. This makes ornia kick off the clients due to mismatched IP address.

The other issue is with Mac OS X users who use the client “ShakesPeer” to connect to ornia's DC hub. This client is sub-par in many ways, but a horrible feature it has is to use a service such as whatismyip.com to detect the external IP address of the machine on the Internet and report that address to the hub. This is horrible for LAN setups where the hub is on the same network as the ShakesPeer clients. This causes the same issue whereupon Verlihub kicks Mac OS X users off until they find their correct internal IP address and configure ShakesPeer to use that instead.

After speaking with the Verlihub developers, Niko is now in possession of a patch to the source code to eliminate this issue. Now, the current configuration of Verlihub must be backed up, and a new source tarball must be downloaded and this patch applied. After this, the daemon must be compiled and installed, and the previous configuration must be restored. This must happen extremely quickly, so that the users of the hub don't notice too long of a downtime. There are around 40-100 users on the hub at any time, but this number is expected to at least double after this fix is implemented.

BACKUPS!!!!
ornia's backup solutions are few and far in between. This is extremely high priority and should be tackled very soon. Different solutions must be examined for backing ornia up: should snapshots of Xen domU guests be taken? Or perhaps just the LVM2 logical volumes? Both? Where will such snapshots be stored? How often will they be taken? Would it be better if they were incremental? How will this all be implemented? Dan Parker's experience will be relied on heavily for this task.

Upgrade ornia to lenny
Debian is wonderful for many reasons, but it's release cycle is extremely slow in the fast paced world of Free/Open Source Software development. A new version of Debian is coming out very soon, version 4.1 codename “lenny”. This version will contain new versions of almost all daemons ornia is running, as well as almost all components of the GNU system itself and the Linux kernel. There are complications to this upgrade, namely no precompiled Xen kernel suitable for running a domU paravirtualised. Because of this, it may be possible that ornia will become hardware virtualised on top of the domain 0 host operating system instead of paravirtualised. This will be pending the release of Linux version 2.6.28, when Xen domU support in the paravirt_ops extensions in the Linux kernel will be fully implemented and stable.

Research free (as in beer) SSL certificate authorities
The certificates which ornia uses are not signed by a certificate authority, or CA. This is fine for personal use of SSL/TLS encrypted ornia services, but the more used the service gets, the more annoying it is for a large userbase to have to click through to accept the certificate and claim they trust the source, which is ornia. Hopefully, a no-cost CA can be found which has root certificates in Firefox 3.

This issue is much, much worse after the release of Firefox 3. For some reason, Firefox 3 uses a quite intimidating screen which looks as if the site is down if the website uses a self-signed SSL certificate. It requires five clicks of the mouse on the correct buttons in order to accept the certificate and view the site anyway. This is an asinine take on encryption which encourage website operators to use no encryption at all if they don't want to buy CA-approval for their certificates. In the interest of free encryption on the Internet, research into a CA which costs $0 and who has root certificates in Firefox 3 will be conducted. Ideally, all of ornia's SSL certificates would then be signed by this CA, if it exists.

Explore internetworking between ornia and pitus
ornia and pitus are siblings, both designed by Niko within a mere four months of one another. They exist on the rack right next to each other in the server room. They both contain two Ethernet ports on their motherboards, one of which is of course connected to the Hampshire LAN and by extension, the rest of the Internet. However, the second Ethernet port on both servers is connected to one another using a crossover cable.

Even so, the two machines are not currently configured to know how to make use of this crossover cable. They would be able to send data to one another at a full 1 Gb/s, which is extremely swift. Given the immense storage capacity in both machines (~3.5TB for ornia and ~6.3TB for pitus), as well as the impressive CPU power and RAM capacity, there are quite a few things which could potentially be done to harness the collective power of both machines. Backups and distributed computing experiments come to mind as top uses.

Research DC hub linking between ornia and Amherst College
There is a student-run server which is sadly under-maintained and not used very much at Amherst College. Through his Amherst connections, Niko may soon be granted root access to this machine. After this, he will be able to run an Amherst wiki on site at the college, as well as running a Verlihub installation for their college as well. Seeing as all five colleges are on a fiber loop with one another, it is natural to extend a data sharing infrastructure beyond the confines of a single college campus, but rather to all five.

Hopefully, after gaining root on this server, Niko will be able to install and configure Verlihub for Amherst as well. At this point, he can look into hub linking between both ornia's directconnect hub and the one at Amherst College. This will only have positive effects for users at both colleges.

ornia Mumble improvements
ornia's Mumble server, called murmur, must be upgraded and configured to yield an easier user experience. Firstly, it needs to be accessible on the default Mumble port. Second, it must show up on the public server list for Mumble, so people just need to install Mumble and know ornia's name and connect to it through the built-in server browser. Thirdly, Niko must grant his username administrative privileges so that he may kick/ban users, create and delete channels, and alter server properties through his client. This seems more difficult than it should be. Lastly, the SSL certificate used for Mumble is self-signed, which presents first-time users with an ultimately unnecessary extra dialog box which would be ideal to eliminate.

munin + ntop for statistics
Graphical data showing network a system statistics would be an excellent, helpful feature for ornia to have, not to mention interesting. Both munin and ntop are tools which could provide many useful diagnostics. They both have web servers built-in, so graphical data could be viewed remotely via a web browser.

Tor!
A Tor node used to run on ornia 1.0, but it turns out certain companies take a proactive position and actively ban Tor nodes from using their services. For example, Yahoo now will not receive SMTP e-mail from ornia.hampshire.edu, even though the Tor node no longer runs. There must be a better way of running a Tor node without compromising the availability and usefulness of other services on ornia. Perhaps the best route is to create an entirely new domU guest operating system for running just the Tor node.

GPG in ornia webmail?
Not enough people use e-mail encryption. It must be easier to use before it gains an appreciable amount of popularity. Far and away the best e-mail encryption available is PGP encryption, and the best software implementation is GNU Privacy Guard, or GPG. If GPG were to be seamlessly integrated into ornia's webmail without compromising the sanctity of the private key of the users, it would be a step in the right direction.

Niko intends on working directly with the core Citadel development team in order to not only figure out the best way to implement this feature, but to make it part of Citadel itself so that others may make use of it besides on ornia.

Graphical Apache statistics...?
The more websites ornia runs, the more interesting it will become to gather usage statistics. Graphical data, much like munin and ntop are capable of producing for system/network information, would be wonderful to have for Apache page hits. Graphs and maps of source IP addresses displaying page hits over time for all the websites running on ornia is the goal. Thus far, no research into which software implementation would be best for running this service has be conducted.

Possible integration of ornia's Icecast with the Yurt
It is possible to link up Icecast servers with one another so that the same source client broadcasts to both. Niko has received a few complaints of the Yurt Icecast server being down, or students not having access to it for bureaucratic reasons. Hopefully, ornia's Icecast could provide redundancy, if not a student-run replacement for the Icecast which serves radio.hampshire.edu.

Pester Verlihub and Mumble developers to integrate LDAP support
Having the DirectConnect hub and Mumble be able to accept logins with Hampshire usernames and passwords authenticated by the LDAP server on campus would increase the usefulness and formality of the two services which Niko believes are of most importance to the Hampshire campus. Doing so would emulate the LDAP implementation currently found in Hampedia which make it so much easier to use.

Unfortunately neither Verlihub nor murmur have LDAP support currently. Niko is initialising discussions with the developers in order to convince them to write LDAP support into the daemons.

More services, more wikis....
It's not done here, it's never done. There are many more ideas for ornia which have not even graced the conscious mind of any human being. There are more services to be explored, the most important of which have not even been invented yet. Of specific note are wikis, which have been demonstrated to have an extreme market value for various organisations, be they educational institutions, companies, or even governments. In this respect, Niko will continue creating wikis on the technological end, all the while working with Jose Fuentes to help develop them as overall platforms for those who could benefit from them.

= See Also =

ornia

ornia Portal

Examining Anonymity Online (Birth of ornia)

Accomplished thus far ~ ornia