• fassembler discussion

  • deliverancevhoster's fassembler_config.ini_tmpl

    from magicbronson on Mar 11, 2008 03:31 PM 
    Right now "#force_ssl = True" is hardcoded into fassembler_config.ini_tmpl,
so if you want this to be uncommented out after a fresh build, you have to
remember to go into etc/deliverance/deliverance.ini to change it. In the
recent spirit of parameterizing more settings and controlling them through
the requirements profile, does the following seem reasonable?
Index: fassembler_config.ini_tmpl
===================================================================
--- fassembler_config.ini_tmpl (revision 52389)
+++ fassembler_config.ini_tmpl (working copy)
@@ -41,7 +41,7 @@
 # WARNING: If this is set to true, you MUST have SSL correctly configured
 # for this host, and all SSL requests MUST set X-Forwarded-Scheme header
 # to 'https' and X-Forwarded-Port header to '443'.
-#force_ssl = True
+force_ssl = {{asbool(project.req_settings.get(force_ssl, False))}}

 logger = {{env.var}}/logs/deliverance/dvhoster.log


josh
    Thread Outline:

  • Re: deliverancevhoster's fassembler_config.ini_tmpl

    from ianb on Mar 11, 2008 03:37 PM 
    Joshua Bronson wrote:
> Right now "#force_ssl = True" is hardcoded into 
> fassembler_config.ini_tmpl, so if you want this to be uncommented out 
> after a fresh build, you have to remember to go into 
> etc/deliverance/deliverance.ini to change it. In the recent spirit of 
> parameterizing more settings and controlling them through the 
> requirements profile, does the following seem reasonable?

The setting is more about whether this is a production/development 
installation, and the requirement files apply to both.  Maybe just as a 
normal setting?

   Ian

    • Re: deliverancevhoster's fassembler_config.ini_tmpl

      from magicbronson on Mar 11, 2008 08:19 PM 
      On Tue, Mar 11, 2008 at 3:37 PM, Ian Bicking <ianb@...> wrote:

> Joshua Bronson wrote:
> > Right now "#force_ssl = True" is hardcoded into
> > fassembler_config.ini_tmpl, so if you want this to be uncommented out
> > after a fresh build, you have to remember to go into
> > etc/deliverance/deliverance.ini to change it. In the recent spirit of
> > parameterizing more settings and controlling them through the
> > requirements profile, does the following seem reasonable?
>
> The setting is more about whether this is a production/development
> installation, and the requirement files apply to both.  Maybe just as a
> normal setting?
>
>   Ian
>

Good call. Done in r14373. I also changed newbuild.sh.template to pass in
force_ssl=True in r14376.

Are there any other settings that should always be one way when building on
flow or theman, and always another when building on our own machines?
(force_port used to be, but apparently we got lucky* and no longer need it.)
If there turn out to be a lot of these, maybe there is some structure we
could pull out into production/simulated-production vs. personal-development
profiles.

Josh


* We should remember this when configuring apache once we get our new
servers:
 magicbronson_ <member:magicbronson_> btw, what ever happened to force_port?
[7:59pm]ianbicking <member:ianbicking>:magicbronson_ <member:magicbronson_>:
actually, I don't know
[7:59pm]ianbicking <member:ianbicking>:I forgot about it, and it seems like
it hasn't been a problem...?
[8:00pm]ianbicking <member:ianbicking>:with the right squid/apache
configuration, it shouldn't be necessary
[8:00pm]magicbronson_ <member:magicbronson_>:ianbicking <member:ianbicking>:
oh, good. all i know is, i always used to have to tweak it by hand when i
was building for production versus personal development
[8:01pm]ianbicking <member:ianbicking>:if Squid and Apache keep Host intact,
then it isn't necessary.  I think they now do keep it intact, and so it
hasn't been a problem
[8:03pm]magicbronson_ <member:magicbronson_>:ianbicking <member:ianbicking>:
maybe squid didn't used to, or something? hm.
[8:04pm]ianbicking <member:ianbicking>:I noticed some Apache configuration
to send Host through; that might be recent
[8:04pm]magicbronson_ <member:magicbronson_>:hm, wonder if
RaFromBRC<member:RaFromBRC> did
that?
[8:04pm]ianbicking <member:ianbicking>:(I actually wasn't aware that you
could even get Apache to do that, so maybe it's something new)
[8:04pm]ianbicking <member:ianbicking>:yeah
[8:05pm]RaFromBRC <member:identifier:rafrombrc>:i think i did that when i
was experimenting w/ the SSL stuff, before we decided to just stuff the info
into the request headers
[8:08pm]magicbronson_ <member:magicbronson_>:RaFromBRC <member:RaFromBRC>,
ianbicking <member:ianbicking>: and it turned out to be the only thing
saving us from not needing force_port? a lucky coincidence?
[8:09pm]magicbronson_ <member:magicbronson_>:if so we should make sure to
remember to keep doing this in httpd.conf when we get our new servers
[8:09pm]RaFromBRC <member:identifier:rafrombrc>:a lucky coincidence and
accident... it had no effect on what i was doing, but i apparently forgot to
remove the setting, which i would normally have done
[8:09pm]

      • Re: deliverancevhoster's fassembler_config.ini_tmpl

        from magicbronson on Mar 17, 2008 04:52 PM 
        On Tue, Mar 11, 2008 at 7:18 PM, Joshua Bronson <jabronson@...> wrote:

> Are there any other settings that should always be one way when building
> on flow or theman, and always another when building on our own machines?
>

Another difference between a local build and a server build is that on local
builds (at least mine, anyway) zope sends email directly, whereas on flow
and theman it leaves messages in a queue for maildrophost to send. Where
does this configuration live? There must not have been any need to make
fassembler aware of this, but I'd like to be able to look in etc/ to find
anything I need to know about the current build. Today
dev.livablestreets.com wasn't sending emails because maildrophost wasn't
running, and I totally didn't think of checking that because it's nowhere (I
can find) in /usr/local/topp/dev.livablestreets.com. Fortunately Rob Miller
knew that was the problem and started maildrophost back up. Thanks Rob!

Note: There is now a ticket for the local vs. server build question:
http://trac.openplans.org/openplans/ticket/2476

        • Re: deliverancevhoster's fassembler_config.ini_tmpl

          from ra on Mar 24, 2008 02:30 PM 
          On Mar 17, 2008, at 1:52 PM, Joshua Bronson wrote:

> On Tue, Mar 11, 2008 at 7:18 PM, Joshua Bronson  
> <jabronson@...> wrote:
> Are there any other settings that should always be one way when  
> building on flow or theman, and always another when building on our  
> own machines?
>
> Another difference between a local build and a server build is that  
> on local builds (at least mine, anyway) zope sends email directly,  
> whereas on flow and theman it leaves messages in a queue for  
> maildrophost to send. Where does this configuration live?

the configuration lives in the ZODB.  the standard MailHost object  
does synchronous sending, if that's replaced w/ a MaildropHost object  
then the maildrop queue is used.

> There must not have been any need to make fassembler aware of this,

this is correct, fassembler knows nothing about this.

> but I'd like to be able to look in etc/ to find anything I need to  
> know about the current build. Today dev.livablestreets.com wasn't  
> sending emails because maildrophost wasn't running, and I totally  
> didn't think of checking that because it's nowhere (I can find) in / 
> usr/local/topp/dev.livablestreets.com. Fortunately Rob Miller knew  
> that was the problem and started maildrophost back up. Thanks Rob!
>
> Note: There is now a ticket for the local vs. server build question: http://trac.openplans.org/openplans/ticket/2476

if we want fassembler to handle this, we'd need to write an optional  
configuration step that replaces the default mailhost with a  
maildrophost instance.  this should only ever happen once, though;  
after the initial build, then the ZODB will contain the right mailhost.

-r

          • Re: deliverancevhoster's fassembler_config.ini_tmpl

            from magicbronson on Mar 27, 2008 03:33 PM 
            On Mon, Mar 24, 2008 at 2:29 PM, Rob Miller <robm@...> wrote:

> On Mar 17, 2008, at 1:52 PM, Joshua Bronson wrote:
>
> > On Tue, Mar 11, 2008 at 7:18 PM, Joshua Bronson
> > <jabronson@...> wrote:
> > Are there any other settings that should always be one way when
> > building on flow or theman, and always another when building on our
> > own machines?
> >
> > Another difference between a local build and a server build is that
> > on local builds (at least mine, anyway) zope sends email directly,
> > whereas on flow and theman it leaves messages in a queue for
> > maildrophost to send. Where does this configuration live?
>
> the configuration lives in the ZODB.  the standard MailHost object
> does synchronous sending, if that's replaced w/ a MaildropHost object
> then the maildrop queue is used.
>
> > There must not have been any need to make fassembler aware of this,
>
> this is correct, fassembler knows nothing about this.
>
> > but I'd like to be able to look in etc/ to find anything I need to
> > know about the current build. Today dev.livablestreets.com wasn't
> > sending emails because maildrophost wasn't running, and I totally
> > didn't think of checking that because it's nowhere (I can find) in /
> > usr/local/topp/dev.livablestreets.com. Fortunately Rob Miller knew
> > that was the problem and started maildrophost back up. Thanks Rob!
> >
> > Note: There is now a ticket for the local vs. server build question:
> http://trac.openplans.org/openplans/ticket/2476
>
> if we want fassembler to handle this, we'd need to write an optional
> configuration step that replaces the default mailhost with a
> maildrophost instance.  this should only ever happen once, though;
> after the initial build, then the ZODB will contain the right mailhost.
>
> -r
>

Just wanted to note Ian's recent work on this and the corresponding thread
on operations-discussion<http://www.openplans.org/projects/operations/lists/operations-discussion/archive/2008/03/1206644936153>.
Thanks Ian!
Return to conversation view