[racattack] Re: RAC Attack Automation Project
- From: Alvaro Miranda <kikitux@xxxxxxxxx>
- To: "racattack@xxxxxxxxxxxxx" <racattack@xxxxxxxxxxxxx>
- Date: Wed, 16 Apr 2014 08:24:54 +1200
i will go tru the ebook and will test using the 6.4 image i already have
created, if all goes good as expected, will create racattack/oracle64 on
vagrant cloud and default github vagrant file to that image as we agree over
email.
( https://mini.kikitux.net/racattack have the image i havent tested yet nor
created the vagrant cloud one )
for github, what name sounds good for a new repo ? Can you Jeremy or Seth
create one ? racattack/filesforwikibook or something like that?
> On 16/04/2014, at 2:27 am, Jeremy Schneider <jeremy.schneider@xxxxxxxxxxxxxx>
> wrote:
>
> 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:
