I want to deploy bugzilla on dotcloud, but the perl environment is psgi.
The doc said I must use "modules to add PSGI hooks to legacy CGI or FastCGI applications".
I found CGI::Emulate::PSGI module but could not figure out how to do it.
I am a Python programmer and have no experience in Perl.
I had partial success with bugzilla-4.0.2 on a local openSUSE. I don't think Bugzilla will be suitable for cloud deployment in the short term because of its large amount of manual setup necessary. Follow the instructions referenced from docs/en/html/index.html, then run
plackup -MPlack::App::CGIBin -e'Plack::App::CGIBin->new(root => ".")->to_app'
and visit http://localhost:5000/index.cgi. The static files are missing, e.g. stylesheets. Something like along the lines of
plackup -MPlack::Builder -MPlack::App::Directory -MPlack::App::CGIBin -e 'builder {
mount "/" => Plack::App::CGIBin->new(root => ".")->to_app;
mount "/" => Plack::App::Directory->new({ root => "." })->to_app;
}'
is necessary, but mounting to the same path actually does not work in Plack 0.9985, or I'm doing it wrong.
I did not try it but This sounds like what you want. Its bugzila deployed to a cloud stackato.
You can join Stackato then deploy the bugzilla sample.
https://github.com/Stackato-Apps/bugzilla
Related
I just finished my first backend with Go using Iris framework but now I need to put it on production so I can use it in the Slack app I built.
In order to test the code locally I only run my file with go run main.go and ngrok to test with the Slack API, it's working and it's finished.
I have a droplet with Ubuntu 16.04.3 and other one with Centos 7... I was searching for something like pm2 for go, running the server and using nginx to point that port but I read that with Go it's different and I have to use something like this https://fabianlee.org/2017/05/21/golang-running-a-go-binary-as-a-systemd-service-on-ubuntu-16-04/
But that's a very long configuration for a simple server and my questions are:
Is this the usual way to config the APIs with Go?
Apart of DigitalOcean, do you recommend to use a different service to run my API?
This is really my first time with Go and I just want to learn more, I am a backend developer with Laravel and NodeJS.
You can use pm2 if you want. When you build a go project it creates a binary executable, lets say backend-server, which you can run from terminal and will start the app like this:
$ ./backend-server
If it's not executable or has permission denied issue, add the executable permission to it.
$ chmod +x backend-server
You binary should be ready to run. I like to do it with a json config file (process.json) so that I can pass extra env variables as well and don't have to type a lot in terminal.
My process.json looks something like this:
{
"apps" : [{
"name" : "backend-app",
"script" : "./backend-server",
"env": {
"DB_USER": "db_user",
"PORT": 8080
}
}]
}
Finally you can start the app using pm2 like this:
$ pm2 start process.json
More details about json config can be found in official doc
I think most people use Supervisor for this purpose, including me.
To make it very easy for you, just take a look at my Golang project, isaac-racing-server and use it as a template for yours by replacing isaac-racing-server with the name of your app. (The Supervisor files are in a subdirectory.)
If I enable Catalyst::Plugin::Session or Catalyst::Plugin::Authentication, I'm no longer able to add settings via myapp.conf, myapp_local.conf, or MyApp.pm. I've searched extensively and haven't been able to find any documentation of why this might be occurring. Is this a feature or a bug? I'm on the latest version of Catalyst and the Session plugins available via the FreeBSD ports tree. I tested this on Debian, and the same issue occurs.
p5-Catalyst-Runtime-5.90016
p5-Catalyst-Plugin-Session-0.35
p5-Catalyst-Plugin-Session-State-Cookie-0.17
p5-Catalyst-Plugin-Session-Store-FastMmap-0.16
I'm running the development server. The plugins are being loaded as follows in MyApp.pm:
use Catalyst qw/
ConfigLoader
Static::Simple
Authorization::Roles
Authentication
Session
Session::Store::FastMmap
Session::State::Cookie
/;
Attempts to set config values fail as long as the Session or Auth plugins are enabled. The only exception to this is the 'name' variable.
__PACKAGE__->config(
name => 'Will be accessible via "name"',
foo => 'Will not be accessible via c.foo if plugins are loaded',
disable_component_resolution_regex_fallback => 1,
enable_catalyst_header => 1, # Send X-Catalyst header
);
I can see ConfigLoader and myapp.conf being loaded in the server debug output. Since this is a pretty basic setup that many users probably use, I'm assuming I'm missing something fairly obvious. Neither the plugin documentation nor any number of other sources I've looked up mention anything about this, unless I just completely missed it.
Update: I thought maybe the fact that I was running this via the develpment server might have been an issue. I made a deployment via Apache/FastCGI, but it didn't make a difference.
Sorry, I need 50 reputation to make a comment, so, I will question here,
Can you add this code right before your __PACKAGE__->setup(); in App.pm ?
my $conf = __PACKAGE__->config;
use DDP; p $conf;
exit;
if you don't have Data::Printer, you can do:
my $conf = __PACKAGE__->config;
use Data::Dumper; print STDERR Dumper $conf;
exit;
this will show your current config.
I thing you are misunderstanding how it works. Since you say that "foo" 'Will not be accessible via c.foo if plugins are loaded', it should be accesible via $c->config->{foo} or c.config.foo if you are using Template::Toolkit
Can I use memcachier with ZendFramework 1.12 ?
The provider that I am useing(AppFog) only offers Memcachier (Memcached is comming soon from 10 Months) And My app will need a lot of caching when it starts. I don't want to stick with APC so I have no other good alternative.
So this is just a half answer right now, I'll try to figure out the rest. I work for MemCachier by the way, so please shoot us an email on support#memcachier.com if you have more questions.
PHP includes two memcache bindings by default: memcache and memcached. The first one (memcache) is its own implementation of the memcache procotol, while the second one (memcached) is a php binding to the libmemcached C++ library.
The memcached binding for php does support SASL these days (since version 2.0.0). Sadly it isn't documented. It also is an optional part of the memcached module, so you'll need to make sure it is compiled on your machine (or AppFog) with the SASL support enabled. The steps to do that roughly are:
Install libmemcached. I used version 1.0.14.
Install php-memcached. Make sure to pass the "--enable-memcached-sasl" option to it when running ./configure.
When building both of these you can sanity check the output of "./configure" to make sure that SASL support is indeed enabled, sadly right now it can be tricky.
Edit you php.ini file. Put the following line into it:
[memcached]
memcached.use_sasl = 1
I did all of this on OSX 10.8 using homebrew. If that is the case for you the following should work:
$ brew install libmemcached
$ brew edit php54-memcached
// you'll need to add the line:
args << "--enable-memcached-sasl"
// to the brew file.
$ brew install php54-memcached
Now to actually use SASL support, here is a test file that demonstrates it and is a good sanity check.
<?php
/**
* Test of the PHP Memcached extension.
*/
error_reporting(E_ALL & ~E_NOTICE);
$use = ini_get("memcached.use_sasl");
$have = Memcached::HAVE_SASL;
echo "Have SASL? $have\n";
echo "Using SASL? $use\n\n";
$mc = new Memcached();
$mc->setOption(Memcached::OPT_BINARY_PROTOCOL, true);
$mc->setSaslAuthData("user-1", "pass");
$mc->addServer("localhost", 11211);
$mc->set("foo", "Hello!");
$mc->set("bar", "Memcached...");
$arr = array(
$mc->get("foo"),
$mc->get("bar")
);
var_dump($arr);
?>
Adapting this to work in the Zend Framework is unknown to me right now. I'm not familiar with it so may take me some time to install and figure out. It seems very doable though given one of the backends works with SASL auth.
What is the difference on a Wamp or Web Server for the definition of $_SERVER['DOCUMENT_ROOT'] and where does it get defined on both?
And the reason I ask is I have a bunch of live websites that use the $_SERVER['DOCUMENT_ROOT'] definition.
On the live websites, $_SERVER['DOCUMENT_ROOT'] works perfectly.
On wamp server locally, it shows $_SERVER['DOCUMENT_ROOT'] as C:/wamp/www even though I have virtual hosts set up. Everything on wamp works except for the $_SERVER['DOCUMENT_ROOT'] declaration.
I used a php script suggested as a fix. The prepend_script set in auto_prepend_file in php.ini:is as follows:
auto_prepend_file = c:/wamp/www/prepend_script.php
$basePath = dirname(__FILE__); // assuming this script is in c:/wamp/www
$projectPath = preg_replace('#('.$basePath.'/[^/]+)/.*#i', '\\1', $_SERVER['PHP_SELF']);
$_SERVER['DOCUMENT_ROOT'] = $projectPath;
What that did was change the$_SERVER['DOCUMENT_ROOT'] from C:/wamp/www to /itsaboutwirelessnetworks/index.php
When in actuality for it to function properly it should be C:/wamp/www/itsaboutwirelessnetworks and not /itsaboutwirelessnetworks/index.php as the prepend script did.
So in order for myself and others to understand how this can affect them, I would appreciate an explanation of why it works on my live server and not the wamp server.
Hence the original question:
What is the difference on a Wamp or Live Web Server for the definition of $_SERVER['DOCUMENT_ROOT'] and where does it get defined on both?
The documentation says about DOCUMENT_ROOT: (emph mine)
The document root directory under
which the current script is executing,
as defined in the server's
configuration file.
So you should look at your config file and check if there is something strange there i'd say.
(I think that unless you've changed it, C:/wamp/www sounds like a valid value to assign to your document-root. If it should be something else, that must be defined in the config of the virtual host)
This seems like a bug in Apache, as it's defined in the Apache httpd.conf file.
http://www.devcha.com/2010/02/solved-incorrect-value-for.html
https://issues.apache.org/bugzilla/show_bug.cgi?id=26052
Apache/php/mysql websites are most often run on Linux servers and you're developing on Windows, the large differences between them could well account for the different bug behaviour.
If I have a greenfield project, what is the best practice Perl based configuration module to use?
There will be a Catalyst app and some command line scripts. They should share the same configuration.
Some features I think I want ...
Hierarchical Configurations to cleanly maintain different development and live settings.
I'd like to define "global" configurations once (eg, results_per_page => 20), have those inherited but override-able by my dev/live configs.
Global:
results_per_page: 20
db_dsn: DBI:mysql;
db_name: my_app
Dev:
inherit_from: Global
db_user: dev
db_pass: dev
Dev_New_Feature_Branch:
inherit_from: Dev
db_name: my_app_new_feature
Live:
inherit_from: Global
db_user: live
db_pass: secure
When I deploy a project to a new server, or branch/fork/copy it somewhere new (eg, a new development instance), I want to (one time only) set which configuration set/file to use, and then all future updates are automatic.
I'd envisage this could be achieved with a symlink:
git clone example.com:/var/git/my_project . # or any equiv vcs
cd my_project/etc
ln -s live.config to_use.config
Then in the future
git pull # or any equiv vcs
I'd also like something that akin to FindBin, so that my configs can either use absolute paths, or relative to the current deployment. Given
/home/me/development/project/
bin
lib
etc/config
where /home/me/development/project/etc/config contains:
tmpl_dir: templates/
when my perl code looks up the tmpl_dir configuration it'll get:
/home/me/development/project/templates/
But on the live deployment:
/var/www/project/
bin
lib
etc/config
The same code would magically return
/var/www/project/templates/
Absolute values in the config should be honoured, so that:
apache_config: /etc/apache2/httpd.conf
would return "/etc/apache2/httpd.conf" in all cases.
Rather than a FindBin style approach, an alternative might be to allow configuration values to be defined in terms of other configuration values?
tmpl_dir: $base_dir/templates
I'd also like a pony ;)
Catalyst::Plugin::ConfigLoader supports multiple overriding config files. If your Catalyst app is called MyApp, then it has three levels of override: 1) MyApp.pm can have a __PACKAGE__->config(...) directive, 2) it next looks for MyApp.yml in the main directory of the app, 3) it looks for MyApp_local.yml. Each level may override settings in each other level.
In a Catalyst app I built, I put all of my immutable settings in MyApp.pm, my debug settings in MyApp.yml, and my production settings in MyApp_<servertype>.yml and then symlinked MyApp_local.yml to point at MyApp_<servertype>.yml on each deployed server (they were all a little different...).
That way, all of my config was in SVN and I just needed one ln -s step to manually config a server.
Perl Best Practices warns against exactly what you want. It states that config files should be simple and avoid the sort of baroque features you desire. It goes on to recommend three modules (none of which are Core Perl): Config::General, Config::Std, and Config::Tiny.
The general rational behind this is that the editing of config files tends to be done by non-programmers and the more complicated you make your config files, the more likely they will screw them up.
All of that said, you might take a look at YAML. It provides a full featured, human readable*, serialization format. I believe the currently recommend parser in Perl is YAML::XS. If you do go this route I would suggest writing a configuration tool for end users to use instead of having them edit the files directly.
ETA: Based on Chris Dolan's answer it sounds like YAML is the way to go for you since Catalyst is already using it (.yml is the de facto extension for YAML files).
* I have heard complaints that blind people may have difficulty with it
YAML is hateful for config - it's not non-programmer friendly partly because yaml in pod is by definition broken as they're both white-space dependent in different ways. This addresses the main problem with Config::General. I've written some quite complicated config files with C::G in the past and it really keeps out of your way in terms of syntax requirements etc. Other than that, Chris' advice seems on the money.