First things first – the questions look typical for the recruiter screening stage at any large company. Some people know the answers, others lack the most basic concepts and fail such test from the beginning to its end. The purpose of this screening, at its very core, is to reduce the load on the subsequent “interview layers” – phone interviews with engineers and then on-site interviews. It is simply not economically feasible for any company to have a highly trained engineer administer such test; the engineer’s time simply costs more money, along with the mental wear and the likely alienation that is bound to happen due to the incredibly large percent of unsuitable candidates.
The second purpose of such screening, beyond the technical assesment, is to act early on a possible culture mismatch. Does the candidate speak the same language? No, not if they speak English – the question is: do they use the same words to describe technical concepts? “Knowledge”, in a broad sense, can be expressed in many forms, not all of them useful for everybody out there (e.g. the 0x02 – SYN representation, while undoubtely useful for low level debugging, is of no use during a formal or informal talk, even with an engineer with advanced knowledge of the TCP stack).
The setup was performed on a freshly installed CentOS 6 VM using a “minimal ISO” image from the CentOS Project website. The VM was set up on a local VirtualBox installation, all settings being left to default except for the memory which was increased from 512Mb to 1Gb. Of course, the more, the better, but 1Gb is the lowest one can go without facing serious memory swapping.
The successful Centos 6 installation leaves the external network interface disabled upon the initial boot, so this must be fixed before anything else. One must look into /etc/sysconfig/network-scripts/ifcfg-eth0 and change the ONBOOT parameter from no to yes. Afterwards, the network subsystem must be restarted, e.g.:
# vi /etc/sysconfig/network-scripts/ifcfg-eth0 ... ONBOOT=yes ... # service network restart
Once the VM gets Internet access, it’s a good practice to update everything and reboot it before going forward with the Chef Server installation:
# yum -y update # reboot
There is one important change one must perform in order to get the Chef Server properly set up: the hostname, as localhost.localdomain won’t do. The hostname must also be associated to a static IP address, which can be achieved in VirtualBox by playing with some networking settings (not presented here).
Inside the VM, this is easy to put in place: