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.
#!/bin/ksh
myip=`lsattr -El en0 -a netaddr | awk '{print $2}'`
myname=`hostname`
echo Adding $myip $myname to /etc/hosts >> /tmp/mycloud.log
/usr/bin/hostent -a $myip -h $myname
date >> /tmp/mycloud.log
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 "manage_resolv_conf"
to false in my cloud-init config file and this would prevent the
resolv.conf file from being managed (over-written) by cloud-init. But
changing that option did nothing. And I really didn't want a resolv.conf
file at all anyway!
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/resolv.conf.cloud file instead. This works OK.
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # cat /etc/resolv.conf.cloud
search localdomain
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # mkdir cg
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # cd cg
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg/
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # cp ../aix.py .
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # vi aix.py
Change resolve_conf_fn = "/etc/resolv.conf"
To resolve_conf_fn = "/etc/resolv.conf.cloud"
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # diff aix.py /tmp/cg/aix.py
35c35
< resolve_conf_fn = "/etc/resolv.conf.cloud"
---
> resolve_conf_fn = "/etc/resolv.conf"
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # python -m compileall .
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # cp -p * ..
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros/cg # cd ..
root@vm1 /opt/freeware/lib/python2.7/site-packages/cloudinit/distros # rm -r cg
Now the customer can connect to new AIX VMs immediately after deployment.
# ls -ltr /etc/resolv.conf.cloud
-rw-r--r-- 1 root system 19 Aug 03 12:47 /etc/resolv.conf.cloud
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".
Tags:
aix
hack
cloud-init
update
hostname
chris
resolv.conf
gibson
/etc/hosts