[racattack] Re: RAC Attack Automation Project
- From: Alvaro Miranda <kikitux@xxxxxxxxx>
- To: "racattack@xxxxxxxxxxxxx" <racattack@xxxxxxxxxxxxx>
- Date: Tue, 15 Apr 2014 17:05:39 +1200
the automation one does everything, you just run runInstaller
using vagrant it automatically download a template create 2 or more nodes, sets
names nic ip, create shared, attach the shared setup everything ( sysctl,
hosts, create mount points , permiasions, partition disks, setup udev and
oracle asm)
have you tried ? in 4 mins or about, does all, say 3 hub 2 leaf, all setup.
Alvaro
> On 15/04/2014, at 4:52 pm, Erik Benner <erik@xxxxxxxxx> wrote:
>
> How about have the automation freeze the active yum repo at something like
> 6.3, instead of "latest" and then add in a separate repo for just the RAC
> Attack scripts? The we are less likely to accidentally start a fork of OEL.
>
> I know how to build rpm files, making a simple rpm for the named files
> shouldn't take much. Same for the storage persistence.
>
> Onsite this week, but can send docs for creating dns rpm file for configs.
>
> Of course, I could also make a vbox template for both nodes, and we could
> simply have the users import the templates and then be ready to install grid
> and DB.
>
> Erik
>
>
>> On 4/14/2014 11:17 PM, Seth Miller wrote:
>> I just thought of another huge advantage to having our own repo. We could
>> include all of the configuration files necessary to make the components work
>> together. That way, when people get stuck, they can just diff the file they
>> have created with the correct file on the OS instead of spending time trying
>> to find an extra space or line feed. Moreover, those that don't want to
>> manually type stuff can just copy the file where it needs to go and be on
>> their way.
>>
>>
>>> On Mon, 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:
