Re: is this thing on?

On 07/31/2006 04:40 PM, Michael T. Halligan wrote:
> Joyce,
> 
> Do you need any help? I'm sure there are a bunch of us (myself included)
> who would gladly help out.

	Going a little bit further, I have interest in work with
translation and "push" infrastructures.org in Brasil, so people
get to know it. ;)

	Kind regards,

--
Felipe Augusto van de Wiel (faw)
"Debian. Freedom to code. Code to freedom!"

Re: is this thing on?

Re: isconf deprecates infrastructures.org?

Magnus said on Mon, Jul 31, 2006 at 09:57:07AM -0400:
> I am reading up on isconf at http://trac.t7a.org/isconf/ and a lot of
> what I'm reading would seem to contradict or deprecate the bootstrap
> checklist for infrastructures.org.
> 
> Does the site need to be revamped to reflect this development?

Perhaps this is no longer the correct list, but:

Something that I don't see isconf doing is recovering from user error
(at least, not very well).

Let say that I have an environment with a bunch of developers, and those
developers, for example, have root on a set of machines.  Being
developers, they want to be able to install things temporarily "as
needed", and I want to be able to restore the machines back to baseline
quickly and easily.

isconf seems to indicate that it will just totally fail in that
scenerio, requiring a fully machine rebuild in order to bring the
machine back under control.

In fact, it seems that isconf will blow up if anybody forgets to make
changes using isconf at all (vs. restoring the machine to the known good
state).

Am I missing something?

M

Re: isconf deprecates infrastructures.org?

 > In fact, it seems that isconf will blow up if anybody forgets to make
 > changes using isconf at all (vs. restoring the machine to the known good
 > state).
 >
 > Am I missing something?

    No, you aren't.

    It's a pretty standard problem for sysadmin tools in this space.
You'd have to detect what was done behind the tool's back and either
pretend the missing delta was performed by the tool, or undo what was
done outside the tool.  You're not going to get this kind of behavior
from the isconf model of how you do things.

Re: isconf deprecates infrastructures.org?

Daniel Hagerty said on Sun, Aug 13, 2006 at 03:36:55AM -0400:
>     It's a pretty standard problem for sysadmin tools in this space.
> You'd have to detect what was done behind the tool's back and either
> pretend the missing delta was performed by the tool, or undo what was
> done outside the tool.  You're not going to get this kind of behavior
> from the isconf model of how you do things.

Dang.  That's too bad.  I'd kind of like to be able to use isconf
instead of the in-house system I'm using now (basically, systemimager's
updateclient + cvsup to overlay configurations), but we use the "reset
the system back to known baseline" functionality a lot.

From reading more, it also seems like isconf assumes that your
environment never changes?  At least, there doesn't seem to be any way
to "collapse" the journal into a new base image so that you don't have
to replay the whole thing every time you image a new host.  In my case,
our current images are 2+ years old (Debian sarge), and there have been
a lot of things done to them in that period; having to replay 2 years of
changes (security patching apache multiple times, etc) every time I want
to install another rack of hosts doesn't seem like a good idea,
especially if someone removes a CNAME that hasn't been used for two
years but an early step in the journal depends on.

M

Re: isconf deprecates infrastructures.org?

On Sun, 2006-08-13 at 03:36 -0400, Daniel Hagerty wrote:

>     It's a pretty standard problem for sysadmin tools in this space.
> You'd have to detect what was done behind the tool's back and either
> pretend the missing delta was performed by the tool, or undo what was
> done outside the tool.  You're not going to get this kind of behavior
> from the isconf model of how you do things.

This has long been a complaint of mine with the tools I've looked at.
I'd really like to be able to inform the tool, make local changes, then
check my changes back into the central repository, easily and without a
lot of fuss.  Because, invariably, it takes more than one try to get a
particular configuration right and the iteration of "change in repo,
manually run tool to update host, reload server, see if it worked" is
frustratingly long--even if it's only 30 seconds or so.

Wil
--

-- 
Wil Cooley <wcooley <at> nakedape.cc>
Naked Ape Consulting, Ltd. <http://nakedape.cc>

Re: isconf deprecates infrastructures.org?

 > From reading more, it also seems like isconf assumes that your
 > environment never changes?  At least, there doesn't seem to be any way
 > to "collapse" the journal into a new base image so that you don't have

    Steve's original papers had allusions to a snapshotting process he
used to basically play forward some amount of the log so that new
installs didn't have to start from the very first delta.  He never
really elaborated (that I saw) on how he went about this.

    In any event, you can probably arrive at a workable process for
what you do to prevent this particular problem given what you're
already using.  Play some amount of the delta that gets played to
everything and image it.  Install new machines from the image and play
new delta from the point of imaging forward and you should arrive at
the same place.

Re: isconf deprecates infrastructures.org?

Daniel Hagerty said on Sun, Aug 13, 2006 at 04:32:01PM -0400:
>     In any event, you can probably arrive at a workable process for
> what you do to prevent this particular problem given what you're
> already using.  Play some amount of the delta that gets played to
> everything and image it.  Install new machines from the image and play
> new delta from the point of imaging forward and you should arrive at
> the same place.

That's a good point.  There's no reason to maintain a giant journal
forever.

Here's the thing, though; I've more or less got my infrastructure under
control (server/admin ratio of ~ 350:1 currently), but I'm spending time
doing application management, not systems.  For example, mysql _sucks_
at scale; there are no tools to automate replication setup amongst a
spare pool of mysqlds, for example.

This sort of application specific management is what would be the most
useful to me, but most of it seems to require modifications to the code
itself; many software packages seem to require a _lot_ of effort to
shoehorn them into this kind of environment, and it sucks, although far
less than doing this by hand.

I'm continuing to keep an eye on isconf 4, though; it has a lot of
things going for it that I like a lot, and it plus some other glue may
prove to be better than what I've got right now.

M

Re: isconf deprecates infrastructures.org?

 > This has long been a complaint of mine with the tools I've looked at.
 > I'd really like to be able to inform the tool, make local changes, then
 > check my changes back into the central repository, easily and without a
 > lot of fuss.  Because, invariably, it takes more than one try to get a

    Well, depending on what you mean here, this is kind of what isconf
4 (or whatever it is) is trying to give you, provided that you work
within its constraints.  But by the same token, undoing "oops" as part
of your edit/compile/debug cycle isn't really in scope.  You'd need a
completely different model.  It all depends on what you really mean
when you say the tools aren't that good -- it's true, they aren't, but
what would you like to see them do better, spelled out more precisely?
(and this is the wrong list for such a discussion)

 > particular configuration right and the iteration of "change in repo,
 > manually run tool to update host, reload server, see if it worked" is
 > frustratingly long--even if it's only 30 seconds or so.

    If your edit/compile/debug cycle is 30 seconds, you're doing
peachy.  99.7% of the world has to deal with much longer.

Re: isconf deprecates infrastructures.org?

On 13 Aug 2006, at 03:36, Daniel Hagerty wrote:
>     It's a pretty standard problem for sysadmin tools in this space.
> You'd have to detect what was done behind the tool's back and either
> pretend the missing delta was performed by the tool, or undo what was
> done outside the tool.  You're not going to get this kind of behavior
> from the isconf model of how you do things.

This precisely the basis of how radmind is used to manage systems:

	http://radmind.org

radmind detects changes, a la tripwire, captures them, and allows an  
admin to replicate the captured changes to other machines.  Or, if  
the changes are not desirable, roll the machine back to a known good  
state.

:wes