Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
This is part II of a multi-part blog. If you haven’t read Part I you can read it here.
The homework from part Iof this blog was to determine what your standard configuration is. If your having trouble deciding what this should be hopefully today’s session will help with that. Below you will see all the information that will make up my “standard” build and this will be the information that I use to develop my script.
Sid’s Standard Build
The following information directly relates to the kickstart portion of the script.
Regional Settings:
- Keyboard layout: US
- language: US
- Time Zone UTC America/New_York
Service Console Configuration items:
Partitions:
- /boot = 100Mb
- swap = 1600Mb
- / = 10240Mb
- /var = 8192Mb
- /tmp = 4096Mb
- /opt = 5120Mb
- /home = 5120Mb
- vmkcore = 100Mb
- /vmfs = fill to max
License Server information:
vcenter.sidtest.com (Licenses server is installed on my vCenter Server.
The remaining information is directly related to the post installation portion of the script
Networking:
8 Network Interfaces
vSwitch0 (vmnic0, vmnic2) – Portgroups (Service Console(Vlan 300) & vMotion(vmkernel)(Vlan301))
vswitch1 (vmnic7, vmnic5) – VM Production Portgroups (vlans 2, 15, 150,151,152)
vswitch2 (vmnic4, vmnic6) – DMZ Portgroups (vlans 200, 201, 203)
vSwitch3 (vmnic1, vmnic3) – Backup Networks (vlans 400 & 401)
The two illustrations below show visual diagrams of my network configurations.
Diagram 1
Diagram 2
NOTE:
When developing your standard build it is always a great idea to manually build one server and map out the network interfaces to vmnics. It is also very important to use the same hardware and PCI placement for all servers in a cluster.
I have also decided to reject Forged Transmits and MAC address changes on all the vSwitch’s in my environment.
The following is host specific network information for this particular host:
Hostname: vmware1.sidtest.local
Service Console IP Address: 192.168.10.100
Service Console Subnet: 255.255.255.0
Service Console Gateway: 192.168.10.1
VMkernerl IP address: 192.168.12.100
VMkernel Subnet Mask: 255.255.255.0
VMkernel Gateway: 192.168.12.1
DNS Server 1: 192.168.5.20
DNS Server 2: 192.168.5.21
NTP Server 1: 192.168.5. 30
NTP Server 2: 192.168.5.31
NTP Server 3: 192.168.5.32
AD Server 1: 192.168.5.20
AD Server 2: 192.168.5.21
Remaining Build Items
In my build I will be building Active Directory (krb5) user authentication into the service console. Users will not be allowed to login directly as root. They will be forced to login using their active directory username and password. I will be granting the following users login privileges.
ssmith
jbower
cobrian
talmeda
I will also be assigning a grub password to prevent someone from booting up using init 1 and gaining service console access without entering a password.
I will be preventing users from logging into the physical console as root.
I will be setting the following password policy for local user accounts:
- Maximum password age of 90 days
- Minimum of 1 day between password changes
- 14 Day password warning before change required
I will be setting the following MOTD (Message of the Day) and Welcome.js (For web logins) message:
Warning!!! This computer system is private and may be accessed only
by authorized users. Data and programs in this system are confidential
and proprietary to the system owner and may not be accessed without
authorization. Unauthorized users or users who exceed their authorized
level of access are subject to disciplinary action, up to and including
termination and are subject to prosecution under state or federal law.
Activity on this computer system is logged.
I will be running the following agents in the Service Console:
- EMC Naviagent
- HP System Insight Management Agent
I will be allocating 800Mb of Memory to the Service Console.
This completes my ESX Build information. This is not an all inclusive list of options that can be set or configured as part of an automated installation. It is possible to configure many other options but for the purpose of this example the preceding standard build will suffice.
Be sure to check back for Part III of this series. In Part III we will be building our script to support the build that was laid out in this post. Then later in Part IV we will then go on to demonstrate the options for deploying your script to your ESX Hosts.