Hacking cloud-init on AIX.
cggibbo 270000TMUJ Comments (2) Visits (8786)
There may be better ways to do this, and if there are, please let me know. But lately I've been "hacking around" with cloud-init on AIX and trying to make it behave the way I want it to. There were two problems I faced and solved.
My first challenge. The AIX /etc/hosts file isn't updated with the IP address and hostname of the new AIX VM after deployment from PowerVC.
To work-around this niggle*, I added the following short but effective shell script to the Activation Input in the PowerVC GUI.
It's ugly but hey, it does the job!
And the second niggle. In my customers lab environment, where there's no DNS at all. Everything is /etc/hosts only. Every time they deployed an AIX VM, there was a significant delay for ssh sessions, even with netsvc.conf set to hosts=local4, the dodgy**, default, resolv.conf (search localdomain) forced DNS first....and ssh connections would hang for a minute or so before a login prompt appeared....waiting on name resolution to complete.
Some people told me that I could change "man
What I really wanted was for cloud-init to deploy the AIX VM and to NOT create an /etc/resolv.conf file. But how? Well, I managed to fudge it***. I made a change to the aix.py python script. With this change, the script now writes out an /etc
Change resolve_conf_fn = "/etc/resolv.conf"
Now the customer can connect to new AIX VMs immediately after deployment.
# ls -ltr /etc
It's a hack but it was fun.
And I guess the next time I install the latest release of cloud-init for AIX, I'll need to modify the script again. But I'm OK with this, as I expect the newer release may actually provide me with a fix to each of the problems I faced.
*niggle: To cause slight but persistent annoyance, discomfort, or anxiety.
**dodgy: dishonest or unreliable, of low quality.
***fudge it: put together clumsily. Perhaps an alteration of fadge "make suit, fit".