Re: 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  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@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
> 

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

The future of openmoko.org hosting

[Harald Welte]

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@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

-- 
- Harald Welte    http://laforge.gnumonks.org/

"Privacy in residential applications is a desirable marketing option."
  (ETSI EN 300 175-7 Ch. A6)

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community