Platform for managing ad-hoc web pages
Contents
Goal
Some pages in the new Fellowship platform can not be implemented in the wiki or blogs, moreover these pages have to be translated into as much languages as possible, so we need a platform to handle the versioning of these pages and the generation of multiple language versions (similar to the platform we have for the current fsfe.org webite).
Coordinator
People
A list of other people involved in the project.
mk (webgen platform)
- Gert Seidl Gert DOT Seidl AT fsfe DOT org: offered help with SVN (f-h@ 080910)
- Other volunteers welcome! (for different pages and their translation)
Volunteers are always welcome! Have a look at FellowshipHacks to know how you can help
Status
Done.
Tasks
This is an overview of the tasks to do for the completion of the project.
- (DONE) Decide the location of each component of the platform (see Notes)
- (DONE) Set up the components
- (DONE) Implement the software procedures and tools needed to operate the whole system (see Notes)
- (DONE) Upgrade self-signed SSL certificate for svn server with a CACert signed one
- (DONE) Write a wiki page with instructions for users of the svn server
You can create a page for a new task using the button below. Just enter the name for the page and it will be automatically created as a subpage of this project page.
Systems involved
- Current systems:
- auer
Notes
Location of the components
Servers available
- utyonkov (the server that will hosts the new Fellowship wiki and blog)
- auer (currently empty)
Components to be hosted
apache instance/virtualhost to host ad-hoc pages
- backend scripts for dynamic pages
- These require python
- These require gpg
- These require a local or remote SMTP server
- webgen: the page generating engine (plus the glue scripts to implement automatic procedures)
- This requires ruby on rails
- SVN server to host the page sources
Considerations to help deciding
- Which of the components work better if installed on the same server?
- e.g. does webgen have to be hosted on the same server hosting apache? Or it can update pages on a remote server?
e.g. does the SVN-commit -> webgen automated procedure have to work on the same server? Ore we can use rsync in the final step?
- What security requirements do we have?
- e.g. the server running the scripts that interact with LDAP or the Fellows database must be separated from the SVN server?
- What kind of access to SVN we want to give?
- ssh-based
- apache mod_dav_svn-based
- General opportunities from this platform:
e.g. SVN server: in the future it could be used not only for maintaining the web pages, but more generally as a Fellowship SVN server, to host other material made by Fellows (artworks, flyers, software projects...)
- Please note that flyers etc made by Fellows could also be managed through the wiki, and for possible software projects run by Fellows, just having a SVN would not be enough: we would need other services complementary to SVN (bug tracker, gforge or similar platforms), that currently we can't afford to manage.
- So, I think this is an opportunity only for the future, the only thing that we should care about NOW is to be careful about implementation choices that could block this opportunity in the future (but always keeping in mind the main goal: to have a SVN server up real soon for working on the pages):
User authentication/management (=> apache mod_dav_svn or ssh, see Notes)
- Location of the service
- Others?
Scenarios
- All components on auer
- Pros/cons?
- Separation between SVN and other components
- apache (virtualhost) + webgen + scripts on utyonkov
- SVN on auer
- auer would host the possible apache instance if we decide to implement svn as an apache module
- Others?
Requirements and solutions for each component
SVN server
Requirements:
- User management
- Two options for authentication
Using the LDAP database => SVN implemented as Apache(SSL) + mod_dav_svn
Via SSH accounts => SVN implemented as svnserve over SSH
- Criteria for decision:
- What kind of users will have access?
Internal FSFE team members: these should be in LDAP (are we sure?)
- Fellows: these are in LDAP
- Other external contributors: these are NOT in LDAP (unless we decide to manage external volunteers data in LDAP, see the related discussion for "wiki-only" users)
- What kind of users will have access?
- Two options for authentication
Apache
Requirements:
- Set up language negotiation (through mod_negotiation) like the current fsfe.org site
Page-generating engine
Requirements:
- Easy to manage
- Must be integrated with SVN, to run automatically after SVN commits
Solutions:
Current proposed solution: webgen (http://webgen.rubyforge.org/)
- Pros:
Possibility to add Embedded Ruby scripts: http://webgen.rubyforge.org/features.html under "Dynamic content"
- Extendable by writing add-ons in Ruby
- In the new versions webgen is able to just regenerate what has changed
- Really easy to install and use. So testing things on your local computer is very easy.
- Generated HTML files can be automatically checked if they are standard conform.
- We have some expertise (Matthias)
- Cons:
- It does not have a tool for status of translations yet, so we'd have to develop this (and track the development of the webgen codebase, if we implement it as webgen code)
- Do we have ruby know-how in case we need to hack webgen?
- Pros:
- Alternatives to evaluate
- reStructuredText and sphinx (Michael Kesper f-h@ 080916)
- Alternatives ruled out:
WML - http://thewml.org/ (seems complex, we have no experience)
- The fsfe.org build script (too complex and feature-bloated for this task)
Additional tools and procedures to be implemented
- Must have: automatic regeneration of web pages when a SVN commit occurs
- This must link SVN and webgen
- Take inspiration from the current script running on fsfe.org pages
- Nice to have: monitoring the translation status (like the one we have for fsfe.org pages)
References
- f-h@ 080909 volunteers and ideas for new fellowship site
Home page redesign: see also https://roundup.fsfeurope.org/watt/issue93