Nice work, I've tested the debian package and setting the hostname dynamically based on the PTR DNS entry works perfectly!
Cheers, ML On Monday, March 3, 2014 12:53 PM, Javier Fontan <[email protected]> wrote: 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
