Re: [Catalyst] X-Forwarded-Port works no more?
On 07/23/12 21:52, Tomas Doran wrote:
On 23 Jul 2012, at 08:48, Alex Povolotsky wrote:
Hello,
I'm setting up MojoMojo, https-protected.
However, it keeps making http: urls.
Setting X-Forwarded-Port did not help a bit, and trying to grep
X-Forwarded-Port to 443 did not help as well.
I've set fastcgi_param HTTPS 1, and it helps, but why X-Forwarded-Port is
mentioned but does not work?
Your post implies that your running the app as an FCGI, however you're caring
about X-Forwarded headers, which are only relevant if you're running the app
behind a proxy.
Which (or both) of these are you specifying?
Can you show us your web server config, and app config?
Yes, FCGI
=== nginx.conf ===
server {
listen 443;
server_name wiki.example.com;
ssl on;
ssl_certificate dev.crt;
ssl_certificate_key dev.key;
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location /static {
root /usr/local/share/mojomojo/root;
}
location / {
proxy_set_header X-Forwarded-Port 443;
include fastcgi_params;
client_max_body_size 128m;
proxy_read_timeout 600;
proxy_connect_timeout 600;
fastcgi_param HTTPS 1; # Only this line helps
fastcgi_pass unix:/tmp/.mojomojo.socket;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/www/nginx-dist;
}
}
=== mojomojo.conf ===
name MojoMojo
using_frontend_proxy 1
# other settings are 100% irrelevant to FCGI
=== run script ===
#!/bin/sh
exec setuidgid www envdir ./env /usr/local/bin/mojomojo_fastcgi.pl -l
/tmp/.mojomojo.socket -n 4 -e --proc_title MojoMojo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
[Catalyst] Why does the installer include the 'xt' directory
We are deploying our Catalyst apps by installing them into local::lib directories for specific users. (Yes, I know many people prefer to just run the application as-is from the source tree, but we don't.) Everything works fine, however, Module::Install::Catalyst installs the 'xt' directory in lib/perl5/MyApp. Why does it do this, and how does one tell it not to? ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does the installer include the 'xt' directory
On Tue, Jul 24, 2012 at 4:28 AM, Robert Rothenberg rob...@gmail.com wrote: Everything works fine, however, Module::Install::Catalyst installs the 'xt' directory in lib/perl5/MyApp. Why does it do this, and how does one tell it not to? Try this: http://search.cpan.org/~bobtfish/Catalyst-Devel-1.37/lib/Module/Install/Catalyst.pm#catalyst_ignore(@ignore) -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does the installer include the 'xt' directory
On 24/07/12 16:11 Bill Moseley wrote: On Tue, Jul 24, 2012 at 4:28 AM, Robert Rothenberg rob...@gmail.com mailto:rob...@gmail.com wrote: Everything works fine, however, Module::Install::Catalyst installs the 'xt' directory in lib/perl5/MyApp. Why does it do this, and how does one tell it not to? Try this: http://search.cpan.org/~bobtfish/Catalyst-Devel-1.37/lib/Module/Install/Catalyst.pm#catalyst_ignore(@ignore) I did. It doesn;t seem to have any effect, because it still installs the xt directory. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does the installer include the 'xt' directory
On Tue, Jul 24, 2012 at 9:35 AM, Robert Rothenberg rob...@gmail.com wrote: Try this: http://search.cpan.org/~bobtfish/Catalyst-Devel-1.37/lib/Module/Install/Catalyst.pm#catalyst_ignore(@ignore) Maybe run make distclean first? You are calling catalyst_ignore before calling catalyst in your Makefile.PL? If those are done then this always works.. :) vim $(perldoc -l Module::Install::Catalyst) directory. -- Bill Moseley mose...@hank.org ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does the installer include the 'xt' directory
On 24/07/12 18:34 Bill Moseley wrote: On Tue, Jul 24, 2012 at 9:35 AM, Robert Rothenberg rob...@gmail.com mailto:rob...@gmail.com wrote: Try this: http://search.cpan.org/~bobtfish/Catalyst-Devel-1.37/lib/Module/Install/Catalyst.pm#catalyst_ignore(@ignore) Maybe run make distclean first? Already tried that. You are calling catalyst_ignore before calling catalyst in your Makefile.PL? Yes. If those are done then this always works.. :) vim $(perldoc -l Module::Install::Catalyst) Well, it's not working for me. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does the installer include the 'xt' directory
On 24/07/12 18:34 Bill Moseley wrote: On Tue, Jul 24, 2012 at 9:35 AM, Robert Rothenberg rob...@gmail.com mailto:rob...@gmail.com wrote: Try this: http://search.cpan.org/~bobtfish/Catalyst-Devel-1.37/lib/Module/Install/Catalyst.pm#catalyst_ignore(@ignore) Maybe run make distclean first? You are calling catalyst_ignore before calling catalyst in your Makefile.PL? If those are done then this always works.. :) vim $(perldoc -l Module::Install::Catalyst) Ok. Silly cause of the problem. The documentation says it is a regex, rather than a file glob. Changing it from '.*[.]t$' to '*.t' seems to work. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Managing module regressions.
I meant to reply to this a month ago but haven't had the time until now. On Fri, Jun 29, 2012 at 8:24 AM, Bill Moseley mose...@hank.org wrote: This is a how do others do this? post. In your large (or even not so large) apps I assume at times you experience dependency regressions. My question is do you manage it on a case-by-case basis (simply install an older version or fix internally) or is it such a significant issue that you have a system for managing modules outside of CPAN? I've been working with a few apps where we haven't experienced a lot of dependency regressions per se, but have been dealing with several modules that had major api changes. We have had to spend a significant amount of time on maintenance in the apps to upgrade the code to handle these updated module apis. The reason I ask is because at work we are considering managing different stacks of CPAN and in-house dependencies -- so maybe dev, testing, and production/staging stacks all in separate private CPAN mirrors. And now multiply that times the number of different apps we work on. I would tend to stay away from this approach, as we have managed several apps which use different versions of modules. We have a few different development teams where developers upgrade modules without any set schedule. Some of them are writing modules which are used by all the apps, and the unannounced api changes in those modules have had cascading effects which have slowed down deployment a lot. Only 2 of these developers have modules on CPAN, so I think the others haven't experienced the real world pain that comes with rapid api changes and are less cautious with their coding. My feedback here would be try to stick with a fixed set of modules as much as possible, no matter how tempting a new module looks. My experience is that even with the very large number of dependencies in a Catalyst app that it's pretty rare to have a regression. It happens, sure, and when it happens just deal with it. (And thinking of our own code it's typically not a regression in a module but a fix in a module where our code was depending on some broken behavior). So, the question is: does anyone else find it necessary to manage dependencies as I described above? And if so, what is your process? We looked at implementing Pinto for module version management, but that effort seemed to have never really taken off. I don't think the part of the team implementing it dealt with the pain the rest of us were experiencing on a day to day basis. Another argument that is floated around is we don't want to upgrade dependencies often because of potential new bugs. That seems a bit silly to me because it's ignoring known bug fixes for the chance that there might some unknown new bug.(Yes, we have apps running Catalyst from 2010!) This has been a big pain point for us, enough that the build engineer I work with to deploy the rpms with is now averse to upgrading modules. The config module we developed in house changed its api 3 times in one year. A couple of the other core modules changed significantly, causing weeks/months of delays. We had to upgrade to Catalyst 5.9 and Moose 2.0 recently, and that was quite painful (this is not a dig at either of those modules, just a reflection of our upgrade experience). We ran into this issue with the Moose 2 upgrade - took a few days to track down. http://freebsd.so14k.com/problems_with_perl_catalyst.shtml So while we haven't run into unknown new bugs, the cost of upgrading modules on an ad hoc schedule has been large, and outweighing most business value brought by the upgraded modules. I'm not saying that you shouldn't upgrade modules when they are available. But such upgrades should be scheduled apart from feature releases, and not done ad hoc. This can be difficult when you have a loosely organized team and developers want to try out the latest release of a module. Of course, this is all in the context of an application that generates revenue and has a user base that expects the app to remain largely bug free. If I'm developing something that has an alpha user base, I'll always go for the most recent release. Also, these experiences are that of a large team developing large apps to hundreds of servers. The experience of one developer deploying to a small environment will certainly be different. ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Managing module regressions.
On 24 Jul 2012, at 19:17, Fred Moyer wrote: Also, these experiences are that of a large team developing large apps to hundreds of servers. The experience of one developer deploying to a small environment will certainly be different. I wonder how life would be different if you just deployed an entire perlbrew per app, so /opt/MyApp/bin/perl - this would make the cost of upgrading things much more trivial, as the cost would be per project, rather than having a wider impact.. It would also allow teams for each product to be strongly conservative (if that suited the team in question), or running much newer versions of stuff (on younger apps / more agile teams) - rather than having to dictate a version policy organisation wide. I'm _not_ saying it would be better - everyone's environment and constraints are different, but thinking 'what if' about an entirely different strategy is entirely worthwhile. A lot of your pain seems to come from the fact that you can only have one version of every library on each system. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does the installer include the 'xt' directory
On 24 Jul 2012, at 19:14, Robert Rothenberg wrote: On 24/07/12 18:34 Bill Moseley wrote: On Tue, Jul 24, 2012 at 9:35 AM, Robert Rothenberg rob...@gmail.com mailto:rob...@gmail.com wrote: Try this: http://search.cpan.org/~bobtfish/Catalyst-Devel-1.37/lib/Module/Install/Catalyst.pm#catalyst_ignore(@ignore) Maybe run make distclean first? You are calling catalyst_ignore before calling catalyst in your Makefile.PL? If those are done then this always works.. :) vim $(perldoc -l Module::Install::Catalyst) Ok. Silly cause of the problem. The documentation says it is a regex, rather than a file glob. Changing it from '.*[.]t$' to '*.t' seems to work. Doc patch please? :) Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Managing module regressions.
On Tue, Jul 24, 2012 at 1:03 PM, Tomas Doran bobtf...@bobtfish.net wrote: On 24 Jul 2012, at 19:17, Fred Moyer wrote: Also, these experiences are that of a large team developing large apps to hundreds of servers. The experience of one developer deploying to a small environment will certainly be different. I wonder how life would be different if you just deployed an entire perlbrew per app, so /opt/MyApp/bin/perl - this would make the cost of upgrading things much more trivial, as the cost would be per project, rather than having a wider impact.. It would also allow teams for each product to be strongly conservative (if that suited the team in question), or running much newer versions of stuff (on younger apps / more agile teams) - rather than having to dictate a version policy organisation wide. Agreed on the heterogenous module approach for different apps. That part of it has worked well, but sometimes dependencies leak up the chain into your application. It's definitely not an easy problem. So far though I think we've had success in the current approach despite the pain points on certain part. I'm _not_ saying it would be better - everyone's environment and constraints are different, but thinking 'what if' about an entirely different strategy is entirely worthwhile. A lot of your pain seems to come from the fact that you can only have one version of every library on each system. Cheers t0m ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] po files directory for I18n and compilation
Hi, I have just started to use I18n for localization. It works fine, but I am surprised because it seems that .po translations are only active after restarts. This way I can´t give customers the freedom to localize/customize their app. I am the webmaster, I must restart the app for every change they do in the translations. And the .po files must be loaded in myapp/lib/I18n. But I dont want to give them permissions to use that directory... Is there something I can do? .mo files are compiled versions of .po files. Can't they be used somehow to avoid restarts? Regards: Jeremy ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] X-Forwarded-Port works no more?
I'm afraid only Catalyst::Engine::CGI cares about X-Forwarded-Port as
described in the doc.
You can try to write your own uri_for() to use X-Forwarded-Port.
On Tue, Jul 24, 2012 at 3:22 PM, Alex Povolotsky tark...@over.ru wrote:
On 07/23/12 21:52, Tomas Doran wrote:
On 23 Jul 2012, at 08:48, Alex Povolotsky wrote:
Hello,
I'm setting up MojoMojo, https-protected.
However, it keeps making http: urls.
Setting X-Forwarded-Port did not help a bit, and trying to grep
X-Forwarded-Port to 443 did not help as well.
I've set fastcgi_param HTTPS 1, and it helps, but why X-Forwarded-Port is
mentioned but does not work?
Your post implies that your running the app as an FCGI, however you're
caring about X-Forwarded headers, which are only relevant if you're running
the app behind a proxy.
Which (or both) of these are you specifying?
Can you show us your web server config, and app config?
Yes, FCGI
=== nginx.conf ===
server {
listen 443;
server_name wiki.example.com;
ssl on;
ssl_certificate dev.crt;
ssl_certificate_key dev.key;
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location /static {
root /usr/local/share/mojomojo/root;
}
location / {
proxy_set_header X-Forwarded-Port 443;
include fastcgi_params;
client_max_body_size 128m;
proxy_read_timeout 600;
proxy_connect_timeout 600;
fastcgi_param HTTPS 1; # Only this line helps
fastcgi_pass unix:/tmp/.mojomojo.socket;
}
#error_page 404 /404.html;
# redirect server error pages to the static page /50x.html
#
error_page 500 502 503 504 /50x.html;
location = /50x.html {
root /usr/local/www/nginx-dist;
}
}
=== mojomojo.conf ===
name MojoMojo
using_frontend_proxy 1
# other settings are 100% irrelevant to FCGI
=== run script ===
#!/bin/sh
exec setuidgid www envdir ./env /usr/local/bin/mojomojo_fastcgi.pl -l
/tmp/.mojomojo.socket -n 4 -e --proc_title MojoMojo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
