Public SourceMage Discussion List

[Vlad Glagolev <stealth AT tiberian.ru>]

On Wed, 7 Oct 2015 14:28:17 -0500
Jeremy Blosser <jblosser-smgl AT firinn.org> wrote:

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

You're saying that the hardware you pay for is primary, and along with
that ours -- isn't, simply because it's not in your control. But without
sobukus' mirror there wouldn't be any ability for our users to download
grimoires and code. You call this hardware alien, but for our users
this is the _only_ hardware they get anything from us.

Of course that master server is holding the repository, and when it's
down we have to poke someone to bring it up. But that's not the way how
our fault-tolerance must be implemented.

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

Too bad we don't even have a simple monitoring there :(
I'm afraid of asking about backups as well.

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

We're paying for our servers the same as you do for yours and call it
distro's. We participate in distribution of the sources the same way,
and have right to call them "distro's" as well, because they're primary
nodes for our users to get the code; not that mystic master server
that is not visible to anyone. Especially when it's not anycast-distributed.

We're all the same since we provide our own resources for the project.
We do not have US visas, and instant access to that TX (or not?) datacenter
if it's *the distro's* hardware you're calling. Do we?

If it's about some dedicated stuff, and not colocation stuff, we do not
have access to the control panel to reboot, ask for maintenance and so
on. There's only one key, and it doesn't seem to be very stable -- I'm
talking about reliability: because of lack of proper mirroring our
infrastructure is in awful state, and you say "hell no, we don't need
to have mirrors!". I find it _very_ non-professional.

And the thing I suggested was just temporary setup proxying/dns-switch
to the server where it's configured, up and running until we prepare
the place on your server(s).

But you've chosen to trash any user experience with our new website for
such long period of time. You prefer it that way, I see.

First, spent several months for nothing. Now you're providing pretty
senseless arguments to "protect" "the distro's" "future" from the
non-controllable environment, which has been up and running and
dedicated to *the project* for almost one year (the mirror(s) with
some parts of codex, sorcery, isos -- for 5+ years, though).

That's insane, and definitely shows what does this project mean to
you, when in a name of invisible protection you can sink it without
thinking how could that decision affect the future of the project.

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

I would do that myself instead, but no, it just uses resources from one
of my servers with configuration of everything. It's not that isolated
thing. But if we speak of bugs.sourcemage.ru, then yes, it's on a VM as
I mentioned in May[0].

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

And that's what I was talking about[1]. My setup is already "over
years", in many places, up to 10 years in a very good shape.

I'll tell you a secret: that's about who uses and wants to use it.
Everything will be fine if you're involved in development and use stuff,
and rotten (what we see now) if you're not really interested. That's not
about lack of people, but about lack of interest from your own side.

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

[0] https://lists.ibiblio.org/sympa/arc/sm-discuss/2015-May/021987.html
[1] https://lists.ibiblio.org/sympa/arc/sm-discuss/2015-January/021794.html

--
Vlad Glagolev <stealth AT tiberian.ru>

Attachment: pgpGh3f7ItJ8q.pgp
Description: PGP signature