tobyhferguson / corralitos Goto Github PK

When the internet is flaky then having the GUI open makes builds susceptible to network failure. By performing a build headless then the build will continue to proceed even if there're temporary network outages

The current project uses variables to determine which system to build. It might be much better to follow other people's lead and divide the system up into different directories, one per build. This allows for parallel builds.

Some environments require that YUM be configured with a proxy so that vagrant-vbguest can perform its vbox guest additions update properly.

the variable named uek-iso (or similar) is simply the boot iso - it should be renamed to make its role clearer

After successfully creating a minimal ol6u6 box using lvm, I connected to the new box and checked the /etc/hosts file. It looks a little fat for my tastes, but it could just be that that's how it is supposed to be configured in order to connect to the new box.

I need to research more about vagrant / vbox networking. My concern is that some applications (i.e. Oracle Database Server) can be fairly finicky about how the local /etc/hosts file is configured.

It is possible that as a work around I can add a second NIC to the box and assign a static ip to eth1.

I will test this out.

There are 7 OL6 builds (GA, U1 to U6).

I want to be able to build all and any.

template.json calls ../ks.cfg

i didn't change the name of the ks.cfg file in lvmi9-002 so now we need to consider how the end user can specify which type of box they want to build...btrfs or lvm...

considerations:

• separate ks.cfg files for each box type
  • ks-btrfs.cfg
  • ks-lvm.cfg
• add variable for specifying which box type to build to variable header in template.json file