[racattack] Re: RAC Attack Automation Project
- From: Alvaro Miranda <kikitux@xxxxxxxxx>
- To: "racattack@xxxxxxxxxxxxx" <racattack@xxxxxxxxxxxxx>
- Date: Wed, 16 Apr 2014 08:57:03 +1200
i did work for oracle support in the past and on the same floor we had
different support groups for ebusiness suite, each group needed different
installation based on the module they support but every group needed a base ol5
.
for this i did create an custom iso, someone put the iso on a desktop or vm,
boot the machine and just few questions were asked like hostname, password and
partition layout, then using pre and post features on a kickstart file called
by default, the installation did a base setup ready to run install ebs.
other example is for my previous employer i did a custom ol6 iso that took care
of all the pre-requirement for all the products in our shop, so any vm created
will have all the required for db112 db121 weblogic obiee etc
for this effort i see i can create 2 isos, one just a boot iso that will start
and require then put the official 6.4 or a modified 6.4 that can have a custom
logo ( will do my best ) and give few options on the screen, say:
- setup this as hub collabn1
- setup this as hub collabn2
- setup this as flex collanf1
you get the idea
back to email thread, as i see it, today we have
- totally manual setup. following the book.
pros: you learn a lot, copy and paste from the book helps
con: difficult start for people who hans't used virtualbox before or is not
confortable using linux command line. sometimes copying long lines or end of
line cause the file to not work as expected
in car tuning they call stages when you tune your car
- stage 1 create a zip file with all the files modified on the book. so someone
can create the vms download the file, unzip at root level and overwrite default
ones or copy manually
- stage 2 create a yum repo or boot disk to use ol64 or ol63 and get some speed
up on the setup, following a recipe book like book.
pros. will be able to be used by virtual box, vmware or hyper v . guest os will
be always linux
- stage 3 .. ????
- stage 4 .. ????
- automation with vagrant. vagrant up and ready to unzip and run runInstaller
pros: time saver to setup the os level. allow you start direct on runInstaller
or add more nodes to one existing install ( os level only)
con: you miss the fun of doing it your self
> On 16/04/2014, at 2:15 am, Erik Benner <erik@xxxxxxxxx> wrote:
>
> I like the idea of a rpm for the labs, it is easy to install, and small
> enough that maintaining a yum server for it shouldn't be a challange. My main
> concern is a full out repo for linux, and the potential for a fork.
>
> And yes, I have tried the automated installer and for the most part it worked
> well. I prefer thr manual install, as it teaches more... but the vagrant
> option is a huge advantage for speed.
>
>
> Sent from my Galaxy S®III
>
>
> -------- Original message --------
> From: Jeremy Schneider
> Date:04/15/2014 9:59 AM (GMT-05:00)
> To: racattack@xxxxxxxxxxxxx
> Subject: [racattack] Re: RAC Attack Automation Project
>
> I can definitely see the value of the rpm repo idea for classrooms. I always
> used to copy and paste from the PDF or wiki when I did the labs and it helps
> a lot. This could be great for helping and troubleshooting.
>
> I don't think we need a full blown rpm repo for this though - a simple zip
> file with all the config files and a few troubleshooting scripts might be
> enough. Also a little more straightforward for participants I think. Just
> say, "download racattack.org/files.zip" without having to setup yum. I know
> yum repos aren't that complicated but you know how even simple things can
> trip people up at events. Another benefit of a zip file would be slightly
> easier offline/disconnected use.
>
> We could potentially generate a zip the same way we're generating
> racattack.org/vagrantfile.zip - the URL could redirect to a GitHub auto
> generated zip.
>
> Thoughts?
>
> --
> http://about.me/jeremy_schneider
> Sent from my iPhone
>
>> On Apr 14, 2014, at 10:17 PM, Seth Miller <sethmiller.sm@xxxxxxxxx> 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:
