Building a Churchill server is your first -and mandatory- step into the entire Churchill framework. It is a relatively small, lightweight server that provides all the network services that are required to construct complex Oracle environments. Without it, nothing else will work!
2.0 Hardware and Software Resources
The Churchill server doesn’t need to be particularly powerful or endowed with vast capabilities. It needs a single 64-bit CPU, at least 512MB of RAM (yup: less than a Gig!) and at least a 75GB hard disk (you can build it with about 15GB less than that if you never intend to build a Wilson server). In addition, it must have two DVD drives and a single network interface.
Since the Churchill framework is mostly intended to run on virtual machines using host-only networking, it is not too hard to build a new VM (using VirtualBox, VMware or some other virtualization platform) that meets these slightly odd requirements. See Section 3 below for VM build details.
In terms of software, you will need:
- A RHCSL 6.x distro
- The Churchill ISO
For the RHCSL distro, you can use any of the 6.x releases of Scientific Linux, CentOS, Red Hat or Oracle Enterprise Linux. Most of these distros provide a large variety of possible downloads. For example, here is the Scientific Linux 6.8 release:
You cannot use the ‘Live’ installation media: their file sizes tell you that they are missing much that Oracle will eventually need. You similarly cannot use the ‘netinstall’ media. That leaves you a choice of various ‘DVD’ media. If a “DL” (dual layer) or “Everything” file is available, you can use that for Churchill, though it’s a big download and is larger than is actually required. Probably your best bet is to download the DVD1 file, which contains everything you’ll need to build advanced Oracle infrastructure.
Churchill 1.7 and above defaults to assuming that you’ll use DVD1 of the CentOS 6.8 release, but you are free to use any of the other equivalent distros as you prefer. You can also use different 6.x releases if you prefer, back to version 6.3.
Note that getting hold of the Red Hat ISOs requires that you sign up to their developer program first. You may accordingly find it a bit easier to get hold of the other distros. At the time of writing, you can easily download the following versions of each of the non-Red Hat distros:
Other mirrors may be more appropriate for you, depending on your location of course. Those ones work fine for me in Australia! (I haven’t listed the Red Hat ISOs, because you need to log on to your developer account to be able to download them and therefore the links will always be unique to the user).
Churchill does NOT work with version 7.x RHCSL distros.
The latest Churchill ISO can be obtained from here.
You will boot your Churchill server with both ISOs (i.e., the operating system one AND the Churchill one). You get your operating system functionality from the O/S ISO; the magic sprinkling of automation comes from the use of the Churchill one!
3.0 The Churchill VM
As mentioned previously, it is assumed you are building the Churchill framework on your personal desktop or laptop in the form of virtual machines (though it will work with physical PCs if you have them).
Using VirtualBox, you first specify that you will be installing a 64-bit Red Hat operating system:
(Note that Churchill is exclusively 64-bit; no 32-bit CPUs need apply!)
Next you allocate the relevant amount of RAM:
Remember that the Churchill server itself is very lightweight: it’s not going to be busy running databases itself, merely providing the network services that let other, more powerful, servers do that. Therefore, it doesn’t need more than 512MB RAM. You can allocate more if you like (maybe 1GB or 2GB), but it’s not necessary to do so.
You then create a virtual disk:
You need to be quite generous here. The other members of the Churchill framework will be running databases -but they will be storing them on the disk space provided by the Churchill server. Therefore, 60GB should be considered a minimum useful disk size. If you are going to be building a Wilson server (for Enterprise Manager/Cloud Control), the useful minimum size should be bumped up to at least 75GB, though (because Wilson uses a huge amount of software!)
That completes the basic VirtualBox configuration, but you should alter a few things in the new VM’s settings before first running it. Primarily, this means altering the VM’s storage and networking configuration.
Storage to begin with:
Note how your VM gets built with a single virtual CD drive and a single virtual disk. The virtual disk is fine, but the single CD is not. You need to add a second, and then load each with the appropriate O/S and Churchill ISOs, like this:
Note that my CentOS 6.8 DVD 1 ISO is loaded into the Primary master drive and the churchill-1.7 ISO is loaded into the secondary master drive.
Next, the network. To begin with, you need to use your virtualization tool’s ability to create new network interfaces. This is VirtualBox’s:
I clicked the ‘+’ button to create a new host-only network interface called ‘vboxnet0’. I now need to click the ‘screwdriver’ icon to configure it:
Here, I am giving my new interface a virtual IP address of 192.168.8.1. That is not optional, but mandated by Churchill’s planned network design: your physical desktop or laptop needs to be part of that 192.168.8.x network and this is how you make sure it is.
Once you’ve assigned the new IP address, click the DHCP Server link on the same dialog box and switch off DHCP for this network interface:
Churchill eventually becomes its own DHCP server. We don’t need any other DHCP sources on the network messing things up!
Incidentally, on VMware Workstation, you do it slightly differently:
On VMware, you make your host-only network interface end with a ‘.0’ rather than a ‘.1’. In VirtualBox, you must use a proper, non-zero address. But note that I’ve still made a point of disabling DHCP on this form.
So assuming that, one way or another, you’ve got a virtual host-only network adapter with an appropriate 192.168.8.x configuration and no DHCP… you now make your Churchill VM use it. Call up the settings for your virtual machine and find the item that lets you configure its network interfaces:
By default, VirtualBox virtual machines are all built to use “NAT” network adapters, but you need to change that to be a host-only adapter -and you select the ‘vboxnet0’ interface name from the relevant drop-down.
VMware is similar:
Again note the use of two CD drives and a host-only networking adapter, previously configured to be non-DHCP and 192.168.8.x enabled.
When your virtual machine looks like this, you are ready to power it on and build your Churchill server.
4.0 Building Churchill
To build Churchill, we use Kickstart technology -which is a way of automating RHCSL server builds, using a pre-defined template of configuration and software. The kickstart script needed to automate Churchill’s build is what is stored on the Churchill ISO. So your job is really to get the new VM booting off the O/S ISO, but then tell the O/S installer to look to the Churchill ISO for its instructions. We do that by typing a single (weird-looking!) instruction onto the bootstrap line during the initial boot phase.
To begin with, power on your server …and when the boot menu appear, press the <TAB> key. You’ll see this:
Where it says “vmlinux initrd=initrd.img”, that’s your bootstrap line.
Onto the end of that line, after a space, you add the following:
That’s an instruction to start a kickstart automated deployment; using the instructions contained in the churchill.ks text file; which is found in the second DVD drive (which is what ‘hd:sr1’ is referring to). So your entire bootstrap line ends up looking like this:
Although that’s specifically a Scientific Linux 6.8 screenshot, the results are practically identical whichever version of RHCSL you use.
Just press [Enter] to initiate the installation process when you are sure your bootstrap line has been typed correctly.
Now, if all goes according to plan, you can basically sit back and enjoy a cup of tea at this point: the whole idea of kickstart installations is that they are (or can be) entirely automated. From your point of view, therefore, you’ll see a bit of text-screen faffing around and then this to start with:
…followed, eventually, by this:
…which can take quite a while to complete. And finally, you’ll see this:
And that’s the job done! All you have to do is press [Enter] to initiate the reboot.
To re-iterate: you type <TAB>, <space ks=hd:sr1/churchill.ks> and <Enter>, and that’s your entire involvement with the O/S installation process. Everything else just happens automatically. (Well, OK: to be fair, you may have to manually click a few things to remove the OS ISO before the machine reboots correctly, but I consider that fairly light labour, all things considered!)
When the server comes back from its reboot, you will note that it is rather minimal in appearance, to match its minimalist hardware configuration:
Churchill, in other words, includes no X components so there are no fancy graphical screens of any sort. It’s text mode all the way!
You login to your new server as root, password oracle.
5.0 What you get
Churchill is built simply and looks even simpler, but there’s a lot happening under the hood!
To begin with, type the command:
You’ll see something like this:
Notice that Churchill has acquired the IP address (on interface eth0) 192.168.8.250. That’s part of the kickstart auto-configuration, which is why you didn’t get asked to choose an IP address (or a hostname, come to that).
Now type this command:
pgrep httpd; pgrep bind; pgrep ntpd
That should result in a list of about 11 different numbers appearing on the screen: these are the process IDs for the Apache, Bind DNS and NTP services, so their existence tells you that Churchill is running all these things in the background. You can check some of them out easily enough:
..should return you this:
…which shows you that the DNS server 192.168.8.250 was consulted and found a record for a server called ‘geiger’ (which doesn’t even exist yet) with an address of 192.168.8.103. This is thus proof that Churchill can handle DNS lookup queries: it’s acting as its own DNS server, basically.
Similarly, open a browser on any PC that can connect to Churchill over the network and type in the url: http://192.168.8.250. You should see something like this:
You’ll get different specific results, depending on which O/S you’ve installed -but no matter the specifics, it shows you that Churchill is acting as an Apache web server. What’s more, if you issue these commands:
cd /var/www/html ls
…you’ll see the contents of the document root -files which Apache can share out over the network when a request for it is made by clients. You’ll see, for example, a file called “attlee.ks” -that’s a Kickstart script which can be accessed when you’re building an Attlee server (which I’ll cover in a later article).
Very importantly, too, you’ll see a directory called sl, rhel, oel or centos, depending on which operating system you used to build Churchill in the first place. Within that, you’ll see a sub-directory called 63, 64, 64, 66, 67, 68 or 69, depending on what version of the operating system you used to build Churchill: the directory will be called after the ‘proper’ numeric version, stripped of its decimal point.
Within that directory, you’ll find the complete contents of the installation DVD you used to build Churchill in the first place: the server has copied its own installation media into a directory which Apache can share out over the network. The significance of this? Simply that you can now build additional servers and have them fetch their installation software across the network, rather than from a locally-attached DVD.
One other thing for you to have a poke around at: navigate around the file system as follows:
cd /dbdata ls -l
You should see this sort of thing now displayed:
This shows you that there are 8 large files (each 5GB in size, so 40GB in all) sitting there with ‘globally accessible’ access control settings. These files are there to act as ‘fake hard disks’, which Churchill can share to other servers on its network. How does it share them out? Do the following:
That will show you something like this:
…which tells you that the /dbdata is being ‘exported’ as an NFS share to any server on the 192.168.8 subnet, with a bunch of NFS parameters controlling exactly how the sharing will be managed. Those parameters are not ones I’ve thrown in lightly: they’ve been specified by others (like Kevin Closson) long before me as ‘best practice’ when doing Oracle ASM over NFS, so don’t muck around with them!
6.0 Making it useful
For your Churchill server to be functionally useful as a ‘seed’ server for the rest of the Churchill framework environment, it needs Oracle software copied to it. I wish I could automate this step for you, but licensing rules mean I cannot do that! It’s therefore up to you to download Oracle database software and copy it to the /var/www/html/oracle directory, so that Apache can share them out over the network when asked to do so.
You can obtain an appropriate Oracle database release free from OTN. You need to download the 2 “Database 12c Release 1” files and the 2 “Database 12c Release 1 Grid Infrastructure” files. The four files are about 4.9GB in total.
If you intend to run Enterprise Manager 12c Cloud Control, you will need additionally to download the Release 5 files from OTN. There are three files to download in all, totalling a further 8.2GB of files.
Whether its the database or the Enterprise Manager software, the files you download will come with all sorts of names, depending on where you sourced them. OTN files have sensible-looking names; edelivery files tend to be called things like V7256238.zip, which gives you no clues to their actual function! Accordingly, Churchill requires that you rename your downloads so that they match the following template filenames:
In all cases, you’re obtaining the 64-bit versions of Oracle and the file-renaming described here is not optional.
If you intend to build a Wilson server (for managing your databases via the GUI tool called ‘Cloud Control’, you need to obtain the seven (!) files of the Cloud Control 18.104.22.168 for 64-bit Linux and not rename them.
You additionally need to obtain the database template for small Cloud Control repositories, which is another ~380MB and also needs not to be renamed.
You therefore end up with these files sitting in the /var/www/html/oracle directory in addition to the database and grid files:
The simplest way I know of getting the files onto Churchill is with an FTP tool, such as Filezilla. You make a connection to port 22 on 192.168.8.250, logging on as root/oracle. If you were configuring a ‘site’ in Filezilla for permanent and repeated use, you’d fill it in like so:
Once connected, you navigate to the /var/www/html/oracle directory in the right-hand pane and simply drag the software files across from the left-hand pane:
Eventually, you must end up with your various Oracle 12c files sitting in the /var/www/html/oracle directory, like so:
You may not be happy with the default root password. That’s easily fixed and involves no complex file editing at all. Just issue this command as root:
Just supply whatever you like as a replacement for the default password when prompted.
8.0 Next Steps
Now that your Churchill server has been built correctly, it’s ready to become useful!
It is the start of an entire ‘framework’ of other RHCSL servers, which it will automatically configure for you, that can act as standalone or clustered database servers.
But building those additional framework servers is a task best left to another article, I think!
In this article, I’ve shown you how to build an RCSL server using the churchill.ks Kickstart file that’s stored on the Churchill ISO. That build is entirely automatic and results in a standard, command-line-only RHCSL server that’s already running a bunch of useful network services. Additionally, the server will be hosting a copy of its own distro that client servers can use to build themselves over a network.
By manually copying Oracle database and grid software over to the new Churchill server -and remembering to rename the software files appropriately- you can also turn your new server into a tool that can automate the creation of client Oracle servers.
In the next article in this series, I’ll show you how to use your Churchill server to help create standardized, ASM-based Oracle servers.