
OEDA has properties too
Some customers ask for help to fill in the Exadata Deployment assistant (OEDA for short). This is the case in my current project. They bought a shiny brand new X7 and requested assistance for the OEDA as they faced an issue with the admin network. It reproduces very easily so I will show this using a demo example.
A small introduction is maybe needed for this. Most of us know the 10.x.x.x/8 or the 172.16.x.x and 192.168.1.x/24 ranges that are meant for your own use. The network admins know more and there exist also other predefined ranges. You can find those ranges here: https://en.wikipedia.org/wiki/Reserved_IP_addresses or the official one here: http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml#iana-ipv4-special-registry-1
You feel where this is heading to aren’t you?
My customer wanted to use one of these ranges. In order not to reveal the customer I took another range to demo it, but the point is the same.
As you can see, the OEDA complains on using the ICAN ranges. I used the range which is originally intended for a 6to4 Relay Anycast (but it’s deprecated). I think this is a good thing that OEDA protects you from using these.
In some (rare) cases, it might be necessary to derive from these recommendations. The OEDA tool has, just like many others, a properties file. This one is located in the properties directory.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
mbp-vanpupi:~ pieter$ ls -l $OEDA_DIR total 432 drwxr-xr-x 18 pieter staff 576 May 10 07:38 Lib -r-xr-xr-x 1 pieter staff 3541 Aug 14 2013 README -r-xr-xr-x 1 pieter staff 126268 May 7 22:24 README.html -r-xr-xr-x 1 pieter staff 58045 May 7 22:24 README.txt drwxrwxr-x 2 pieter staff 64 May 10 07:38 WorkDir -r-xr-xr-x 1 pieter staff 232 Feb 8 23:26 applyElasticConfig.sh -r-xr-xr-x 1 pieter staff 233 Feb 8 23:26 changePassword.sh drwxr-xr-x 173 pieter staff 5536 May 10 07:38 config -r-xr-xr-x 1 pieter staff 221 Apr 19 19:11 config.sh -r-xr-xr-x 1 pieter staff 240 Feb 8 23:26 genPasswordHash.sh -r-xr-xr-x 1 pieter staff 307 Apr 19 19:11 install.sh -r-xr-xr-x 1 pieter staff 101 Feb 8 23:26 jre drwxr-xr-x 3 pieter staff 96 Dec 20 02:53 jre1.8.0_162.jre drwxrwxr-x 7 pieter staff 224 May 25 12:25 log -r-xr-xr-x 1 pieter staff 215 Apr 19 19:11 oedacli drwxrwxr-x 11 pieter staff 352 May 10 07:38 out drwxr-xr-x 20 pieter staff 640 May 25 12:22 properties drwxrwxr-x 2 pieter staff 64 May 10 07:38 webApp mbp-vanpupi:~ pieter$ |
There we find the es.properties file
1 2 3 |
mbp-vanpupi:~ pieter$ ls -l $OEDA_DIR/properties/es.properties -r-xr-xr-x 1 pieter staff 52775 May 25 12:08 /Users/pieter/Downloads/macosx-x64/properties/es.properties mbp-vanpupi:~ pieter$ ls |
First create a copy of this file as a precaution. The mandatory disclaimer is needed. Do not mess with these files unless you are very aware of what are the consequences of this.
So the entry we are interested in is:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
#Following ips are from IANA which is responsible for IPv4 address allocation. #http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special #-registry.xhtml#iana-ipv4-special-registry-1 #These ip addresses are not allowed user to use, #Based on bug filer's comment: #One has to point out that the "Private-Use" addresses are commonly used by #Customers to allocate addresses from. So we should not be blocking the #10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16, but the rest in the list should #be checked to make sure they are not used. The deprecated address range, #192.88.99.0/24 should be OK for Customer's to use. IANA_IPV4_IPS=0.0.0.0/8,100.64.0.0/10,127.0.0.0/8,169.254.0.0/16,192.0.0.0/24,\ 192.0.0.0/29,192.0.0.8/32,192.0.0.9/32,192.0.0.170/32,192.0.0.171/32,192.0.2\ .0/24,192.31.196.0/24,192.52.193.0/24,192.88.99.0/24,192.175.48.0/24,198.18\ .0.0/15,198.51.100.0/24,203.0.113.0/24,240.0.0.0/4,255.255.255.255/32 |
Look who is there. All the ICAN ranges which should not be used. The demo used 192.88.99.x/24 so when I remove this entry and change the IANA_IPV4 from
1 2 3 4 |
IANA_IPV4_IPS=0.0.0.0/8,100.64.0.0/10,127.0.0.0/8,169.254.0.0/16,192.0.0.0/24,\ 192.0.0.0/29,192.0.0.8/32,192.0.0.9/32,192.0.0.170/32,192.0.0.171/32,192.0.2\ .0/24,192.31.196.0/24,192.52.193.0/24,192.88.99.0/24,192.175.48.0/24,198.18\ .0.0/15,198.51.100.0/24,203.0.113.0/24,240.0.0.0/4,255.255.255.255/32 |
to
1 2 3 4 |
IANA_IPV4_IPS=0.0.0.0/8,100.64.0.0/10,127.0.0.0/8,169.254.0.0/16,192.0.0.0/24,\ 192.0.0.0/29,192.0.0.8/32,192.0.0.9/32,192.0.0.170/32,192.0.0.171/32,192.0.2\ .0/24,192.31.196.0/24,192.52.193.0/24,192.175.48.0/24,198.18\ .0.0/15,198.51.100.0/24,203.0.113.0/24,240.0.0.0/4,255.255.255.255/32 |
and rerun the OEDA using the same input:
There we go! OEDA accepts the input and the next button does not result anymore in an error.
The thing is. This properties file is a very powerful file which contains all the correct information which is needed to get a stable exadata. I would not recommend to tamper with it, but at least this shows how it works and why the error was thrown.
As always, questions, remarks? find me on twitter @vanpupi