The future of openmoko.org hosting

[dmitry]

Hi Harald, 

Which way that was eventually solved? 

If it is not solved yet, I theoretically have some resources to host
major (probably all, except of email services) part of that. 

let me know, 
thanks! 

Dmitry 

On Sun, 15 Oct 2017 10:59:34 +0200
Harald Welte <laforge at gnumonks.org> wrote:

> Dear community,
> 
> Given that we've just head the 10 year anniversary of shipping the
> Neo1973, this also marks about the ~ 8th-9th year of inactivity in
> the project.
> 
> Ever since Openmoko, Inc. closed down, I've been personally covering
> the hosting fees for the (single, consolidated) openmoko.org
> machine.  I did that in order to keep the legacy/history alive, for
> those who might be interested in it.
> 
> While it was/is "only" EUR 50 per moth, it adds up.  Over the at
> leaset 8 years, that's at least EUR 4800.
> 
> I was happy to contribute that.  However, I don't want to continue
> this kind of financial obligation for another ten years or even any
> indefinite term.
> 
> Please note that the actual burden of system administration is
> contribute by volunteer work from Paul Wise, which is of course much
> appreciated!
> 
> So the question is in general, how to proceed here. One could
> 
> a) try to put funding on some more shoulders than just me, and
> continue with that one hosted machine as-is
> 
> b) get rid of the existing server, by the following strategy:
> 
>    * web: convert the dynamically-generated media-wiki, trac, svnweb,
> gitweb, etc. pages into static renderings that can be served from a
> static web server.  This could be done by something like a recursive
> wget through a http cache.  This would remove the need to run trac,
>      mediawiki and apache mod_svn, mysql, ... - and drastically reduce
>      the CPU and Memory requirements.  In the end, it would be a bunch
>      of static HTML pages rendered by nginx or lighttpd somewhere on a
>      virtual server or shared server.
> 
>    * lisst: migrate the single remaining active
>      (community at lists.openmoko.org) to another mailman instance, such
> as lists.osmocom.org.  We could configure mailman to retain the
>      list-id and simply point the MX to the osmocom.org server, i.e.
> do this without any impact on the list address or users mail filtering
>      rules.
> 
>    * e-mail: discontinue e-mail services at openmoko.org (except
> e-mail forwarding).  To my knowledge, only Joerg Reisenweber is using
> this service today - and to be fair, I would kindly suggest to use a
>      different imap-capable home for his e-mail after about a decade
>      of using the Openmoko legacy. Sorry :)
> 
>    * svn: discontinue svn service and simply have
>      * caches of the rendered html pages (for old hyperlinks to work),
>      * a git conversion of the old svn tree. for svn.openmoko.org, I
>        have done this and published it at
>        https://github.com/openmoko/openmoko-svn
> 
>    * git: discontinue git service and simply have
>      * caches of the rendered gitweb html pages (for old hyperlinks to
>        work), and
>      * the mirror at github.com, which I just created:
>        https://github.com/openoko
>      Yes, I'm fully aware that github.com is a proprietary service,
> and they can at any time take those repositories down and/or stop the
>      free service.  I'm not suggesting anyone use this for active
>      development projects.  But just to have a historic archive of
> code around that hasn't changed for 9 years, I think it's ok.
> Running a git server with a kernel tree inside requires quite a bit of
>      resources, and running gitweb or cgit with all the crawlers out
>      there can be a major CPU/RAM/IO hog.  If we can avoid this, we
>      basically eliminate the need for a separate machine for
>      openmoko.org
> 
>    * USB VID/PID repository: This is so far kept in the Mediawiki, but
>      I don't see a reason why this couldn't simply convert to just
> being a static CSV file that's on a http server, or a small, simple
> git repository with that CSV file inside.
> 
> Any comments/ideas/suggestions/complants?  I'm all-in for moving
> towards 'b'.  Next to the fact of basically reducing our hosting
> requirements to zero, it also has the advantage that we don't have to
> worry about keeping trac,mediawiki,etc. installations secure and
> updated.  Also, when moving to major new versions, there's always the
> risk of some issues with migrating the old data, some wiki rendering
> errors, etc.  - conserving the generated output saves us from all of
> that.
> 
> If we go for 'b', this would include us releasing SQL dumps of the
> trac, mediawiki, svn, etc. databases (probably clearing any
> passwords / password hashes), so that the raw information can be
> restored by anyone who has an interest to it.
> 
> Regards,
> 	Harald
>