Public SourceMage Discussion List

[Jeremy Blosser <jblosser-smgl AT firinn.org>]

On Oct 07, Vlad Glagolev [stealth AT tiberian.ru] wrote:
> On Sat, 3 Oct 2015 04:29:43 -0500
> Jeremy Blosser <jblosser-smgl AT firinn.org> wrote:
> 
> > On Sep 30, Vlad Glagolev [stealth AT tiberian.ru] wrote:
> > > On Tue, 29 Sep 2015 18:55:43 -0600
> > > Sukneet Basuta <sukneet AT gmail.com> wrote:
> > > > What ever happened to Vlad's new website? Using that as Source Mage's
> > > > website would be a step in the right direction imo.
> > > 
> > > Vlad's new website is in-place, but the migration procedure to Jeremy's
> > > hardware is on hold because of some RL happening.
> > 
> > It's not Jeremy's hardware, it's the distro's hardware that Jeremy happens
> > to pay for (except the few times the distro has taken up a donation drive
> > to cover it). What is installed on it and who has root access to it, etc.
> > is determined by the distro. That's how it's always been, and that's why
> > primary distro resources go there and not somewhere else the distro 
> > doesn't
> > control.
> 
> Except now all primary distro resources are on both my and sobukus[0]
> servers'.

No, the secondary resources are there.  The things that hold the primary
scm data and that the distro tools point to are primary, the things those
things redirect to are secondary.  This is why when we lost DBG, for
example, we were easily able to repoint everything to other resources.  And
if your nodes go away, we'd be able to do the same.

> But that's fine. As fine as our @sourcemage.org mail hasn't
> been working since 17 Sep. I wouldn't call that 'control', really.

I wasn't aware of this, thanks for letting me know.  It should be fixed
now, though it has quite a backlog of everyone's spam to get through trying
to forward to them.

> And such complaining in every such discussion sounds _really_ strange.
> I'm sure several of us could host it for years without a problem --
> sourcemage.org is not facebook.com, not even booking.com. So if you're
> suffering from participating in that -- don't.

What complaining?  Are you talking about the simple statement of fact on
the funding?  I just said that to make the distinction that no, it's not my
stuff, and the only reason some seem to think that is because I pay the
bill.  It is the distro's stuff.

From the rest of your mail, there seems to a fundamental misunderstanding
here.  Our server resources are the same as our scm data, or package trees,
or our isos--they are managed and owned by the distro.  Nobody has a
monopoly on any of that, no one person "controls" it.  We're a community
distro.  Yes, all of our stuff (sorcery, codex, iso, servers, what have
you) is suffering from lack of participation and people.  But when someone
shows up and says "the iso is old and busted, I have made a new one" and it
works, we say, "great, please give us the new stuff so the community can
benefit from it."  If they say "no, that's hard, just update your
distribution links to let people download the sourcemage ISO from my server
from now on" we don't do it, because then the distro isn't able to work on
the ISO together anymore.  Me asking you to take your great website work
and put it on distro resources so the distro can work on it moving forward
is not any different.

It's on a VM, right?  Just get me the whole chroot tarball and I'll just
put that up on freki.

> > > So I still propose to set up temporary proxying from at least
> > > sourcemage.org and www.sourcemage.org hosts and/or change DNS records
> > > instead of wasting even more time.
> > 
> > If you currently don't have the time to do the migration, how do you have
> > the time to maintain it on your hardware?
> 
> It doesn't need what you call maintenance or "maintenance" that happens
> to our current distro infrastructure. Once properly set up, it just
> works with cosmetic updates of some stuff -- so it doesn't take much
> time.

This is an odd claim to make given your other complaints about the current
infrastructure below.  Infrastructure always requires maintenance over time
or it degrades.  Our current stuff is not in disrepair because it's overly
complex or requires specialized knowledge, like everything else in this
distro it's in disrepair because of lack of people helping, and lack of
time from those that help.  Over years your setup will show the same
problems without regular maintenance, let alone what happens without
regular security updates.

> While setting up a new infrastructure on another platform from scratch
> does.

Yeah.  Give me the VM chroot tarball.  Done.

> scmweb issue being broken for months,

I thought someone else said they fixed that, I can take another look (or
any of the many distro volunteers could offer to if they want!)

> openhub commit stats hasn't been updated since May (because of what? a
> simple move?),

I'm not familiar with this one, who set it up?

> broken mailing addressing,

In reference to what?

> broken mirrors,

In reference to what?  We don't host mirrors, we have a primary distro site
we had to migrate to another, but that's been done for a while, is
something still broken?

> broken DNS service (one DNS server, are you serious?),

We lost the geographically distributed second one when we lost DBG, this
was fixed and DNS migrated to two other nodes last week.

> just to name a few).

Please do keep going.  I can about guarantee everything you list is, like
everything wrong with codex or iso, something that would benefit from more
people helping work with what's there in the community instead of playing
move the cheese to your own refridgerator and pretendning it'll never spoil
there.

> Are you thinking that all this useless "defense" really costs our
> web-presence? I mean non-existence of our web-presence. We will be
> celebrating a year soon, since I announced of beta.. And you're still
> "protecting" it the wrong way while keeping it rotten. Protecting from
> what or who?

Protecting from loss of the ability of the distro to make updates when you
aren't around.  That's the only thing I've ever objected to doing.  The
same way I'd object to someone in the distro saying "I fixed the codex
problems, I'll take it from here, just point at my codex distro server from
now on."

I mean, you produced a website with fixed content, and I gave you a
dedicated VM with root access to put it all on.  I don't think you can make
much claim I'm obstructing you doing the work.

> > > I'm thinking that putting our primary node of repositories to gitlab is
> > > a bad idea and strategic mistake in comparison with supporting our own
> > > multi-mirror infrastructure (which all must be running Source Mage, not
> > > that RedHat, Fedora, Ubuntu or whatever you happily fire&forget).
> > 
> > In 20 years in this business
> 
> big numbers cost nothing in an improperly-managed environment.
> 
> our infrastructure is not fault-tolerant at any level, and any tiny
> issue causes full blackout of the service we're trying to provide.

When you talk about mirrors, I think you mean in the traditional software
download mirror sense.  Our software download site has been almost entirely
reliable[0] since it was set up.  It is fed from an scm system that takes
our updates, which has had some "tiny issues"[1] and if we want to try to
set up redundant scm servers we could look at that, but that's a different
mirroring problem to solve from just finding people who want to run rsync
for us and that is actually something we'd also presumably just get from
using something like gitlab, so that's not an "either/or" thing.

[0] it went down after something like 9 years when the company providing us
the secondary distro site suddenly vacated their datacenter
[1] the nic failed and had to be replaced; our allocated CIDR block was
suddenly replaced with another one

Attachment: pgpeC6JY8baqb.pgp
Description: PGP signature