[IAEP] ASLO updates
Aleksey Lim
alsroot at member.fsf.org
Thu Oct 15 03:34:50 EDT 2009
On Thu, Oct 15, 2009 at 02:42:15AM -0400, Bernie Innocenti wrote:
> [cc += dfarning, alsroot, systems@]
>
> El Wed, 14-10-2009 a las 17:47 -0700, Josh Williams escribió:
> > I've made some bug fixes to the new ASLO design, I've tested it lightly
> > and it seems to work in all major browsers (even ie6). If you have a few
> > moments, please test it out (download/upload activities, browse around)
> > and let me know if you see any display bugs or major usability issues.
> >
> > http://activities-devel.sugarlabs.org/en-US/sugar/
>
> All links to activity bundles appear to be broken :-(
> For example:
>
> http://activities-devel.sugarlabs.org/en-US/sugar/downloads/file/26072/xpi/labyrinth-7.xo?src=addondetail
>
> I'm not sure how to fix it, but I can imagine that it may be related
> with moving the activity bundles from their old location
> (/srv/www-sugarlabs/activities/files) to the upload directory
> (/srv/upload/activities/) done by Dfarning in order to enable
> Mirrorbrain.
>
> Earlier today, alsroot asked me to fix some permission issues that would
> prevent aslo from writing new activities in the new location.
Thats intended to be so, activities-devel is just mysql copy of
activities, I thought, it shouldn't affect activities-devel testing(but
you can create new activity/version and it should be downloaded).
> also noticing that there's still a copy of the activities in the old
> location, and it is also bigger by 40MB!
Thats because /srv/www-sugarlabs/activities/files contains some tmp
directory, it shouldn't affect .xo downloading.
> /me is very confused :-/
>
> Could anyone who was involved please write a short description of what
> was changed exactly? I'm only trying to reconstruct the current
> situation, not looking for a scapegoat.
We just tried to utilize AMO feature when it lets user download
public .xos from mirror sources and from files/ for other cases.
Recently all .xo were downloaded from files/(even after creating symlink
in /upload to files/).. and it was done from several attempts.
For now we have two independent sources for .xo downloads:
* /srv/www-sugarlabs/activities/files for not public activities
and for 30min age public activities
* mirrored /upload/activities for all public activities,
after making new .xo public, ASLO uploads it to /upload/activities
> Hmm... well, perhaps we can learn something from this accident:
>
> The classic way to avoid the "too many cooks" syndrome would be to
> appoint a single official maintainer and make all the change requests go
> through him. However, I feel this "solution" would create lots of
> critical roles and ultimately defeat our ongoing attempts to
> decentralize system administration.
>
> Instead, we shall establish simple procedures to improve sysadmin
> coordination and communication. For example:
>
> 1) commit configuration changes in git along with a short description
> of what was done and why. We already have repositories for /etc and
> also and we could create more repos as needed;
Yeah, for now, ASLO configs are stored only in
~activities/site/app/config
> 2) write a short report for systems@ when we make substantial changes
> to a service;
>
> 3) write or update the wiki documentation for important sysadm
> procedures such as installing a new instance of a service
>
> Use your common sense to decide what needs to be documented and how much
> detail is needed. At all costs, we want to avoid putting too much
> bureaucratic burden on volunteers because it's the most effective way to
> make them look for something more exciting to do.
>
> We could save time by coalescing steps (1) and (2): all we need to do is
> enabling a post-commit hook in the repositories that would send patches
> to systems-logs@ . We need to be extra careful not to expose passwords
> in this way. Any volunteers to write and test this procedure?
Well, we don't need such ASLO specific administration 24x7, most of time
it could be just regular file-permissions/apache/etc administration.
--
Aleksey
More information about the IAEP
mailing list