[racattack] Re: RAC Attack Automation Project
- From: Seth Miller <sethmiller.sm@xxxxxxxxx>
- To: "racattack@freelists org" <racattack@xxxxxxxxxxxxx>
- Date: Tue, 15 Apr 2014 14:12:13 -0500
Jeremy,
We're not far off from each other. The reason I would like to stick with
yum is because that's what they would need to use in their work environment
to update their systems. It's the same reason I opted for BIND over DNSmasq
or SimpleDNS. One is more likely to interface with enterprise DNS server
like BIND than the other two.
I like your idea of downloading a file locally though so we don't have to
rely on the internet. In fact, let's create a simple yum repo with only the
packages needed for the lab and maintain it on Github and turn that into an
RPM. So they can download and install the RPM which creates a local yum
repo, adds the yum config file to /etc/yum.repos.d and disables any other
configured yum repos.
On Tue, Apr 15, 2014 at 9: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:
