On Mon, Feb 29, 2016 at 10:05 AM, sebb <seb...@gmail.com> wrote:
> On 29 February 2016 at 12:22, Sam Ruby <ru...@intertwingly.net> wrote:
>> On Mon, Feb 29, 2016 at 5:35 AM, sebb <seb...@gmail.com> wrote:
>>>
>>> I'm using virtual hosts for different apps (projects, reports, etc)
>>
>> Makes sense.  Let's plan to update the "Advanced configuration"
>> section of DEVELOPMENT.md to be based on a vhost.  I've attached the
>> current puppet generated vhost definition that is on whimsy-vm2.  I
>> suspect with only minimal changes it would work as is on your machine
>> - complete with authentication.
>
> Attachment was stolen en route to me ...

I blame gnomes.

Try this: https://whimsy.apache.org/test/vhost-generator

>> Perhaps a "vhost generator" CGI script would be helpful?  First it
>> presents a form with a few fields that can be used to customize the
>> result, and then after you click submit it presents a file you can
>> download and drop into your "sites-available" directory?
>
> I don't have a sites-available directory; I'm using
> /etc/apache2/extra/httpd-vhosts.conf
>
> I think a fixed template would be just as good, together with comments
> as to what to edit if necessary.
> That would help people understand the config.

The template I'm using is live data from the actual deployment.  If
you have improvements in mind for the template, please contribute them
to infrastructure-puppet.

But I would like to go further.  I believe that the edits can be
automated.  Once this generator produces a file that you can actually
use, I'll go back and update my setup to use a vhost too.  At that
point, we will have something that two people are using.  If others
want to follow, at least they won't be trailblazing.

> But it would be helpful to have a script to check that the file paths
> used in the template contained the expected contents.
>
>>> I guess this is closer to what I need.
>>>
>>>>      Alias /roster/ /srv/whimsy/www/roster/committer
>>>>      <Location /roster>
>>>>          PassengerBaseURI /roster
>>>>          PassengerAppRoot /srv/whimsy/www/roster/committer
>>>>          PassengerAppEnv development
>>>>          Options -Multiviews
>>>>      </Location>
>>>
>>> Doesn't work.
>>>
>>> However this does:
>>>
>>>     Alias /roster/ /srv/whimsy/www/roster
>>>     <Location /roster>
>>>         PassengerBaseURI /roster
>>>         PassengerAppRoot /srv/whimsy/www/roster
>>>         PassengerAppEnv development
>>>         Options -Multiviews
>>>     </Location>
>>>
>>> Yay!
>>
>> Comparing that to what is deployed on whimsy-vm2, I missed a "/public"
>> on the Alias line.
>>
>>>> Should that not work... have you ever run Docker or Vagrant before?  I
>>>
>>> I have got Docker; don't think I have used Vagrant.
>>
>> Unless you are a Linux user, Vagrant is better in my opinion.  You get
>> a real VM that you can ssh into with full sudo access.  With Docker,
>> you get a container, which can only be hosted by Linux at the moment,
>> and that means that for Mac OS/X users you will be putting it into a
>> VM anyway.  Since you are up and running, I'll put this on the back
>> burner for now, but it is a good thing to have.
>
> Yes.
>
> If Vagrant is still OK for Linux, then potentially there is no need
> for Docker as well.
>
>>>> probably can quickly set up one or the other.  My thoughts are that
>>>> once you have a working system that you can compare against, spotting
>>>> the difference with your current setup would be much easier.  And that
>>>> could lead to updates to the documentation to help others.
>>>
>>> I think it would help to document what the paths represent, and for
>>> file paths, what one would expect to find there.
>>>
>>> e.g. I assume PassengerAppRoot is a local path, and need to point to a
>>> rake app, i.e. a whimsy directory containing config.ru.
>>>
>>> This should make it easier to check the settings are correct.
>>
>> The best way would be to base the settings on what is actually
>> deployed.  The instructions to produce those settings are in
>> infrastructure-puppet, but making the generated results visible and
>> helping you tailor them would be even better.  Would you agree?
>
> Definitely.

Cool.  See above.

- Sam Ruby

Reply via email to