Here they are: http://dev.opennebula.org/attachments/download/768/one-context_4.5.0.deb http://dev.opennebula.org/attachments/download/769/one-context_4.5.0.rpm
Remember to set DNS_HOSTNAME=yes to use the DNS name or SET_HOSTNAME to fix the name manually. On Mon, Mar 3, 2014 at 10:52 AM, ML mail <[email protected]> wrote: > Hi Javier, > > Thanks for the changes. I am not in a rush so I will test directly with > the packages. Let me know when and where the new packages are available and > I will make sure to test the .deb one for you and let you know. > > Cheers, > ML > > > > > On Friday, February 28, 2014 6:21 PM, Javier Fontan < > [email protected]> wrote: > 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 <[email protected]> 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 > > <[email protected]> wrote: > > On Thu, Feb 27, 2014 at 2:13 PM, ML mail <[email protected]> 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 > >> <[email protected]> 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 <[email protected]> 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" > >>> <[email protected]> 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" <[email protected]> > >>> To: "users" <[email protected]> > >>> 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" > >>> <[email protected]> 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" <[email protected]> > >>> To: [email protected] > >>> 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 > >>> [email protected] > >>> 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 > >>> [email protected] > >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > >> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> [email protected] > >>> 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 > >>> [email protected] > >>> http://lists.opennebula.org/listinfo.cgi/users-opennebula.org > >>> > >>> > >>> > >>> _______________________________________________ > >>> Users mailing list > >>> [email protected] > >>> 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 > > > -- 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 [email protected] http://lists.opennebula.org/listinfo.cgi/users-opennebula.org
