I've uploaded the scripts to the branch feature-2453 for both deb and rpm based distros.
DNS_HOSTNAME=yes: gets the first ip and tries to get the dns name with "host" SET_HOSTNAME=name.of.the.host: sets the hostname I'll try to create the packages before leaving the office but you can follow the instructions there in case you want to create them yourself. [1] https://github.com/OpenNebula/one/tree/feature-2453/share/scripts/context-packages On Thu, Feb 27, 2014 at 10:29 PM, ML mail <mlnos...@yahoo.com> wrote: > Hi Javier, > > Thanks for the example with using $NAME in the SET_HOSTNAME context variable > that for sure helps not having one template per VM. Although I already see > the next problem, you can't have spaces in your VM name but that's a detail > :) > > I totally agree regarding the dynamic hostname based on the PTR DNS record > of the VM, it should not be a default but only activated through a context > variable, like you mention DNS_HOSTNAME variable is fine. Right now no other > ideas just as simple as possible by doing a reverse lookup on the first/main > IP of the VM should be enough I would say. > > I guess the "host" command would be the one which should always be > available. I have seen cases where there was no "dig" installed on a base > linux installation and "nslookup" is sort of fading out. In the worst case > if the host command does not exist nothing happens or it could fallback to > dig. > > Greetings, > ML > > > On Thursday, February 27, 2014 4:27 PM, Javier Fontan > <jfon...@opennebula.org> wrote: > On Thu, Feb 27, 2014 at 2:13 PM, ML mail <mlnos...@yahoo.com> wrote: > >> You are right I had to define the HOSTNAME variable in the template >> context >> and not as a tag in the already running VM. This means that I can't share >> templates among VMs, which is a bit stupid of course. With this solution >> you >> need one template per VM. > > Not exactly. The value of custom variables can be a dynamic one [1] so > for example you can set the hostname to the name of the VM: > > SET_HOSTNAME="$NAME" > > or even a mix of static and dynamic data: > > SET_HOSTNAME="$NIC[IP].domain.com" > > [1] > http://docs.opennebula.org/stable/user/virtual_machine_setup/cong.html#using-template-variables > >> I see the issue with the HOSTNAME environment variable which is actually >> set >> at bootup of Linux so no problem with me for using a name such as >> SET_HOSTNAME like you suggest. > > Good, I'll go with this. > >> What do you think about having that same script also defining the hostname >> dynamically (if none was defined with the SET_HOSTNAME context variable) >> based on a DNS reverse lookup if the IP address of the VM has a PTR >> record? > > I think it's a nice feature but it should only be set if the users > asks for it. For example, if some VM has a hardcoded hostname a user > does not expect it to be changed in case SET_HOSTNAME is not defined. > Another variable can be added like DNS_HOSTNAME=yes or even better, > specifying the IP where to get the name from: > > DNS_HOSTNAME="$NIC[IP, NETWORK=\"Public\"]" > > Any better idea? > > I'm not sure which command to use to do the reverse lookup. One that > is in most of the distributions like host, nslookup or dig. > > Cheers > >> >> >> >> On Thursday, February 27, 2014 12:27 PM, Javier Fontan >> <jfon...@opennebula.org> wrote: >> Hi, >> >> ML, I think you should add it in the template context section, custom >> variables. >> >> I am adding scripts to configure the hostname in the context phase. >> These are simple scripts (one for rpm and other for deb based distros) >> that do just what you've commented, call hostname and modify the conf >> file. [1] >> >> I've just found a problem with it and it is calling the configuration >> variable "HOSTNAME". The shell automatically sets HOSTNAME and even if >> we don't specify it so it's a bit tricky to check wether the user >> intents to configure the hostname or leave it as it is. >> >> I am proposing to use the custom variable "SET_HOSTNAME" to configure >> the host name. What do you think? >> >> Concerning the addition of scripts in the context package, there is a >> guide in both the documentation [2] and the source code [3] on how to >> create custom packages. Having the required dependencies it's fairly >> easy to add or modify the configuration script you may need. >> >> Cheers >> >> [1] http://dev.opennebula.org/issues/2453 >> [2] >> >> http://docs.opennebula.org/stable/user/virtual_machine_setup/cong.html#generating-custom-contextualization-packages >> [3] >> >> https://github.com/OpenNebula/one/tree/master/share/scripts/context-packages >> >> On Thu, Feb 27, 2014 at 8:02 AM, ML mail <mlnos...@yahoo.com> wrote: >>> Regarding the hostname script that's exactly what I did, I also tried to >>> redeploy this persistent image. Where exactly did you set the HOSTNAME >>> variable? I have setted it in the tags of that specific VM (where I would >>> also add the SSH_PUBLIC_KEY variable). But that might be wrong? >>> >>> Regards, >>> ML >>> >>> >>> On Thursday, February 27, 2014 2:47 AM, "Campbell, Bill" >>> <bcampb...@axcess-financial.com> wrote: >>> For item 1, no that should do it, just make sure it's executable and it >>> should run. (the vmcontext init.d script will run all scripts in the >>> /etc/one-context.d directory in order). I set this up for Ubuntu, but >>> I'm >>> pretty sure Debian is the same when it comes to setting the hostname. >>> You >>> mention you reboot the VM, you may have to redeploy (as the context >>> script >>> is already generated from your previous deployment package). >>> >>> For item 2, you could include it in your base image, or in the example >>> provided, add it to the files repository along with that init.sh script, >>> and >>> then assign both files to the template. This way the files will be >>> included >>> with the context information, will copy the ##-script over to the >>> instance, >>> and restart the vmcontext service. >>> >>> ________________________________ >>> From: "ML mail" <mlnos...@yahoo.com> >>> To: "users" <users@lists.opennebula.org> >>> Sent: Wednesday, February 26, 2014 11:12:08 AM >>> Subject: Re: [one-users] ONE context package >>> >>> Hi Bill, >>> >>> Thanks for your answer and example scripts. I have a few more questions >>> or >>> issues regarding your examples: >>> >>> - I tried out your small hostname script which I have copied on my Debian >>> 7 >>> VM under /etc/one-context.d/98-hostname. I have then set in my VM a tag >>> called HOSTNAME with a value and rebooted the VM. Unfortunately the >>> hostname >>> did not get changed. Did I miss something here? >>> >>> - I suppose I would have to re-create the one-context package manually if >>> I >>> would like to include the aforementioned 98-hostname script in the >>> official >>> one-context package, correct? or I could manually copy it into my image >>> before deploying it? >>> >>> Regards, >>> ML >>> >>> >>> >>> On Wednesday, February 26, 2014 3:08 PM, "Campbell, Bill" >>> <bcampb...@axcess-financial.com> wrote: >>> We don't have the automatic lookup from DNS (that would rely on the DNS >>> record being created first prior to VM deployment), but we use a script >>> that >>> is placed in our base images /etc/one-context.d/ directory that does this >>> (which relies on option 2 as you mention below, a HOSTNAME context >>> variable): >>> >>> #!/bin/bash >>> >>> if [ -f /mnt/context.sh ]; then >>> . /mnt/context.sh >>> else >>> exit 0 >>> fi >>> hostname $HOSTNAME >>> echo $HOSTNAME > /etc/hostname >>> >>> exit 0 >>> >>> The above example is for our Ubuntu instances, so it may need to be >>> modified >>> for RHEL or SUSE based virtuals, if that's what you use. >>> >>> In addition, if using 4.4, use the files datastore and create an >>> 'init.sh' >>> script that can then load up additional files that you assign to the >>> template (so you don't need to manually update each image). We use an >>> init.sh script like this to inject new configuration/contextualization >>> options so we don't need to update our base image very often: >>> >>> >>> #!/bin/sh >>> # >>> # OpenNebula Init Script >>> # >>> # init.sh >>> # >>> # Copies additional context scripts to the appropriate directory >>> # >>> ## Set environment >>> SOURCE=/mnt >>> DEST=/etc/one-context.d >>> >>> if [ -f /etc/redhat-release ]; then >>> OSVERSION=RHEL >>> else >>> OSVERSION=UBUNTU >>> fi >>> if [ -f /usr/bin/rsync ]; then >>> echo "Applying additional contextualization scripts..." >>> else >>> if [ "$OSVERSION" != "UBUNTU" ]; then >>> yum -y install rsync >>> else >>> apt-get update && apt-get -y install rsync >>> fi >>> fi >>> >>> ## Copy Files. This will IGNORE any *.sh files in the source/destination >>> directories, as all context scripts >>> ## should NOT have the .sh extension. >>> for i in $(ls $SOURCE --ignore=*.sh) >>> do >>> if [ -f $DEST/$i ]; then >>> echo "$i exists in context directory. Skipping..." >>> else >>> rsync -au $SOURCE/$i /etc/one-context.d/ >>> chown root.root /etc/one-context.d/* >>> chmod 700 /etc/one-context.d/* >>> service vmcontext restart >>> fi >>> done >>> exit 0 >>> >>> This will check the OS Version and install the appropriate package. It >>> will >>> NOT copy any file that has the .sh extension, but if you follow the >>> context >>> script standard of ##-<scriptname> then you can add additional context >>> upon >>> deployment. Rudimentary, sure, but works well enough for us. >>> >>> >>> ________________________________ >>> From: "ML mail" <mlnos...@yahoo.com> >>> To: users@lists.opennebula.org >>> Sent: Wednesday, February 26, 2014 5:39:46 AM >>> Subject: [one-users] ONE context package >>> >>> Hi, >>> >>> I am very happy with the ONE context package for automated >>> contextualization >>> on Debian and CentOS but I miss one feature: automatically and manually >>> setting the hostname of the VM. >>> >>> Basically it would be great to have the following two options: >>> >>> - automatically set the hostname of the VM based doing a reverse DNS >>> lookup >>> on the IP address, for example I have as reverse DNS entry >>> "one-vm-1-0-16-172.mydomain.com" then the hostname of my VM would be >>> automatically set to "one-vm-1-0-16-172". >>> - using a HOSTNAME tag in the VM to manually enter a hostname and >>> overriding >>> the automatic hostname attribution described above >>> >>> What do you think? >>> >>> Regards, >>> ML >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opennebula.org >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >>> >>> >>> NOTICE: Protect the information in this message in accordance with the >>> company's security policies. If you received this message in error, >>> immediately notify the sender and destroy all copies. >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opennebula.org >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opennebula.org >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >>> >>> >>> NOTICE: Protect the information in this message in accordance with the >>> company's security policies. If you received this message in error, >>> immediately notify the sender and destroy all copies. >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opennebula.org >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >>> >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users@lists.opennebula.org >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org >> >>> >> >> >> >> -- >> Javier Fontán Muiños >> Developer >> OpenNebula - The Open Source Toolkit for Data Center Virtualization >> www.OpenNebula.org | @OpenNebula | github.com/jfontan > >> > > > > -- > Javier Fontán Muiños > Developer > OpenNebula - The Open Source Toolkit for Data Center Virtualization > www.OpenNebula.org | @OpenNebula | github.com/jfontan > > -- Javier Fontán Muiños Developer OpenNebula - The Open Source Toolkit for Data Center Virtualization www.OpenNebula.org | @OpenNebula | github.com/jfontan _______________________________________________ Users mailing list Users@lists.opennebula.org http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
