[Systems] [IAEP] ASLO updates
alsroot at member.fsf.org
Thu Oct 15 04:04:10 EDT 2009
On Thu, Oct 15, 2009 at 07:34:50AM +0000, Aleksey Lim wrote:
> 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
hmm.. but what about passwords in ASLO configs
> > 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.
not sure, ASLO configs could be not obvious for others, so we need
explanation in email anyway.
>> 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.
Maybe just reuse issue tracker, I mean it could be a good way from
decentralization pov and all interested people can subscribe to
bugs.sl.o email notifications. So all administration related tasks(not
only ASLO) could be requested on bugs.sl.o at first.
More information about the Systems