[racattack] Re: RAC Attack Automation Project
- From: Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
- To: "racattack@xxxxxxxxxxxxx" <racattack@xxxxxxxxxxxxx>
- Date: Tue, 15 Apr 2014 09:27:42 -0500
I think there's an important point to be remembered here. The RAC attack
project centers around people actually doing the hands on labs at events and at
home. Most of these people will be following the wiki book and will not use the
automation stuff. So the main/trunk automation subproject needs to track the
wiki book and aim for perfect consistency with it.
If people following the wiki book are using an OEL 6.4 ISO then that should be
the default for automation. Now there can be branches for experimenting with
improvements - I have a few branches of my own - but trunk/master should be
consistent with the wiki book. Changes to which version of the OEL ISO should
be discussed for the wiki book first, then the master branch of the automation
project should follow the stable wiki updates. Cool interesting new stuff
belongs in branches, after all that's what git is really good at!
For the wiki book instructions, I'd personally be hesitant to rely too much on
yum. Conferences always have poor internet connections so the lab should rely
as little as possible on the Internet IMHO. There is also the dojo sub-project
which could host or cache a yum repo - but personally I'd want to minimize
reliance on that. (Needing the proxy for downloading oracle software is an
unfortunate legal reality we can't get around.)
Having run a lot of events myself, I also place a _very_ high value on
consistency. We do a lot of troubleshooting and helping people over email or
over the shoulder at events. It's already complicated enough when you know
everyone has exactly the same package versions!
Few thoughts I had, but I'd love to hear some discussion!
-Jeremy
--
http://about.me/jeremy_schneider
Sent from my iPhone
> On Apr 14, 2014, at 10:07 PM, Alvaro Miranda Aguilera <kikitux@xxxxxxxxx>
> wrote:
>
> Hello,
>
> For the Automation project, the actual image is an 6.4 installation updated
> using UEK_latest and OL6_latest to April 07th.
>
> In the next quarter, Oracle May release a new UEK2 and pump version like
> 2.6.39-500 and depending on the actual acfs it may load (if they have
> 2.6.39-*) or may fail , (if they have 2.6.39-100/200/300/400)
>
> When the new kernel came out, I will report back (or anyone can test and
> report back)
>
> At the moment, the automation project is done in 2 components, one is the vm
> image (vagrant box) .. that have all included for those wanting to show this
> in a conference center without internet, and 2nd component are the Vagranfile
> and script hosted in github, The actual vagrant box image, works out of the
> box, and don't require any update, it just works.
>
> I keep an eye on the list and proposal of new labs, and will update the image
> in case a new RPM XYZ is required, but so far, so good.
>
> The Vagrantfiles and the scripts on github, have received some minimal
> updates based on feedback from Leighton and Jeremy, and I am about to push
> some further improvements that will allow the creation of new labs a bit
> faster, I foresee the weekend for those (long weekend hehehe :) )
>
>
> If there is a requirement to have a consistency, we may default to some
> particular version, say 6.4 DVD, the only extra rpm required could be
> oracle-rdbms-preinstall, all the rest from DVD should be enough.. if this
> step is required, I have created a Vagrant Box 6.4, with no extra patches,
> that I haven't yet tested since the 6.4 patched to 6.5 as April 07th works..
> But I can default to this 6.4 frozen version, provide all the rpms and update
> the wiki.
>
> Actually, that is a pretty good point since anyone at home may download a 6.5
> iso, boot, and will be using UEK3 kernel version 3,8 and ACFS won't work..
> and move to UEk2 may be PITA for some people who just want something out of
> the box.
>
> Alvaro.
>
>
>> On Tue, Apr 15, 2014 at 2:44 PM, Seth Miller <sethmiller.sm@xxxxxxxxx> wrote:
>> My suggestion to avoid the ACFS kernel version issue and other compatibility
>> issues is to create our own yum repository and update the wiki to use it
>> instead of the Oracle public repo. That way, we can control the environment
>> and at the same time limit the packages in the repo to speed up the metadata
>> processing.
>>
>>
>>> On Tue, Apr 8, 2014 at 5:15 PM, Jeremy Schneider
>>> <jeremy.schneider@xxxxxxxxxxxxxx> wrote:
>>>
>>>> On Tue, Apr 8, 2014 at 5:09 PM, Martin Nash <martin@xxxxxxxxxxxx> wrote:
>>>> Hi Jeremy,
>>>>
>>>> Did you try "acfsroot install"?
>>>
>>> Um, disregard that last email. Hit send too quickly. The binaries were
>>> there and perfectly functional, just looks like they weren't relinked
>>> according to timestamps. Wish I could blame lack of sleep but I definitely
>>> should have known better than to email so quickly... :)
>>>
>>> -J
>
Other related posts:
