Most recent edit on 2007-08-19 02:18:49 by ChrisBuechler
Additions:
- Add SCTP (Stream Control Transmission Protocol) support. May be possibly utilized by VoIP apps
Deletions:
- Add SCTP (Stream Control Transmission Protocol) support. May be possibly utilized by VoIP apps
Edited on 2007-08-19 02:18:20 by ChrisBuechler
Additions:
- If using a DTD/XML Schema/RelaxNG Schema
Deletions:
- If using a DTD/XML Schema/RelaxNG Schema
Edited on 2007-08-19 02:18:06 by ChrisBuechler
Additions:
- Add IPv6 support
- Running IPv6 (ISBN: 1590595270)
- We, the pfSense developers, recently discussed that it may be desirable that not only Ajax capable browsers should be able to render the pfSense config GUI but also text browsers such as lynx/links. Unfortunately their ECMA script support is quite limited. Thus they are not able to render the current pfSense webGUI.
Deletions:
- Add IPv6 support
- Running IPv6 (ISBN: 1590595270)
We, the pfSense developers, recently discussed that it may be desirable that not only Ajax capable browsers should be able to render the pfSense config GUI but also text browsers such as lynx/links. Unfortunatly their ECMA script support is quite limited. Thus they are not able to render the current pfSense webGUI.
Edited on 2007-08-19 02:17:18 by ChrisBuechler
Additions:
- Add support for a UPnP Media Server DCP which is required by the FreeNAS package (possibly overlaps with the already existing miniupnp package)
Deletions:
- Add support for a UPnP MediaServer DCP which is required by the FreeNAS package (possibly overlaps with the already existing miniupnp package)
Oldest known version of this page was edited on 2007-08-19 02:16:31 by ChrisBuechler []
Page view:
Google Summer of Code Ideas
This page will house ideas that we would like to pitch to google. Actually the below ideas are just brainstorming ideas. If you think you are able to provide even better ideas do not hesitate to do so. Of course quite lengthy work items may be split into several smaller work items if necessary.
Note: Some of the below ideas are quite challenging, some even may not be accomplish during the Google
SoC period. On the other hand others are rather easy to accomplish. So please question yourself really thoroughly whether you have the skills to accomplish a certain work items before applying to the actual item.
- Fix traffic shaping so that IPSEC is shaped
- better upgradeprocedure for embedded systems
- Add a BGP package
- Add a OSPF package
- Add a Gfarm package which my be utilized by the FreeNAS package (see: http://datafarm.apgrid.org/∞)
- Add gjournal support (see: http://wiki.freebsd.org/gjournal∞)
- Add SCTP (Stream Control Transmission Protocol) support. May be possibly utilized by VoIP apps
- Implement pfSense support for ARM based platforms based on the FreeBSD ARM architecture (see: http://www.freebsd.org/platforms/arm.html∞)
- Fix Miniupnp to use a proper traffic shaping queue
- Add support for a UPnP MediaServer DCP which is required by the FreeNAS package (possibly overlaps with the already existing miniupnp package)
- Add support for Avahi and its accompanying autoip daemon
- Avahi (i.e. Zeroconf) support is already part of the FreeNAS package, try to turn it into something that can be used by any package. For example create a leightweight API which allows any pfSense package to register itself with the Avahi system. That way Avahi may announce the service provided by such a package using mDNS.
- Add autoip support to the pfSense base systems
- This is especially interesting for (mobile) mesh networking setups where peers do appear/disapear spontaniously or where there's no DHCP server available.
- Basically the pfSense system should start to negotiate with the autoip daemon if getting a DHCP addressed failed (IIRC Avahi already provides a script for the ISC DHCP daemon which exactly implements such a behavior)
- Further reading:
- Finish the squid package and fix/add missing or broken features.
- Fix squid authentication against Windows AD using winbindd or LDAP
- Add a front end to view the generated squid logs system/cache/acces
- Make squid work with Multi-Wan installations. Currently all traffic goes out the main wan interface
- Port the FreeNAS package to the pfSense stable system
- Negotiate with the package author what needs to be done to port the package the RELENG_1
- smbpasswd needs plain text passwords as input which isn't not supported by pfSense (password are stored encrypted). Try to figure out whether it's possible to use LDAP or PAM as an authentication backend instead to overcome this limitation.
- FreeNAS currently exports a whole disc via NFS/CIFS etc.. This is quite bad because most times it's rather desirable to export particular directories instead of a whole disk. Try to elaborate whether it's possible to implement an Ajax based UI that allows to export a distinct folder to certain users or even a complete group (hint take the windows 'Sharing and Security' dialog as an example).
- Port http://www.lionic.com/Products_LC2350A.htm∞ to FreeBSD so that pfSense can utilize.
- Port Linux l7 filter classification userland proxy to pf
- Add pftpx-routeto so that multi-wan ftp will function correctly (initial groundwork laid in -HEAD)
- Add IPv6 support
- Try to make IP services aware of a LAN address change
- Add PAM support to any piece of pfSense software that is able to utilize PAM
- This includes the webGUI and the various software packages
- The student needs to do a minimal degree of research work to figure out which software packages are PAM capable (e.g. Squid)
- It should be for example possible to authenticate against a LDAP directory (user/groups provided by LDAP) if using PAM
- Add nsswitch subsystem support
- Refactor the current config system
- The current pfSense config settings are stored within a pseudo XML file (i.e. the file does not contain valid XML markup)
- Create a config XML settings file that validates:
- If using a validating XML parser (i.e. libxml2)
- If using a DTD/XML Schema/RelaxNG Schema
- Each package uses its own set of XML tags. A unified set of XML tags is required that can be used by any software package to store its config settings. This step is mandatory because it's not possible to define a DTD/Schema if each package uses its own set of tags (Apache Ant for example has the same issue with its XML config files).
- Certain pfSense project members already expressed their interest in having a config backend that stores the pfSense settings into a SQLite DB instead of a XML text file.
- Define and implement a pluggable config backend which is able to store pfSense settings in a XML file (stored on the pfSense device), in local embedded DB such as SQLite or in a remote persistent store such as a RDBMS or a LDAP directory.
- Further reading:
- Pro PHP XML and Web Services (ISBN: 9781590596333)
- And of course the books about PHP v5 further below
- If you want to improve your SOA expertise try to elaborate whether it's possible to leverage SCA/SDO to store pfSense based ...
- system settings
- package settings
- pfSense user definitions
- pfSense group definitions
- pfSense permission-/role settings
- The applicant needs to coordinate his efforts with the student that tries to refactor the pfSense config system
- Further reading on this subject:
- Make the pfSense UI MVC agnostic
- We, the pfSense developers, recently discussed that it may be desirable that not only Ajax capable browsers should be able to render the pfSense config GUI but also text browsers such as lynx/links. Unfortunatly their ECMA script support is quite limited. Thus they are not able to render the current pfSense webGUI.
- Additionally it may be desirable to have a curses based UI that may be accessed using a terminal app such as PuTTY.
- In consequence we had the idea that it may be a good idea to use the MVC design pattern to implement different views for the same pfSense config data. Examples:
- A XHTML and Ajax driven view
- A simple HTML view possibly without the need of JavaScript so it can be rendered appropriately by text browsers
- A curses based view that allows to access the pfSense system (i.e. the config settings) via the console, a SSH session or a serial line console.
- In the past we had the idea to use an already existing framework such as CodeIgniter (see: http://www.codeigniter.com/∞) which already supports the MVC paradigm to accomplish this task. So this would mean:
- A classical situation where you should elaborate whether it's more sufficient to code MVC support from scratch or to use an already existing framework
- Design the actual model-view-controller hierarchy and implement at least one view with the accompanying controller for one of the previously mentioned scenarios (preferably an Ajax view)
- Further reading:
- http://en.wikipedia.org/wiki/Model-view-controller∞
- Ajax Patterns and Best Practices (ISBN: 1590596161)
- The Book of Javascript (ISBN: 1593271069)
- Foundations of Ajax (ISBN: 1590595823)
- Object-Oriented PHP: Concepts, Techniques, and Code (ISBN: 1593270771)
- PHP 5 Objects, Patterns, and Practice (ISBN: 1590593804)
- The Web Programmer's Desk Reference (ISBN: 1593270119)
- Lock certain web pages from being accessed or make them read only
- If an admin currently administers certain settings, it should be possible to completely lock the page or make it read only for unprivileged users. That way it would not be possible that two users are editing the same pfSense settings at the same time.
- Completely lock the web UI for maintenance purpose
- Monitor changes to settings contained on a page and just submit the changed settings upon page submittal.
- Refactor the current Ajax based form submission code
- Reference: http://wiki.pfsense.com/wikka.php?wakka=IdeasForANewAjaxFormSubmission∞
- Right now we are observing the onclick event of a form named iform (see: headjs.php init() and submit_form()). This approach is quite inflexible because it does not allow for example to provide a custom form serialize logic (For example those found in disks_manage_tools.php). Thus we need a more OO like approach which allows a subclass to overwrite the observe logic with its own, custom logic.
- Replace the current Sajax based CPU usage graphs etc. on index.php which are using a pull technique to get new data, with the Comet technique where the server pushes new data to the browser if applicable.