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 <mailto: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 <mailto: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 <mailto:jeremy.schneider@xxxxxxxxxxxxxx>> wrote: On Tue, Apr 8, 2014 at 5:09 PM, Martin Nash <martin@xxxxxxxxxxxx <mailto: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
