Database Reference
In-Depth Information
■
Tip
encrypted passwords can be taken from an existing /etc/shadow file.
Specifying an encrypted password is much safer than a clear text password!
The following directives disable the firewall and set the security-enhanced Linux settings to permissive. Be sure
to update this section after consulting your IT-security department! The
authconfig
command enables the use of
shadow passwords which implies local user accounts on the machine. Furthermore the shadow passwords should use
SHA512 as the password algorithm.
The timezone is then set to America/New_York-this should most definitely be adopted to match the closest
location where the server is located. The next few lines are dealing with the boot loader location and the partitioning
scheme. The chosen partitioning options can be translated into English as follows:
•
clearpart
: Clear all partitions and initialize the disk label
•
part /boot
: Create a boot partition of 200 MiB using ext4
•
part pv008002:
Create a physical volume and use all remaining space
•
volgroup rootvg:
Create a volume group “
rootvg
” using the physical volume just created
•
logvol (twice):
Create two logical volumes on volume group
rootvg
.
The kickstart file explicitly uses disk sda only. The remainder of the file specifies which YUM packages and
groups should be installed. If you wonder which groups are available, you can use YUM on a system to execute the
following query:
# yum grouplist
Although it looks intimidating at first-especially the partitioning part-the Kickstart process is logical and easy
to master. The Kickstart format is also very well documented in the installation guide. Please refer to it for further
information about available options. Once the Kickstart file is ready, move it to a directory on the webserver from
where it is accessible to the build network. For security reasons it should not be exposed outside of the build network.
To follow the example you need to place it into
/var/www/html/ks/
.
A final word of warning: please be careful with the file. It absolutely erases everything! As with anything in this
book, please adapt the file to your needs and test it thoroughly before deploying it on real systems.
Testing the automated installation
With all the preparation work completed, it is time to put the procedure to test. Connect a machine to the build
network and enable PXE booting on the hardware level. Most often you would connect to the lights-out management
console before starting the server. After a little while, when the subsystems have initialized, the network card
should advertise that it is trying to PXE boot. This triggers a DHCP request on your install server, which should be
acknowledged. If you like (still on the install server) start tailing the
/var/log/messages
file to see what happens.
If you are really curious you could start
tcpdump
on your install server to listen on port 69 to see if the
tftp
request
can be satisfied.
If everything goes well then you will see a (very basic) boot menu which will automatically boot the default
operating system. If you are curious you will see the whole installation happening on the lights-out management
console. You should do this at least once to ensure that there are no problems with the process. Also bear in mind
that you need to be careful where you install the operating system: there is no safety net: all the data on the machine
is erased, and you get a fresh Oracle Linux server instead. If you used DDNS you should then have a server, which is
correctly configured within DNS and ready for the next steps, the preparation of the OS to install Oracle Database 12.1.
Search WWH ::
Custom Search