Multiple Vhosts

[heyMP]

How are we adding mulitple vhosts for our different websites in this vagrant box. Typically, that was something that was handled through puppet or chef correct?

@jpat14 is working on a bash script that does it. I'm just wondering if that is something that can be handled by vagrant.

Something like: config.vm.hostname: ['nittany.psudug.dev', 'itnews.psudug.dev', 'coolwebsite.psudug.dev']

[btopro]

thus far we've been going w/ the notion that chef / puppet to do stuff like that is overkill. All it does it tokenize input and then write an associated .conf file. Nothing a simple bash script could do. Brad might have some thoughts on one vs the other. In my pre-install routine for elmsln I take a generic host file and then use sed to search and replace one thing w/ the other. Might be a lightweight way of accomplishing multiple hosts on provision since I think the values in the provisioner are able to be passed in throughout the scripts.

[btopro]

https://github.com/btopro/elmsln/blob/master/scripts/install/root/elmsln-preinstall.sh#L258-L266 has the sed stuff which is rewriting part of this file https://github.com/btopro/elmsln/blob/master/docs/domains.txt

[heyMP]

That works. So the hope is you just maintain the domains.txt and the preinstall script will pick up all of those entries?

[btopro]

yea like take a copy of domains.txt and flash the name of it to the other domains / subdomains you choose

[jpat14]

This solution is somewhat unconventional, but it works. You enter the docroot and it goes in and makes the domain config as well as edits the etc/hosts file https://github.com/itpsu1/itcomm-nittany-vagrant/blob/master/runfirst.sh

[btopro]

not a terrible approach in theory, like I said, i'm increasingly big on simple / compact vs packaging language upgrade hell. Writing each to its own .conf file would be better and then you wouldn't be overwriting other peopl'es files. if they said psu.edu it would be easy to smash this into psuedu.conf w/ the associated domain goodness in there.

I also don't know if the host file overwriting will go into the host machine or stay on the vagrant VM; assuming vagrant VM's /etc/hosts which is important as well but would need to be more of a 127.0.0.1 written to be pointed to for calls against the associated domain. This way it would be able to handle advagg / apc "remote" cache clears, etc.

[jpat14]

As of right now, it's editing both host files (on the host machine and the vm), with the latter outputting a similar hosts file (a textfile) pointing to 127.0.0.1, which the vagrant instance can pick up and concatenates in a script available via the wizard. It wouldn't be difficult to come up with a naming convention to programmatically give the conf files separate names.

[btopro]

yeah, do that then :) conf files generally should be split into multiples for maintainability anyway and lower confusion when u start dealing w/ boatloads of domains

[jpat14]

Is this still functionality we're looking to merge into nittany-vagrant?

[btopro]

might be in the advanced stuff i'd think, good to get a proposal for at least

[jpat14]

Todo: https://github.com/psudug/nittany-vagrant/blob/4b9a0808a6207321916010335d032bc5125805cb/multisite_todo.md