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